How to make Agile work for you
“Yes, but how can this work for us?”
This is the most common question in all of my Agile training. Many Agile coaches would answer the question as “Implement Scrum” or “Start using SAFe” or whatever methodology they use. And while there’s value in that, my recommendation is to run a series of small experiments to help you figure out what actually helps you get better.
It goes something like this:
Ask yourself: Why do you want to be Agile? Clearly define what success will look like.
Leveraging Agile values and principles, identify some small changes to how you deliver value to your customers. For example, start by only working on things that have a clear definition of what it will look like when the work item is complete.
After a short timebox (ideally 2-4 weeks), see if the changes moved you closer to your goal.
If they did - keep them
If they did but the results could be better - change them
If they didn’t - get rid of them
Repeat: Run another experiment that builds on the last one. Continue making iterative changes to how you work so you get better over time.
Not everyone finds this satisfying. Many people want a clear direction on which Agile practice to start first. And while this might provide some value, I personally have never seen that approach work: there’s always in-progress projects that prevent an immediate Agile adoption, and it takes time for many people to adopt an Agile mindset. Starting Agile practices iteratively seems to work much more smoothly.
Let’s see how this plays out by looking at some urgent problems that arose in one of my recent Agile Fundamentals classes:
Daily standups - the 15-minute alignment meeting each team conducts every morning - go on way too long. In addition, UX and QA people (e.g., the shared services) need to attend standups for multiple teams, taking up a larger proportion of their time.
The “Minimum Viable Product” (MVP) turned into their “Viable Product” upon delivery, which means that…
Bugs frequently emerged in their live product, causing understandable but unpredictable halts in development until each issue was fixed.
Just adopting an Agile process won’t immediately fix these problems. In fact, they might make them worse in the short term as everyone learns a new way of working. So leveraging what they learned during the training, the class came up with a potential experiment for each issue:
Standups. Strictly enforce a 15-minute timebox rule. Capture “extra” topics that would take longer than 15 minutes and create forums where only the necessary people work through them.
MVP -> VP. Lean into the idea that what’s released as the MVP will be sold and be live at customer sites. This means intentionally defining a minimal quality standard for anything released to customers.
Bugs. Test the product in an environment as close to live as possible - typically in a type of Staging environment. Make this a gating factor to the release in order to minimize the risk of bugs making it to customers.
Taken together, these experiments and the ensuing process changes they initiated have helped the company progress towards more efficient value delivery. The time saved by addressing these issues can then be folded back into exploring how to solve more customer problems.
That’s how Agile works for you: making sure that every small step you take helps you get even better than you were today. That’s the journey towards high-performance.