We had a banner over the door way at our nuclear weapons plant decommissioning project.
Don't so stupid things on purpose
This banner was meant to remind all those working on the decommissioning of the plant not to "do stupid things - period." Least bad things would happen. In our Program Management Office, overseeing the development and deployment of software systems in support of those doing the real work, NOT doing stupid things meant being on-time, on-budget, and on-specification for our applications and services, engaging them in conversations about their needs, continuing that conversation during test, deployment, operations, and eventual decommissioning of the software itself. When you've removed all the Plutonium and hauled everything else to Carlsbad NM, what's left is several TeraBytes of data and the applications that created it. Putting that somewhere safe requires project management as well.
But doing stupid things on purpose seems to be what Dave Nicolette suggests people do in his recent Nine Boxes post. The concept at the end is interesting - although any good requirements elicitation process would result in the same outcome. But this one is cleaver I must admit.
But once again a "voice of agile" starts with a situation that will be corrected by the application of some form of an agile method. The situation here is typical agile-mumbo jumbo.
- Some kind of inane software development process is applied to a problem. No in the loop customer, just big bang requirements developed by strangers, no feedback anywhere in sight, lots of linear testing at the end, and of course Dilbert management running the show.
Maybe this happens. I can't say I've seen it. Maybe Dave's just playing the role of provocateur for effect. But in the end it's the traditional agilest "red herring" approach.
- We have this terrible problem in the software development world created by "waterfall," or some other boggy man from the past
- Our agile methods cure this problem
Never thinking to ask - are these people doing stupid things on purpose. Are they not even following the most rudimentary of project processes known to man - ask your customer what you want, confirm that want, and continue to confirm as you proceed.
There is absolutely no doubt iterative and incremental development processes are beneficial. That having the customer fully engaged in the requirements, development, testing, and deployment processes is vastly better than not having them engaged. But why all the extreme - maybe even preposterous - examples of doing it wrong on purpose, then looking for the agile version of a process to save the day. I just don't get it. Maybe I've been around good engineering practices - ones that also use agile - too long and have lost touch with those folks out there "doing stupid things on purpose."
It turns out when behaviors like this actually do occur (and I know they do), it's not the lack of process or the wrong process - agile process or not.
It's a lack of leadership
