Source: Wikimedia Commons
“I don’t understand, it was a textbook implementation! I should have been able to do it with my eyes closed. ”
For once, I was talking to my gorilla willingly. Well not so much willingly. It was more I had no choice since the only other “person” in my home office was Hogarth. Of course, Hogarth didn’t seem to be listening. He was more intent on the garden just outside my window. I could almost see him cataloging the various plants. The long and hungry look he gave the ancient wisteria was troublesome.
Oblivious to this, I continued my rant. “I did exactly what they asked for, I executed letter perfect to the book. We had scrum rolled out to all twenty teams in record time. Heck, you couldn’t walk ten feet in their office without running into an information radiator.” Noticing Hogarth was not paying attention, I turned to glare at him. “You’re not helping me at all!”
Hogarth reluctantly tore his gaze away from the garden view. “Why do you need me, like you said it was a textbook roll out. What do you think caused the failure?”
“What do I think?…” I stared at him open-mouthed. “If I knew I wouldn’t be talking to you now would I?”
Hogarth just kept looking at me.
“Fine!” I threw up my hands. “Let’s see. The first problem I noticed was the timebox kept getting broken.” I waved my hand at Hogarth, “That wasn’t it though, they actually had existing SLAs and agreements in place that supported interrupting the teams.”
“Existing processes you say?” said Hogarth. “How might you have learned about them?”
“I did learn about them!” I grumbled. “I just didn’t learn soon enough.”
Hogarth nodded. “Uh huh… Tell me what was it you wanted me to do again?”
Was he serious? “Damn it, Hogarth, I want you to listen to me. Just listen, don’t try and fix the problem. Don’t be the damned expert, just listen so I can work this out…”
My words trailed off to nothing. Hogarth had done it to me again.
You have to be agile to be successful in agile
Note: This blog is based on the article I had published on AgileConnections.com in January of this year.
The problem with the classic playbook model is it follows a fairly standard set of steps. Sure, you might alter the timing a little, the overall process though is pretty much set down. No, it’s not as bad as that call center script the agent used on you last week. However, it can still lead to pretty upset customers as you try and roll out something that doesn’t work for them. “But I was just following the plan” isn’t going to save your engagement.
Even reaching all the way back into my project management days, I realize that I understood this unconsciously and managed to suppress that unconscious knowledge time and again in order to “follow the process” like I had been trained to do.
Perhaps it was my background in 1990’s era computer game technical support, where every customer’s problem was just a little different or just plain common sense that drove that not listened to, subconscious realization. It would take a decade of project management and a good five years of agile coaching before I came to the conscious understanding that it wasn’t the process, it was the ingredients.
Think of each customer like an episode of Iron Chef (America or the original Japan). Your judges (customers) are different every time. The live audience (additional stakeholders) will have a different energy. The secret ingredient (unique challenge) is always different. And your sous chefs (team) might even change from challenge to challenge.
What is almost always a constant though, is your pantry (tools) and basic kitchen appliances (core process frameworks). Having a strong mastery of these cooking basics allows you to assemble ingredients in unique ways and cook them to meet the needs of the customer.
What are my “Go To” ingredients and kitchen appliances, we all have them? Bobby Flay is going to reach for BBQ of some kind. If Michael Symon doesn’t use bacon at least once we think he’s ill and Mario Batali was sure to reach for some kind of pasta. You could also count on the blast chiller and ovens getting used in every episode.
So what do I always reach for?
Three ingredients and two appliances.
Three “Go To” Ingredients
Education is a key to any transition. I’ve learned that education normally needs to happen early, and it needs to be organization-wide for it to be most effective. If teams are trained differently on what agile means, it can lead to what essentially amounts to language barriers. Educating everyone at once leads to shared understanding and support. You can read my Agile Connections article for more on my Education First recommendations.
The principle here is “Do no harm.” When you first start an agile transformation, be it as a new hire or in a new project, you are almost always an outsider. You need to build trust before you can make a difference. The best way I’ve found to build relationships and trust is through asking questions and listening. Until you understand, you can not help guide change. I delve more into building team relationships in this Agile Connections article.
This phase is what most people think of when they think of an agile transformation: the agile coach rolling up his sleeves and diving in to help individual teams. Doing hands-on facilitating with one-on-one coaching is a vital part of a transformation.
My key component for a successful agile transformation is to focus on one thing at a time. After engaging with the team, it’s typical to come away with a dozen observations as well as the team’s own reflections from their retrospectives. When faced with a huge list of things that can be “improved,” it can be very easy to start tackling it all, but you should fight that urge.
In agile, we coach teams to focus on one user story at a time, and it’s no different for improvements, impediments, and blockers. Start a team backlog for things the team wants to improve. Have them pick only one thing to work on at a time, and when they reach that goal, move the “story” down the backlog.
Two Key Appliances
Inspect and adapt cycle
One of the most underused agile tools is the retrospective. We tend to limit retrospectives to the team level, focusing only on the previous sprint. If you replace the tires on your car and ignore all other maintenance, it won’t matter how great those tires are—eventually, the car will stop running.
Retrospectives need to move beyond the team to the entire organization. You must apply the principles of continuous improvement to all levels of the organization on a constant basis.
And remember, inspect and adapt are two separate steps. We can be really great at finding problems, then do poorly on fixing them. Without the follow-through, inspection is pointless. You need to create an organization-level impediment backlog that is tracked and managed by the leadership team.
Assessment & Self-Supporting Metrics
People in any organization have a driving need to know how they are doing. In the case of an agile transformation, we always want to know two things: When will we be done, and is this agile thing working? To this end, metrics provide a vital service to the health and well-being of an organization and some kind of organizational assessment tool tells us if the transformation itself is being successful (You can be shipping tons of new value and still be failing).
With metrics, as I advocated in my previous blog, “Metrics: The third rail of agile adoption” you need to have interlocking metrics so you don’t fall afoul of Goodhart’s Law and have the teams gaming the system to satisfy leadership’s desire for some imposed goal. Using metrics responsibly is also vital. I give detailed advice on the responsible use of metrics in this article.
For organizational assessment, be consistent. If you measure one car in miles per gallon and the other in feet per second, you just end up confusing things. A common set of assessment tools allows everyone to track to the same understanding. I delve more into how to pick a good assessment strategy in this Agile Connections article.
The Cookbook doesn’t care about Frameworks
One thing I want to make sure to call out. Everything written here is totally agnostic of what frameworks or methodologies you are putting in place. Whether you are using Scrum or Kanban, SAFe or LESS, or whatever my go to things don’t change. Think of these frameworks and methodologies like the set of an Iron Chef. I don’t care if I’m in LA or New York, inside or outside. At the end of the day, I’m still going to reach for the same core ingredients and tools to roll out whatever agile framework is best for the customer.
Am I an Iron Agilist?
Okay, I have my “go to” ingredients and appliances, so what? Plenty of challengers have faced the Iron Chefs with a “go to” approach and failed. Am I winning any Iron Agiist competitions?
Well in one of my most recent agile transformations I have close to two years of data showing the before and after of their agile transformation. In a twenty team transformation, the overwhelming majority of teams saw thirty percent or more improvement in predictability, reduction in cycle time, and increase in velocity. They all also saw strong improvements in organizational maturity and happiness.
The biggest change always happened after education. After a team had gone through one of my two-day training, they always saw a marked improvement in their metrics.
Oh, one last thing. You know how every Iron Chef tries to use the Ice Cream maker and it almost always fails (trout ice cream anyone?). Be on the lookout for your agile ice cream maker. For the longest time, my ice cream maker was the C-Suite. I had to learn how to work with them to advance as an iron agilist.