To my enormous delight, the Project Management Institute has finally come out with it’s own Agile certification.
See http://www.pmi.org/agile.aspx for more details.
Although I now know some great project management professionals who embrace taking an agile approach, some of the worst projects I’ve been on have been made so by project managers wielding their PMPs to great effect: namely enforcing that most noble of business laws “If something doesn’t work do more of it”.
In reading the current batch of blogs about agility, every now and then I come across someone noting that “testing after development is not optimal”. Or some such.
Anyone mind if I’m a little more blunt?
Testing after development is stupid. Stupid. STUPID!
Of course, I know that now. The thing is that for a long time, before I was introduced to the idea of Test Driven Development, I kinda knew it. There was always that ghastly feeling “What will they find when they test this? Or worse, when we don’t have time to test this and the users start using it? Will I accidentally ruin someone’s livelihood because we didn’t check…?”
It was a miserable feeling. But until I learned about TDD it tended to end up in the “too hard” basket. I’d step over it. We all stepped over it.
So where else are we stepping over stuff? The Kruger and Dunning Effect says that stupid doesn’t know it’s stupid because it’s too stupid to know it’s stupid! More kindly, the good folks at Landmark Education, champions of having a great life in this life, point out that we’re disempowered by the stuff that’s living in “Don’t know that we don’t know”. Either way, it seems to me that once we realize that something is stupid, how on earth can it be ok to just let it carry on? It’s not.
I see people’s lives being trashed because they’re stuck in a culture where it’s ok to work 70 or more hours in a week. The crime is that they don’t have to, there are best practices proven to work in multiple contexts that would get them home on time. It’s what keeps me going in the face of a whole ton of resistance – I know that things can be better. I couldn’t sleep at night if I didn’t do something about that.
The presentation two days ago went well. The contractors seem excited, the line of business folks emailed me to say that they are keen to take this new approach, and on the whole, we took a big step forward.
That said, a few feathers got ruffled. Figures in the project management office got wind of what’s happening, and seem very threatened by it. According to previous experience, and that of all the great and good who write on the subject, this is a healthy sign, and would indicate that we’re right on track!
At some point, they’ll realize that we all want the same thing: to maximize value, minimize waste, and raise the company’s game. What, you want our employer to do worse?
I’m not sure, but every time I review this story or tell it to others, it has me wonder if this isn’t one of the biggest scandals in the history of productivity and process.
Based on what I’ve read in Agile and Iterative Development – A Manager’s Guide by Craig Larman, repeated in Agile Data Warehousing by Ralph Hughes and apparently confirmed in Wikipedia, it would seem that my unease with waterfall has some basis.
I’m going to quote Hughes directly (Hughes, p.48):
The vast majority of corporate IT departments today still utilize methods based upon the waterfall method. How can we foster the right frame of mind among IT managers that they will give Scrum/XP a honest try? We will draw upon two stratagems. First, point out that the predominance of the waterfall method is due to a tremendous error on the part of the U.S. military when it was codifying software development methods, and second, provide a long list as to why Scrum is many times more effective than a traditional approach. We deal with the military’s SNAFU here, and leave the advantages of Scrum for the next section.
The standard waterfall approach became the standard paradigm only through a series of mistakes. In 1970, W.W. Royce first identified the classic waterfall categories as only “essential steps common to all computer program developments, regardless of size or complexity.” In the second half of that same paper he clearly advocated an iterative path for progressing through these steps. To pursue the waterfall steps sequentially from analysis through coding in a single pass, he cautioned, “is risky and invites failure.” The single-pass waterfall method is only the simplest possibility for organizing a development project, and he suggested that “it only works for the most uncomplicated projects.” [Royce 1970]
Undaunted by these warnings from Royce, the Department of Defense proceeded to make the single-pass waterfall method its standard approach for systems development with its official specs MIL-STD-1521B and MIL-STD-2167. One can only speculate that they read just the first half of Royce’s paper and missed the later sections that contained his recommendations. The MIL-STD-2167 spec was particularly influential and soon propagated into many further standards both within the U.S. and internationally. Yet, when interviewed in the mid 1990s, the author of MIL-STD-2167 admitted that he had been unaware of the notion of time boxes when he drafted his recommendations, and with hindsight he would have strongly advocated iterative and incremental development methods instead. [Larman 2004 and Oestereich 2006]
In 1994, DOD replaced MIL-STD-2167 with an IID-promoting standard. Unfortunately, the other governments and standards bodies that based their methods on the earlier spec did not update their policies to match, so the single-pass waterfall approach sadly remains the basis of many methodological standards today. However, one can argue that to cling to a non-iterative, incremental approach is to persist in making a known, fundamental error in software engineering.
(Links to attributions mine. “Oestereich 2006” attributed by Hughes as “www.isqi.org/isqi/deu/conf/conquest/2006/slides/B3.pdf (accessed Feb 2007)” but not available at the time of writing this blog post.)
I’ll be blogging more about my understanding of the history of agile, but the short version is that the failure of waterfall did not go unnoticed. Overtime, folks realized that doing more of some things and doing less of others worked better, and that has lead to agile as we know it.
Pitching Scrum to stakeholders tomorrow. I’m hoping this will start the game-change. Or game raise, at least.
This blog is going to be used to promote and develop agility in the workplace.
I’ll be recording my actual experiences and what I’ve learned from them, and I’ll also be looking into the history of work and how come we do what we do the way we do it, and could we do it differently to give ourselves a better chance of success.
Agility has been mainly adopted in the world of software development using a variety of frameworks. It’s cultural shift and what that makes possible is applicable to all areas of knowledge work. Is it also applicable elsewhere? I would argue that it is, that any project that requires a large portion of work that cannot be pre-defined is a suitable candidate. I want to see this become a major topic of discussion.
I’ll also be using the blog to capture snippets of thought from my mobile WordPress application as I’m out and about. These thoughts may well end up being fleshed out into full blown posts. Who can tell? Not me! But this blog can exemplify the great principle of “Make it visible, periodically inspect, then adapt”.