The Secret to Organizational Agility (Revisited)

I did a post late last year called The Secret to Organizational Agility. In that post I suggested that for a company to be truely agile, they had to break dependencies at all costs. I got a bit of flack for that post… the general consensus being that organizations were full of dependencies and we had to manage for that reality.

No argument from me there.

I maintain though that if you really want to be an agile organization… if you really want to be responsive as a company to changing market conditions…. you must find a way to break as many dependencies as you possibly can. Any dependencies you leave in place are going to incur a cost… a tax if you will… on your organizations ability to adapt to changing conditions.

That begs the question then… just how agile do you want your organization to be?

When we leave dependencies in place, the inputs to one team will be constrained by the output of the other teams. This is why Larman and Vodde make such a strong case for feature teams in their book “Scaling Lean and Agile Development”. When you can have a single team work across the entire software stack under the direction of a single business stakeholder… that is pretty darn agile.

When we are talking about a large application where feature sets have to share common behaviors or a common look and feel, you are creating dependencies that reduce the team’s autonomy. When you have component teams that are building component features, features that will ultimately be integrated into some larger customer facing feature… you now have dependencies that limit the decisions each team can make about the product.

Said another way, one team’s outputs will become the inputs for each of the other teams.

There will be greater context costs because you’ll have to put structures in place to align your teams with the objectives of the organization. There will be greater coordination costs because your teams will have to operate with an awareness of each others activities.