How to Avoid Agile Transformation Pitfalls
Pitfall 2 - Agile transformation as a traditional project
Over the years, I have been part of many organizational transformations. Almost without exception, the goal was a worthy one. Some did succeed, but many of these transformation efforts failed, either entirely or at least to a large degree.
The reasons for failure were often the same. I listed the ten most painful pitfalls in this article. Understanding the possible pitfalls is step one. Then, you can start fixing the situation.
Today, I will discuss what helped me successfully avoid the pitfall of treating an Agile transformation as a traditional project. I will put the spotlight on the practices I experienced that were particularly helpful for me, rather than a complete guide.
Traditional project approaches focus on upfront planning of the work to create the desired output. All steps are meticulously analyzed to ensure the plan is as solid as can be. The premise is that the delivery of the output will result in the desired outcome. That cause and effect are known.
The worst Agile transformation I witnessed had such a traditional plan. It described how the first weeks would be used to communicate the transformation and how and when the teams would be formed, trained, and coached. It had a strong focus on performing the tasks. Because showing that the Scrum training had taken place was considered to be the same as having everyone on the right knowledge level to work with Scrum.
Alarm bells should be ringing when people wish to introduce Agile in your organization using a traditional project management approach. It justifies the question: do these people know why you would want to work in an Agile way in the first place?
All the things true to using Agile to create your product or provide your service apply to Agile transformations as well. You may have ideas that will benefit the organization, but you can’t know for sure. Also, there may be ideas that only come to you while you are well underway in your journey. You need to uncover better ways to create value. It doesn’t work to simply implement an off-the-shelf approach. Instead, the transformation will be a discovery.
As the transformation is a discovery, the tasks you complete and the output you generate are no measure of success. Hence, you need to understand what the desired outcome is and which impact you wish to make.
Objectives and Key Results (OKRs)
One way of defining and moving towards the desired outcome is by using Objectives and Key Results (OKRs). We are using it to great effect in many of our transformations. We together establish what we wish to achieve, resulting in objectives. Then we determine how we can assess if we are moving towards success. This we do by defining key results.
For all the things we do during the transformation, we know how it will contribute to achieving the objectives plus how we can assess our success by measuring the key results. In fact, we are not aiming to justify our work by finding ways to link it to the objectives. Rather, we start with the objectives and then identify what would be the most effective things we can do to bring us closer to do objective.
OKRs have helped us to focus on the work that brings actual value. Completing the work isn’t a measure of success. Getting closer to the objectives is.
Another great tool is Evidence-Based Management. It is also goal-based and very much aligned with using Scrum.
Milestones
Many believe that Agile approaches rule out the use of milestones. I don’t agree. However, I do often see how milestones are horribly misused. They are almost always about output and deliverables. I already discussed how you can’t know upfront what you need to do to meet your objectives.
But you do know what you wish to achieve and when your transformation is a success. You can certainly add a date to this, like “By December 1st, we wish to have improved stakeholder satisfaction by xx%.” (when you have established you care for stakeholder satisfaction improvement). These milestones allow you to find alternatives to increase stakeholder satisfaction based on what you have learned along the way. Done this way, milestones help bring commitment and focus on what really matters to the organization.
Working in Sprints
I facilitated many transformations where we worked in short iterations. Every iteration, we reviewed if the things we had produced were actually bringing us closer to our goals.
I look most fondly back to the transformation when we decided to use Scrum. The transformation team would have Sprints of 2 weeks. We defined a longer-term goal that stated what we wished to achieve within 3 months. Every Sprint we had a Sprint Goal which was an objective to bring us closer to the Product Goal. Then we would decide what we would do to achieve the Sprint Goal.
We had our Daily Scrums and ended the cycle with a Sprint Review and a Sprint Retrospective. The Sprint Review was a collaborative session with everyone who worked at the department or who was an important stakeholder. We showed what we had produced including our findings and had great discussions with the attendants on what we had achieved and what we should aim for next.
Using Scrum for our transformation efforts helped us to focus on our objectives and still be flexible in the way to meet these objectives. And most importantly, we allowed everyone to chip in. It was so successful, that we since then often turned to Scrum for similar endeavours. And we have coached others to successfully use it.
Scrum may not be your cup of tea. Then, why not use another Agile approach?
End note
In this article, I have focused on:
embracing the desired outcome of the Agile transformation;
acknowledging that you can’t plan everything upfront;
you may have milestones, but these should be about what you wish to achieve, not what needs to be delivered;
regular feedback moments with the important stakeholders, like the people of the impacted department(s).
I also presented some examples of what worked for me multiple times in different settings. I am convinced it works in other environments too. Perhaps it’s of benefit to you.
What are your thoughts on this? Do you have additional tips? Please let me know in the comments!
Why would the bigger goal be clear? Maybe all you know is a broad direction. And while being on the road you find out that the goal changes with your travel and learning.