What’s your excuse for not being Agile?
It’s time to break through our barriers and start changing.
“We are doing hybrid Scrum. Pure Scrum won’t work here.”
“We have too much other work to do. We can’t dedicate our time to one team.”
“If we allow teams to self-organize with no checks and balances, chaos will ensue.”
“We are starting our Agile journey with an output focus.”
“We need to reorganize our company structure before we can try to work like this.”
“We still have to maintain existing management mechanisms while we transition to Agile.”
“We have had too much change. We can’t take any more.”
“We have a review board to approve our work. They expect a detailed plan, scope, and design up-front.”
“Management tells us to bring solutions and not problems to them.”
Over the years, I have heard every possible excuse for why Agile won’t work. I am sure you have also heard many similar versions of these justifications for keeping the status quo. Maybe you have even said some of these things yourself.
These sentiments are perfectly understandable. If leaning on these crutches is familiar to you, dropping them on the floor is a scary thought.
Yet this is exactly what Agile requires.
Without embracing change, Agile will do nothing for us. Many organizations have not embraced it, and they are stuck on their Agile journey. Their efforts are Agile in name only.
When I check where these organizations are the Agile journey, they all end up in the same spot: the beginning. Even if they have been on the journey for several years, they are still at the beginning.
In most cases, these companies are attempting to use Scrum. I see Sprint Events happening. They have a Product Backlog, and I hear lots of talk about making the work transparent.
But that is as far as it goes. When you look beneath the surface, all pre-Agile behaviors are the same.
So what should we do? I have no easy answer. But I am trying a few things to break through the barriers and help organizations start changing.
I have made it my mission to coach organizations back to the basics of what forms an Agile Mindset. My approach is simple. Let me walk you through it.
Let the teams decide
Managing, controlling, and directing teams has no place in the pursuit of an Agile Mindset. If you do nothing else, provide an environment and the support teams need. Let the teams decide how they will achieve their purpose.
Teams with autonomy, mastery, and purpose are a treasure to any organization. The engagement of these teams will soar. And teams with high-engagement self-select the path to their purpose without management intervention.
I recently had a team that benefited from autonomy. Rather than directing this team on what to build, management gave the team access to its customer.
After engaging with and learning the customer’s true needs, the team eliminated an entire release of planned features. If they had built the features on the backlog, they would have wasted their effort. Now, that’s awesome!
Break down walls
Too many dependencies suck the life out of teams. Delays will happen when dependencies plague a team. When factors out of their control determine their performance, teams get demoralized.
Rather than identifying and coordinating dependencies, the better option is to remove them. This gives teams control over delivering their work. The improved flow of value creates happy teams, happy customers, and happy organizations.
While you can’t remove all dependencies, you can remove the frequent, impactful ones. First to remove should be functional or structural dependencies for delivering working features.
I have a great example to show the value of removing a dependency. It involves a team I coached who relied on a downstream team to test its features. This team worked with the downstream testing team to assume responsibility for the testing.
As a result, the team was able to deploy features to production every Sprint versus every six Sprints. The increase in control over its work breathed new life into this team. And its customers and stakeholders were ecstatic with the improved flow of value.
Learn by doing
Product development is uncertain and complex. In this context, we don’t learn by thinking, planning, and designing. Rather, we learn by taking small steps, inspecting the results, and using insights to guide us. But we often fear trying new things.
We tend not to try new behaviors until we have confidence they will work without any issues. This is a risk-averse approach that does not favor action.
A better approach is to try a new behavior in a small, safe way and inspect the result. This provides direct evidence to check out. Evidence of how it works for real in your context is more valuable than endless speculation.
We can apply this same thinking to building our products. Instead of planning and designing, we need to try our ideas and inspect the result. Plans are the map, not the terrain. We must plan light and navigate based on the reality that emerges on the path.
I coach teams and organizations to have the courage to “try” amidst their fear of the unknown. A preference to “try” helps emerge the “right” delivery approach and the “right” product to build.
Take for example a team I coached that was not working together on one feature at a time. When introduced to the concept of swarming, the team was unsure it would work for them. But they leaped and decided to try it for a Sprint.
In one Sprint, the team completed and delivered a feature to its customer. Without swarming, this type of feature took four months to deliver in the past. And every team member learned valuable techniques from each other by working together.
The members of this team said they would never go back to working in isolation on separate features. The “try” mentality catapulted their team dynamic and raised their delivery of value.
Start finishing
Why start two things in parallel when you can do them one-at-a-time and get them both done faster, easier, and better? This is a fact, but we still tend to start many things at one time. This could be because we can’t say “no,” or we perceive we are effective at multi-tasking.
One thing we have to get good at in an Agile world is finishing what we start. We have to be relentless in our pursuit of getting “done.” This requires that we rank what we need to do, select the top item, and collaborate as a team to complete it.
This gives you control to deliver the highest priority thing first. If you work on many things at once, you deliver all later than if you worked on them one-at-a-time in priority order.
As an example of the power of focus, consider a team I coached where its members worked across two teams. This team decided to dedicate its members for an entire Sprint to one team.
By dedicating its time to one team, the team delivered three times the number of features as normal. And they all agreed their pace felt more sustainable. This is a win-win situation.
Give managers a foothold
When managers don’t feel they have a place in an Agile world, bad things happen. They continue to manage from the command-and-control paradigm. Detailed plans and designs, perfect plan execution, and status reports remain the focus.
The result is an environment not good for high team engagement. An Agile Mindset can’t thrive and won’t survive without engaged teams.
One answer is in giving managers a new foothold in the Agile world, helping them become Agile Leaders. An Agile Leader serves, coaches, and engages with teams. They leave the plans and status reports behind in favor of joining teams on their journey.
I have one recent striking example of the value of changing the management paradigm. It involved removing status reports as a stakeholder communication vehicle. Rather than relying on status reports, these stakeholders started attending Sprint Reviews.
The result was the elimination of three weekly meetings for each two-week Sprint. 50 person-hours of meetings per week were no longer needed.
Furthermore, status reports rarely revealed obstacles to these stakeholders. But in the Sprint Review, they heard first-hand how environment downtime hurt the team’s flow. Immediately, the stakeholders worked with the infrastructure team to stabilize the environment.
With one simple change, the stakeholders removed significant waste from the system. And the stakeholders were more attuned to the situation of the teams.
Taking it forward
I have seen dramatic results with this simple recipe. Whether I attack it in parts, do it as a whole, or take a thin slice of each element, the Agile Mindset grows.
You may ask, “Is this recipe any different than following the values in the Agile Manifesto¹?”
These techniques are in complete alignment with Agile Values. The fabric of the Manifesto — individuals and interactions, customer collaboration, working software, and responding to change — runs through them. Perhaps this is the reason they work so well.
Stop making excuses and try these techniques out for yourself today. Embrace change to forge your path to an Agile Mindset.
For more content like this on my pursuit of Lean Leverage, delivered to your inbox, you can just join my email list. Or see my other related posts below to dive even deeper.
Related Posts
You can read posts related to this one below.
References
- The Agile Manifesto, Beck et al., 2001
