newcohospitality.com

Evolving Agile Coaching: Transitioning to Delivery Leadership

Written on

Agile Coaching is facing significant changes — what does the future hold? Here are three essential steps to advance your career.

Agile is evolving

Previously, I discussed how Agile coaching is becoming less relevant. The main reason is straightforward: every method is now a blend of Agile and Waterfall. Just as a surgeon cannot specialize solely in keyhole surgery, a leader cannot restrict themselves to Agile practices alone.

With this understanding, we can pivot to what lies ahead.

In the future, the role of the Agile coach will shift to that of a delivery leader, transitioning from a supportive role to a hands-on position with accountability for delivery.

The concept that Scrum teams can operate independently is outdated. The complexity of the modern world demands collaboration across teams. No single team possesses all the knowledge regarding business needs, customer expectations, regulatory requirements, and technological capabilities. This interconnectedness is why organizations have various departments. The most effective teams are those that successfully navigate this complexity and achieve results collectively.

This capability to navigate complexity is where the future of Agile coaching resides.

Regardless of whether your organization employs SAFe or another operational framework, as an Agile coach, it is crucial to redefine your role. You are no longer merely a coach.

The Agile Delivery Leader

I propose the term Agile Delivery Leader, representing a transitional role between the traditional Scrum Master or Agile coach and a project manager adept in both Agile and Waterfall methodologies. When the Agile movement began, the industry was still rooted in Waterfall, and unfortunately, Agile has not fully evolved since then.

For instance, EDF, while constructing the world's most expensive power station, has adopted Agile principles in its design process, opting to build components of the Hinkley Point C power station in modular formats.

Yet, organizations like scrum.org claim, “One of the significant drawbacks of Waterfall is its rigidity.” Similarly, Scrum Alliance states, “Waterfall is a project management method where tasks are completed in sequence, and the next phase cannot commence until the previous one is finished. Stakeholder or customer requirements are established at the project's outset, creating a linear progression.”

In contrast, an efficient DevOps pipeline might look like this:

Source > build > test > deploy

This is a refined version of Waterfall!

Why does the Agile sector complicate matters? It has marketed Agile as a methodology rather than a mindset. This was necessary for selling certifications. The certification industry relies on offering something distinctive, leading to Scrum Master resumes overflowing with qualifications yet lacking in essential skills. So, what skills will be necessary moving forward?

A proficient project manager (PM) must possess various skills, which can be summarized as follows:

  • Governance
  • Stakeholder management
  • Value management
  • Scope and schedule management
  • Risk management
  • Team management
  • Change management

This is a broad range, and the PM must assemble a leadership team for all but the smallest projects. From a pop star's global tour to developing a new app, a competent PM typically organizes four teams:

  1. The PMO
  2. The Design Authority
  3. The Change Authority
  4. The Delivery Authority

Let’s briefly discuss each:

The PMO

The PMO (Project Management Office) is the backbone of any project. Their responsibilities include:

  • Ensuring governance is effectively executed (i.e., the right decisions are made at the right time by the right individuals);
  • Maintaining alignment between spending and income forecasts with approved budgets;
  • Creating a unified schedule that integrates the activities of both internal and external teams;
  • Tracking dependencies, risks, issues, and assumptions to preemptively identify and resolve potential delivery obstacles;
  • Allocating resources for the project, whether through staff, contractors, partners, or vendors.

While I've omitted many minor tasks, this gives a clear overview.

The Design Authority

In many projects, the Design Authority operates as a dedicated team responsible for the overall design of what is to be delivered. While we often hear about the product owner, it is rare for one person to grasp every detail of a solution. However, a single individual must lead the design team.

The Change Authority

The Change Authority often acts as the counterpart to the Design Authority. My organization does not employ the “Desirability, Feasibility, Viability” (DVF) framework. While useful, it often fails to differentiate between what customers want and what they can realistically use. We refer to this concept as Absorbability, which is a primary reason for project failures. The Change Authority's role is to ensure that the customer (internal or external) is prepared and able to accept what we produce.

Though this role may seem straightforward, it is challenging to accomplish.

The Delivery Authority

The Delivery Authority oversees the teams. They may be referred to as the Chief of Staff, COO, or another title, but they are the individuals who drive team performance.

This final role is where the Agile Delivery Leader excels.

From Nine Stances to Three Objectives

Agile practitioners once discussed the nine roles of an Agile coach:

  1. Observer
  2. Facilitator
  3. Advisor
  4. Mentor
  5. Trainer
  6. Coach
  7. Agile expert
  8. Change catalyst
  9. Partner

These roles are now outdated. I have yet to see a job listing for a “change catalyst”; if I do, it would be surprising. The paradigm shift required for Agile coaches is to transition from a passive role (observing, facilitating, advising) to one focused on active delivery. Being responsible for results is significantly more valuable than being labeled an expensive change catalyst.

The Agile Delivery Leader has three core objectives:

  1. Enhance team performance
  2. Develop the roadmap
  3. Deliver efficiently

Enhance team performance

The term coach can imply two things: supporting a person or team to achieve their potential or managing and driving them toward success. If the Indian cricket team wins the World Cup, they don’t dismiss the coach; rather, the coach is vital to the team's success. In the same vein, the Agile Delivery Leader is accountable for team performance. If a team member is underperforming, the leader must investigate, implement performance management strategies, and if necessary, replace that team member. This marks a clear distinction between passive coaching and proactive delivery leadership.

Develop the roadmap

Often referred to as program increment (PI) planning, gathering both internal and external teams to establish the next steps is crucial. These decisions might require governance approval. The Delivery Lead is responsible for emerging from this process with a definitive schedule.

Several factors might necessitate governance review:

  • Conflicts between teams (e.g., should we release a new app that worsens customer experience?);
  • Team decisions that exceed allocated time or budget;
  • Risks related to meeting deadlines that surpass board-set tolerances;
  • Contractual, legal, or regulatory issues that are beyond the team's capacity to resolve.

An Agile coach may say, “I anticipated that.” A Delivery Lead prevents such situations.

Deliver efficiently

Once a plan is established, the Delivery Lead guides the teams in executing the agreed-upon increment. Collaborating closely with the Change Authority, Design Authority, and PMO, the Delivery Lead ensures alignment:

  1. With the PMO — ensuring time, cost, quality, risk, and value constraints are maintained, and emerging issues are proactively addressed;
  2. With the Design Authority — confirming that the right solution is being developed correctly;
  3. With the Change Authority — ensuring that the output will be accepted by the customer and can be utilized effectively. Otherwise, the effort is futile.

Numerous challenges may arise, and the Delivery Lead must navigate them not as a coach, but as a leader responsible for resolving issues.

What can I do to prepare?

If you wish to transition to this new role, consider these suggestions:

  1. Actively address and resolve team dysfunctions rather than merely observing and reporting them. Collaborate with your PM to assess team dynamics, performance, and succession planning, and take on accountability for execution;
  2. View impediments as risks — most impediments were once risks. Learn about risk management and seek opportunities to engage in this area;
  3. Think beyond your team during PI planning. If you aren’t currently conducting PI planning, propose it and offer to facilitate a ‘big room’, ‘product increment’, or ‘forward planning’ workshop;
  4. Stay informed about each team's progress in executing the plan. Do not assume that Agile means improvising; understand the governance board’s expectations for progress and report accordingly;
  5. Familiarize yourself with your customers (internal or external) to grasp the ‘desirability — absorbability’ gap. Few people do this, and it distinguishes you by allowing you to foresee implementation challenges before they arise.

Summary

Experience as a Scrum Master or Agile coach lays a strong foundation for these challenges, but it is not sufficient. Transitioning to delivery leadership and ultimately taking on full PM accountability represents a significant leap.

As organizations recognize that “Agile” is inherent to their operations and that “Agile methodology” is neither adequate nor essential, Scrum Masters and Agile Coaches must evolve toward delivery accountability.

Many of my Scrum Masters and Agile Coaches have already acquired their PMP Certification and are on a path to becoming the COO of their projects or products. Many have assumed full accountability for projects and are thriving, but all have a contingency plan for the end of Agile in the coming years. Do you?

Note: I use the terms project and product interchangeably. Aside from how the backlog is prioritized, the day-to-day responsibilities are remarkably similar.