Sometimes I feel more like a medical doctor than an agile consultant—and my clients resemble a certain type of patient.
You know the one: the man who comes into the doctor’s office complaining of general malaise and a lack of energy. When the doctor examines him, she says, “Didn’t I see you for these same symptoms six months ago? I recommended behavioral changes—a better diet, vitamins, and more exercise. How did that go?” The patient responds, “Well, I started eating more healthfully, but then I kind of let that slip. And the vitamins were expensive, so I stopped taking those. As for exercise … well, it’s a good idea, but I have deadlines to meet, and work doesn’t get done in the gym.”
Just like when teams are transitioning to agile, making so many changes all at once can be hard. But in order to see progress, you have to commit, and when something starts working, you have to keep it up.
Start with Agile Training
When I ask clients about their symptoms, I’m told they want their development team to be agile so they can go faster or deliver more. If I ask again, I frequently discover that what they really want is more predictability.
My prescription starts with training followed by coaching. Training has its failings, but starting this way gets everyone off on the right foot, shows that the whole team is committed, and, perhaps most importantly, sends the message that the company wants to work like this and is ready to spend the time and money to really do it.
It also helps the entire team establish a common agile language. Everyone has heard of agile and has some understanding of what it means, but in any given team you’ll find many different interpretations of what agile is. People may remember the bit they like most; more often, they remember the bit they dislike most. Putting a team in a room together for a couple of days allows them to agree on a common understanding and expose misunderstandings.
Some teams can grab the ideas and just make them work. Most teams benefit from a little bit more help, so I frequently revisit teams after training to help them implement, refine, and improve their application. The teams I continue to revisit are usually successful.
Add a Regimen of Technical Practices
Following training I prescribe regular iterations, a physical board, planning meetings, stand-ups, and retrospectives. But just like someone who signs up for the gym on January 1, it’s not uncommon to hear of a team that started with good intentions and then let the actual practice fall by the wayside. Physical boards become electronic, stand-ups are scheduled less frequently, planning meetings become abridged and those who aren’t managers skip them altogether, and after a couple of retrospectives that don’t change the world, the team decided to save their time.
Having an experienced coach can help you avoid some of these traps. But if a team is supposed to be self-organizing and its members decide to drop a practice, is it right to stop them? When developers aren’t active participants in the planning meeting, boards become simply a means of work assignment, and stand-up meetings are merely short status reports, then tools intended to give workers authority become the tools of the micromanager.
I prescribe a program of technical practices to go with the iterative working—specifically, starting with test-driven development. The teams that stick to the prescription see great improvements on both the technical side and the process side. Sure, you can run agile processes without the technical side, but it is far more effective when you put the two together.
Unfortunately, too few follow through with the technical side. It might be that iterative working alone relieves the worst of the pain, so the driver for change goes too. One might blame managers who don’t want to spend more money or who see the costs coming before the benefits. But one might equally blame the developers who say, “TDD won’t work here” or “My code is good enough” and either don’t actually try doing it or give up at the first challenge.
Whatever the reason, it’s frustrating to see teams not reach their full potential and continue to struggle with bugs. The cost of training and coaching is easy to see, but the cost of bugs—both direct cost and indirect cost caused by disruption and schedule slippage—doesn’t show up as a named line item.
Once a team is working well within its new agile process, it’s time to change the focus to the requirements side and work with the product owners, managers, and business analysts. But again, if the immediate pain has gone, so, too, has the motivation. If the requirements side doesn’t take its medicine also, improvements will be stunted and the team’s full potential will never be realized.
User Comments
A nice post. I fully agree that proper training plays a key role in the successful transition to Agile development methodologies. As Allan pointed out, the shift to Agile involves two important aspects -- process and technology. Unfortunately, most firms focus only on the latter, resulting in failed projects.
I believe that the key to a sucessful switch to Agile methods hinges on clarifying the roles and responsibilities of teams in the new scheme of things. As with any major organizational initiative, the move to Agile creates a certain degree of confusion. Companies need to take steps to clear this confusion and ensure their staff members are able to adapt to the change. At the end of the day, well-defined processes pave the way for effective use of technology.
Thanks, glad you like it.
I'm far from convinced that thw way roles and responsibilities are define makes things any better, in fact I think it may make things worse.
I believe that people define themselves in terms of their identity and it is that sense of self-worth and identity that infroms what people actually do far more than anything it might say on an R&R document.
Besides, when R&R are handed out its another form of top-down control.
I'd far rather work with people help them find how they can work together with everyone working in terms of who they think they are and where they feel responsible.