This post is largely inspired by David Anderson, whom I had the pleasure of meeting at an AgileAustin meeting several months back.  In this post, David proclaims to “just say no” to agile transition initiatives.  He spells out in great detail why he believes they are risky.  Here, I would like to explore a few reasons why such a transition might fail.  This may seem odd given that I head up an agile software consulting company, Headspring Systems, and we offer agile coaching.  The big differences I explain below:

Why agile transition initiatives might fail:

• Success is not defined and measured
• The executive makes a “vendor” or external “coach” responsible for the transition
• Employees are incentivized to protect their “kingdom”
• The company culture does not have self-improvement baked in

Success is not defined and measured

As with any project, an agile transition initiative must have success defined.  First, in my opinion, a special initiative just for the purpose of improving the delivery of software is indicative of a weak self-improvement culture.  Even so, everyone participating should understand what success looks like.  Otherwise, you don’t know when you’ve arrived.  The end date of the initiative is not the definition of success, and you must have milestones along to way to see if you are on track. 

What I have just said brings in a big problem.  How do you measure the “agileness” of your organization.  The agile manifesto provides no such metrics, so you have to define your own in the context of your business.   The organizations who already have metrics around business agility, responding to the market, etc, probably already have a culture of self-improvement, in my experience.  Even if you decide on an agile transition initiative, you have to define success, and you have to measure it.  If you don’t, I guarantee that you will be disappointed with it.

The executive makes a “vendor” or external “coach” responsible for the transition

If you have handled the first risk and have defined success and success metrics, you likely will not find a vendor who will base his payment on your metrics.  After all, the metrics likely call for less project failure rate, faster response times, etc.  You probably can’t measure these things in less than a year if you really want objective metrics and not one optimized for short-term results at the expense of the longer term.  A vendor might want:

• # of people trained
• % of teams using an “agile” project management tool
• # of teams with an embedded “agile champion”
• # of successful iterations

It is really easy to accomplish the above metrics and still not make any material change in the organization.  I have worked with a client that did something similar to the above.  Most of the teams starting using some new Scrummy project management web application for project tracking.  They declared that monthly status meetings were now iterations.  They declared a member of the team to be the Scrummaster (and sent that person to training).  Overall, the same organizational problems persisted.  Vendors cannot produce real change in an organization unless the organizations executive leadership alters the culture in a meaningful way.

Employees are incentivized to protect their “kingdom”

Extreme Programming talks about collective code ownership.  In short, no line of code belongs to a single programmer.  The entire team is responsible for the entire piece of software.  This collides with the notion that if everyone is responsible, then no one is responsible.  It is counterintuitive, but with a team working closely together, it does work in practice. 

To have an agile organization, this notion must be scaled to higher-level concerns.  Each person in a department needs to be able to help improve any process.  In many cultures, it is not acceptable to call out inefficiencies in a process if someone else is the “chief administrator” of that process.  It is somehow considered to be an attack on that persons kingdom.  In the Office Space culture, if a certain process went away, that employee might be at risk of being laid off.  This is a dysfunctional culture.  Good people are constantly working themselves out of a job.  Then, they go on to the next job (at the same company).  Folks who cling very tightly to the way they work at the expense of improvement will actively work against a forced initiative of improvement.

The company culture does not have self-improvement baked in

If the company does not have self-improvement infused into the heart of the culture, then an agile initiative is not just an agile initiative.  It is an initiative to change the fabric of the culture.  Did you just notice the scope creep?  Changing a company culture is very difficult, and you cannot have a project for that purpose.  It really needs to be a conscious stream of leadership from executives who are setting the example for all of the employees.

Conclusion

I agree with David Anderson.  Just say no to agile transition initiatives.  Say yes to a company culture of self-improvement.