Many times we (as Agile coaches) quickly discover that the Agile frameworks used in our client organizations are deeply incompatible with…
- The nature of their work
- The flow of their work
- Their overall organizational context
- And the list goes on!
This is especially challenging when the organization has chosen to quickly scale a single framework with brute force while using a one-size-fits-all approach without considering systemic root causes to their performance issues. In my experience, this often happens when management aims to address symptoms that manifest at their flight level for immediate pain relief and inadvertently neglect to probe more deeply into systemic causes.
As a result, the teams doing the work struggle through these mandated ways of working that ultimately lead to more problems than they solve!
This blog post is about my experience when Kanban was a better fit than Scrum, the SAFe caused more problems than it solved, and the organization was afraid to let go and let teams explore what Agile Ways-of-Working works best for them.
I’ll be sharing pieces of the journey that led to a 300% improvement in Lead Time along with three key questions that can help keep you on track if you find yourself in a similar spot, which are as follows:
- #1: What problem were you brought in to solve? And what Agile good practices could help?
- #2: Is the problem actually the problem? Or is it a symptom of something else?
- #3: If it is a problem, are the current Ways-of-Working helping or hindering? What does the nature and flow of work tell you? What about the organizational context?
This blog post is structured according to those questions where I share the success story that came from carefully answering each one. Hopefully the article will be helpful resources if you find yourself navigating through the same murky waters!
#1: What problem were you brought in to solve? And what Agile good practices could help?
Like most Agile Coaches, I started by seeking to understand the measurable problem I was brought in to solve. And because the client wanted quick results, I also looked for what Agile good practices might help to secure some early wins.
In the specific experience I’m drawing upon for this blog post, this was, “We need to improve this department’s predictability to at least 80%”.
The landscape
The teams were using Scrum in a SAFe set-up based on a decision 5 years ago to centralize everything Agile under one big SAFe roof. Managers and stakeholders seemed to like using PI planning as a really large batch transfer that happened every 3 months. The outcome amounted to quarterly Gantt charts from each team detailing at a User-Story level how they intended to work on the massive influx of work items the business pushed onto them to complete. Although stakeholders actively invited the Product Managers and Product Owners “to say no” to taking on more work then they could handle, during my interviews I learned that the unspoken cultural norms made it very unsafe to do so.
What the data showed
Team interviews and high-level value stream maps indicated that, like most organizations, the teams were flooded with work due to a push-based system, features were bundled into projects creating very large batches, and there was a lack of prioritization due to minimal program or even backlog management. The result was a push-based system that was “going through the motions” of Lean Agile but not experiencing the benefits.
Although Scrum is a pull-based system, it wasn’t being used in that way. To get the system heading back into the right “pull-based” direction, I recommended we start with some known good practices for balancing capacity with demand and optimizing flow, such as unbundling features from projects to work in smaller batches, practicing regular backlog refinement, implementing clear definitions of ready and done, and implementing some good program management practices that include prioritization.
I also recommended that we work on creating T-Shaped team members so work wouldn’t grind to a halt if people were sick, on holiday, or chose to leave the team.
What I did not expect
Although the Agile Coach and Product leadership team agreed with my assessment and recommendations, which I expected, the team-of-teams did not! They were firm on their stance that adopting such practices would not address the root cause to their pain points. Moreover, they disagreed with management’s assessment that they have a predictability problem.
As a coach, this was interesting territory. I was brought into drive change in a team that believes no change is needed and doesn’t agree with the measures used to gauge their performance.
After a few honest discussions with the team, I found myself asking the following question:
