Typically, companies who attempt agile methodologies whether Scrum, XP, Crystal, etc, do so because someone in a position of influence has read somewhere that the new way to improve quality and deliver value is through the use of these new(ish), trendy methods. What they usually aren’t prepared for is the loss of familiar project tracking artifacts, not that there are none in agile techniques; the new artifacts simply measure different things.
It is not uncommon for a newly agile development department to stress that they are ‘doing iterations’ and holding stand ups. Where they usually stumble is that they assume that the test-driven development and pair programming aspects are optional elements of the process.
Often, project management assumes that they get half the output from their developers when they’re pairing and that writing tests before code is wasted energy because it doesn’t advance the project’s code base.
Wrong. And wrong.
After presenting these concepts to a large group of mid-level executives at a leading insurance company, the QA manager raised her hand and asked the amazing question, “That’s all very interesting but what do we get besides better quality code?”
Besides better quality code?
Unfortunately, this is typical in companies that have invested time and money training staff in heavyweight development processes. They reason that since they’ve invested so heavily, all they need to do is apply the appropriate pressure and enforce some mandatory documents and the process will rescue them from budget overruns, project slippage, etc.
We know they are wrong because the facts show that these heavyweight methodologies do not insulate companies from costly failures. They sure have a lot of documentation that says what they would have had though.
These companies would be better off to shelve the big methodologies and hire a few agile coaches who can teach see why so many companies are switching to agile.
Start small and work your way into it. Or hire us to get you set up and started.
Occasionally, we are asked to come into a company under the radar. We are there to stealthily stir up some quiet resistance among the employees and create some enlightenment for the management by example.
Sometimes it works, and sometimes it doesn’t. The key is usually that there needs to be a relatively high level sponsor who can insulate the agile team from efforts to sabotage the project.
And there will be saboteurs. Usually managers who fear losing control because of the transparency of the agile process are the worst. They have connections up the ladder and they can expose what’s going on with a few judiciously placed calls. They can also put co-conspirators on the project as developers or they can make sure the project is only assigned developers without the necessary skills to contribute productively.
The other likely saboteur is the developer (sometimes a co-conspirator of the manager’s) who sees his position as a job rather than a profession. Change is always uncomfortable, but agile development is more uncomfortable than other types of change because there is no where to hide.
Some senior developers arrive at their positions because they have survived in the organization long enough to get there. Others have simply become complacent over the years.
Every standup requires each team member to briefly explain what they are worked on yesterday, what they are working on today, and what’s holding them back. It’s all out in the open.
To borrow a rule from my good friend Gary Evans (www.evanetics.com) in this situation, there are four Es you should apply save your sanity:
Makes sense, doesn’t it?
Where are you?