I drafted this post over two years ago, and I’m only just getting to post it. Time has passed, but I feel the post is still relevant and current. The topic originally started on the ScrumDevelopment news group as a discussion about flaccid Scrum.
George Dinwiddie posted an excellent comment in which he discusses some of the difficulties of transforming an organization. This is a deeply complex topic with many subtleties of context, as experience coaches will attest. Some of the problems of organizational transformation appear simple and straightforward; but further investigation reveals layered complexity. In a few short paragraphs George nicely outlines some of the difficulties that coaches encounter:
In my experience, most organizations have much room to improve both their project management and their technical engineering practice. Those that start with Scrum seem to improve their project management practice enough that the deficiencies in their technical engineering practice become more painfully obvious. The answer is simple and obvious–improve the technical engineering practice. The way to do that is not so easy, however.
For example, Tim Walker suggests “Attention to technical excellence and hiring motivated people are required for it to be successful.” As true as this is, it’s no way for an organization to get from where it is to a desired state of being able to reliably create desired functionality in their software.
People cannot suddenly be attentive to technical excellence. They must slowly acquire the awareness and deeper understanding that they lack, or they would already be attentive. Hiring motivated people suggests that those doing the hiring will suddenly be able to understand what sort of motivation is required, how to discern it in candidates, and follow through with this criteria in preference to the criteria they’ve been using.
And what would you do with the people you have now? Those that are presumably not motivated toward technical excellence? Fire them all and replace them? This is the HR equivalent to the total rewrite of a legacy application, and it has some of the same problems. There is a lot of domain knowledge hidden in there–knowledge that would be difficult to find written down anywhere. The new must achieve the competency of the old before it can begin to surpass it–until then, no benefit is seen. The new will be starting in the same context as the old, and therefore is likely to produce something with a similar organization (or lack thereof).
The bottom line is that the developers have to learn to /recognize/ what is “better,” they have to learn how to /do/ it, and the cultural context in which they work has to change such that it really is important enough to have happen. Depending on where you start, that’s a lot to change all at once. It can take a lot of time and energy.
At the risk of sounding like an industry shill, this is where a Scrum or Agile coach is really necessary. They help the organization recognize what is “better”, and they help team members do it.