Monday, February 14, 2011
Top-Down vs. Bottom-Up Agile
Interestingly, I’ve never actually experienced what I would consider a true top-down agile transformation. Oh sure, I’ve been at places where managers, directors, and even executives say all the right words, but when push comes to shove, it’s usually business as usual; pushing forward to hit some arbitrary date or BDUF in Scrum clothing or some other nonsense...folks just determined to not understand how software development actually works.
In many of the top-down scenarios I’ve seen or heard of, the dev teams feel as if some new silver bullet process is being forced on to them. Here we go again, the big wigs found something shiny in the latest trade magazine while they were on the pot and now we all gotta learn new words and have new meetings just to keep doing the same ole thing.
Unfortunately, bottom-up or grass-roots initiatives don't seem that much better. Sure the teams may have adopted some better engineering practices such as TDD, pair programming or continuous integration, but to what end? The business is usually still some level of disengaged from the team; or the organization as a whole hasn’t adapted to produce a constant flow of value through its high performing software teams.
Eventually it seems, if the teams become high performing, the team members realize that the bottlenecks to creating value lie outside their sphere of control and then get frustrated. This tends to lead individuals down one of two paths: either find a new employer or become detached from the organization and slump back into a zombie-like status quo.
Which one is better?
Obviously neither! I guess if you forced me to choose, I’d pick bottom-up as the lesser of two evils...but that’s just because I have seen and heard of too many botched top-down, process-driven, prescribed, checklist style agile transformations. At least with bottom-up something of value is created whereas with a botched top-down it’s usually just wasteful. Also, with some luck, maybe some mid-level or senior leader may realize how to actually get something done with these locally optimized high performing teams.
So what to do?
As indicated above, the answer lies in the middle. The perfect situation would have the enthusiasm and inertia of a bottom-up style transformation with the trusting top-down support needed to create an environment in which the transformation can flourish.
Sounds like a pipe dream, I know...but it makes sense right? We are basically saying that to even have a chance of optimizing the whole, everyone from every layer of the organization has to be involved. Anything else will be a sub-optimization. Everybody must question the status quo, empower the most appropriate nodes of responsibility and above all continually reflect, learn, and adapt.
It is in this way the transformation will be successful. Oh, by the way...what exactly are we transforming? Software development; from a necessary evil into a competitive advantage!
Posted by Matt Barcomb at 1:52 AM