Monday, February 14, 2011

Top-Down vs. Bottom-Up Agile

Now, the systems thinker inside me knows that both top-down and bottom-up are just local optimizations. The correct (or at least better answer) lies somewhere in the middle. Surprise! Like most things in life, balance is better :) It’s also very likely that the decision of how much to one side or the other is dependent on the context of the given organization. Dang it! No one-size-fits-all solution again!

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!

1 comment:

  1. Matt,
    I would consider the last situation you mentioned as being the "bottom up" people are looking for. I think it's up to the developers to come up with ideas and methods to make their team more successful, not the management. All the management needs to do is be receptive to new ways of delivering software and communicate that throughout the organization.

    Therefore, I think the initiative lies squarely on the team's shoulders. If you aren't constantly learning about your craft and experimenting with new methods, you're falling behind. The only real problem is when management is truly against this type of thinking, and, to some degree, this could be a marketing problem on your end. Your team needs to prove why it's more efficient the way you're proposing.

    Now, sure, it can be the case that management won't change, and it seems the only way is out. However, I think most organizations want to move with the times,and the right marketing skills from the team can be convincing enough to get a shot. Actually succeeding when you get that shot, is another matter ;)