My Company's Agile is a Mess!
Help! My company is doing Agile wrong!
“My company says they are Agile but we really aren’t. It’s a mess.”
Have you ever wondered why are so many Agile Transformations a “mess”? And what does a “mess” mean exactly? Are there things you can do to help Agile deliver on its promise?
First let’s unpack what people mean when they say “The Agile Transformation is a ‘mess’”. Here’s a recent conversation I had with an Agile Product Owner:
PO: Our Agile Transformation is an Epic Failure.
Me: Oh? So you aren’t seeing an improvement in the delivery of software?
PO: Oh we are seeing software delivered faster and better than we’ve ever seen it before! Our financials results have doubled!
Me: Uh-huh. So what makes it a failure?
PO: Well people are confused, we didn’t feel like we were properly trained and no one seems to know what they are doing.
In this example, the “mess” was that Agile felt “messy” and they weren’t used to that. There are also cases where teams are not delivering results. Let’s stick to “messy” for today, and we’ll tackle “poor results” later..
Why do teams new to Agile feel like it’s a “mess”? Self-organizing teams, iterative work, responding to change - these are all concepts that feel “messy” compared to traditional ways of working. The traditional processes felt more predictable. Was waterfall actually more predictable or was it an illusion? Think back to a waterfall project you worked on, how often was the project missing dates, over budget or missing the financial result?
How can we get the results we want without it feeling so messy? Or do we just need to get used to feeling uncertain? And if so, how do we get our executives used to it?
Here are a few things that have worked for me.
Use your Retrospectives. With any challenge on an Agile team, my first question is “Did you talk about this in your Retrospective? And if so, what actions are you taking?” Teams can solve most problems if they put a little energy into it. If you’re not doing retrospectives, or you aren’t addressing and taking responsibility for the big issues, you are missing an opportunity to improve. As a participant your most powerful tool for change is the Retrospective. If you are having them, raise these issues. If your team is not having them, set one up! You don’t need to be the ScrumMaster to hold a Retrospective, anyone can do it.
Make Productivity Visible. I recently saw a team member create a visual report showing how much value the team delivered. This report kept the team aware that although life felt messy, they were getting better results. Tying the work to actual revenue or savings works great. But sometimes depending on how much lag there is in financial results, you may choose to also include a “leading” metric, one that you can see sooner. # of features delivered per month is a great, simple metric, and has a side benefit of helping with forecasting.
Help Bridge the Language. As a participant, you can help your fellow team mates transition from “process-language” to “responsibility-language”. For example, when a teammate says “We weren’t trained, no one knows what to do.” You might respond with “We’re a smart and capable team. What do you think we can do to move forward?”
We'd love to hear what worked for you!