Friday, June 8, 2012

Agile De-transformation


You have a high performing organization. The teams are self-directed. They can take business goals and work with the product owner to build a backlog, plan iterations and using pairing and test driven development deliver working software. They often delight the business.
Once you have transformed an organization into a high performing organization, how do you stop it? How do you de-transform it?

Why would you want too you ask? If we can identify what would bring an end to a high performing organization, we may gain some insight into what not to do. We may learn that the “don’ts” we identify are exactly what many managers do today unaware of the consequences.

So what is the master plan? In priority order, what would you do to bring a high performing organization to a halt? Here is a short list:.

  •        Commit the team to deliver software that was estimated and planned by someone other than the team
  •        When the team provides estimates that are higher you tell them to waive their practices so they can commit to the budget, schedule and scope as it stands


Is that all you have to do? Is it that simple? Let’s examine the impact of the above two steps.

By committing a team to a schedule, budget and scope you have taken away the team’s ability to be self-organizing and self-directing. The team not only does not have buy-in, they don’t have knowledge of the solution nor any confidence that it can be done.  What knowledge they do have says it can’t be done yet their feedback is ignored.

By the above actions, you have moved the team from emerging design and iterative and incremental delivery to big up front design with big bang development. Planning not only is a one-time event, it was done by someone other than the team. The ability to deliver working software every two weeks, receive and incorporate feedback and update the plan is now lost.


How about the second bullet point, what impact does it have. You have told the team that their practices are the reason the estimate was wrong. That the practices of agile utilized by the team are the reason their estimate is high and the estimate done by someone else is right.

Never mind that the “other” estimate was done by one or two architects and was very high level. You can ignore that the team took the original estimates and decomposed them into story cards. Discussed proposed solutions with the product owner and used planning poker to bring about shared understanding.

You are telling the team that they cannot leverage the skills they have learned and utilized to deliver successfully many time previously. Instead, the lower estimated is picked, not because it is nearer to the truth but because expectations with the business have already been set and no one wants to bring about the bad news.

Management has now set up the team for failure. If the teams resists, they are told they are wrong. You can imagine how demotivating such an experience would be.


As you can see, it does not take much to destroy a high functioning team and organization. A few simple directives and you no longer have a team but a group of hostages being held accountable to deliver something they don’t understand or believe is possible. The final insult is you have taken away the very tools that have brought them success.

How many leaders put their organization or teams in this very position? When given a high level estimate, instead of bringing the truth to the business, they relent and commit the team to failure. Instead of coaching their peers and the business they throw the team under the bus.

Is there a shorter list than the one above that can destroy a high performing team? I say yes. It is, remove the product owner.

Really? Remove the product owner? Is the product owner that important?

Absolutely! How many organizations attempt agile without a product owner? The product owner is the one that provides feedback as working software is delivered incrementally. Without feedback, how is the team to know if they are on the right path. If the business does not have skin in the game (see http://www.agileandleanatscale.com/2012/03/skin-in-game.html) they are not vested. They have no ownership for what is being built. They are dis-engaged by standers. What chance does a team have to build the “right thing”? What chance does the team have to “delight the business”?

As you can see, it does not take much to destroy engaged, self-directed and productive teams. All it takes is a leader that has little to no understanding of how agile works.