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!
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.
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.
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.
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.