How to Shift Gears to Become an Agile Leader

Help the team with things they cannot control.

“What do I do now if I am not managing the teams?”

This is the most common statement that I hear from management when on the journey to Agile and self-organizing teams. The path to Agile Leadership is not clear.

In Agile, the term Management is being replaced by Leadership. Leadership is about believing in the change, leading your teams toward the new destination, and most importantly, supporting and serving the team along this journey. Service is one of the core management values outlined in the prior blog post, Do We Need a Manifesto for Managers?

Service is an interesting Agile Leadership core value because when you demonstrate it, you have to exemplify the other core values of Courage, Trust, Growth, and Improvement. Let’s dive deeper into this critical core value of Service.

How Managers Turn Into Agile Leaders Through Service

In their excellent book, Scaling Lean and Agile Development¹, Craig Larman and Bas Vodde reveal a key finding. This finding provides a perfect outlet for managers to serve the team.

Craig and Bas note that they have analyzed the lead time of many organizations. The lead time is the time required to get from concept to cash—from idea to user adoption and business impact.

They found the maximum percentage of time spent towards value for the end user was 7% of overall lead time. The established software industry maximum is closer to 5%. This means that between 93% and 95% of lead time is spent on non-value-added waste.

This large bucket of waste provides fertile ground for Agile leaders to support and serve the team. Traditional management techniques focus on optimizing and managing the 5-7% of value work. This is work that the team typically has the control to improve on their own. There is not much optimization to be had in the 5-7%. However, there are countless opportunities for an Agile leader to optimize by removing non-value-added waste.

The following principles in the Agile Manifesto underscore this revised focus for management.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Simplicity—the art of maximizing the amount
of work not done—is essential.

Common Scenarios

Now that we have clarity on what you should do as a leader, let’s explore common scenarios where this applies and what you can do.

We are Dependent on Another Team

If your team does not own every capability to deliver its features to its end user, it likely has dependencies. This introduces the possibility of many wastes, including handoffs, partially done work, waiting, context switching, defects, over-production, over-processing, under-realizing team potential, and knowledge scatter. There is significant potential to reduce lead time when dependencies are removed.

Guidance

You will need to use your political capital here. The best scenario is that your team performs the work of the other team. Your team will do this under the other team’s guidance and coaching. This builds control in your team now and in the future when similar dependencies emerge. Most importantly, it efficiently removes all of the aforementioned wastes.

If the other team will not give up control, another good option is to break the dependency with a workaround. By implementing a short-term workaround, your team can deliver value now and minimize lead time. When the other team can satisfy the need, your team can then remove the workaround and replace it with a permanent solution.

A third option is waiting on the other team to complete the work before your team does any work. This is the least attractive choice; it does not remove as much waste as you still have value left waiting on the other team.

We Have to Provide an End Date

Often, when an organization has not fully transformed to Agile, the business will likely require your team to provide a delivery date. This predictive thinking runs counter to the empirical and uncertain nature of software development. Also, it is common for dates to be imposed on your team to motivate them to deliver faster.

All of this puts extreme pressure on your team to predict amidst uncertainty and to cut corners. Your team will likely reduce quality to meet the date. Ultimately, this date-driven behavior takes away your team’s ownership. Numerous wastes are present when dates are around, including handoffs, partially done work, waiting, context switching, defects, and over-processing.

Guidance

It is time again to spend your political capital to serve your team. Protect the team from having to give a date. Don’t allow others to impose a date on your team (unless it is a rare, unalterable constraint).

If a date is unavoidable, work with your team to provide a realistic forecast to completion and work with them to align the delivery to the date constraint without compromising quality.

If you get pressure for a date, try not to give it until your team has shippable software. When you have no choice but to give a date, ask your team for a range they are comfortable providing based on the current level of uncertainty.

We Have to Get Approval

The vestiges of waterfall approaches require phase gates and governing bodies to approve a wide variety of activities. These stand in the way of the team delivering value to the customer. Most of these processes are no longer necessary or applicable with new Agile frameworks.

This administrative, check-the-box activity frustrates the team as nobody wants to do this non-value-added work. Granted, some steps may be necessary for compliance reasons. However, there are typically extreme amounts of waste in these governance processes, including handoffs, partially done work, waiting, context switching, defects, over-production, and over-processing.

Guidance

It is a good thing that you have so much political capital because you need it again. You will need to work with these governing bodies or owners of the phase gate process to trim down their checks for your team. When the processes being imposed are no longer relevant or add no value, ask for their removal.

If applicable, explain how your team removes the risk of being governed. It may be the case that your team needs to perform additional work to better take ownership of the risk. In this situation, establish an agreement with the governing body for your team to own the risk.

We Cannot Directly Engage With Our User

In the early days of software development, teams would engage directly with users. As time has progressed, the team has become further and further removed from the user. Organizations have developed separate departments and groups to focus on user experience. These groups are experts in user research, usability, and user testing.

Typically, the largest waste in software development is over-production waste. It is common for teams to deliver unnecessary features—the Standish Group Chaos Report sites as many as 65% of features delivered are rarely or never used². To avoid this waste, your team should develop empathy for what their user needs through direct user engagement. As an additional benefit, this will avoid the hand-off and knowledge scatter waste created by a separate group engaging with the user.

Guidance

Political capital is a wonderful thing. You will need it again. You will need to establish a partnership between the user experience group and your team to engage directly with the user.

The user experience group will provide user engagement expertise for your team, teaching them this valuable skill. Additionally, your team will develop a crucial understanding of user workflow and needs while building a relationship with the user.

We Don’t Have a Stable Delivery Environment

Over time, functional departments have resulted in silos and specialty teams. Infrastructure teams are one of these. They stand up delivery environments, support the hardware, monitor the hardware, and procure the hardware. As a result, your team typically does not have control of the environments it uses for development, testing, and production.

Having to rely on a separate infrastructure team can be particularly frustrating if the environment is not stable. When a key environment is down, your team will likely partially or completely stall out, which produces waste, such as hand-offs, waiting, defects, over-processing, partially done work, and context switching.

Guidance

Yes, it is that time again to bring out the political capital wallet. While it will not be easy and will take time, you will best serve your team when they have complete control over all of their environments and can troubleshoot each if not operating correctly.

You will need to work with the infrastructure groups to relinquish control and get the appropriate coaching and tooling for your teams to own their environments.

---

Conclusion

By simply switching your mindset to focusing on the waste that your team cannot remove themselves, you will serve your team well and be a great Agile Leader.

Your team will build confidence in self-organizing around what they can control. You will serve the team by removing non-value-added waste and by increasing the ability of the team to move from concept to cash on their own.

This will require you to spend some political capital to change the organization. At first glance, this seems impractical, but the investment will be well worth it. Your Agile Leadership will propel your team to greater heights.

---

Related Posts

• Do We Need a Manifesto for Managers?
• Overcoming the Fear of the Incapable Team
• Improvement Versus Delivery
• How a Stable Team Grows in Capability
• The Moment of Truth

---

References

1. Scaling Lead and Agile Development: Thinking and Organizational Tools for Large Scale Scrum, Craig Larman, Bas Vodde 2008
2. The Standish Group Chaos Report, a yearly publication since 1994