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.