Posted on

Agile Leadership in Action: Navigating Change with the STARS Framework

When an organization begins a new or renewed transition to a more agile way of working, leaders, especially those in executive, management, or transformation roles, face a wide range of challenges. Knowing where to start and how you can best coach your team(s) in a new way of working can be overwhelming.

One of my go-to resources when starting a new leadership position has been Michael Watkins’ book The First 90 Days: Proven Strategies for Getting Up to Speed Faster and Smarter. The book provides a framework for making a positive impact in your first 90 days in a new leadership role by overcoming challenges based on the current situation in which the organization or team finds itself. While the book is focused on transitioning to a new or different traditional management role, its guidance can be applied to the challenges faced by leaders in a new or renewed move to a more agile way of working.

Leaders impacted by such a transition include existing roles such as executives, directors, line managers and project managers, and potential new roles such as agile coaches, Product Owners and Scrum Masters. Watkins’ framework, which he calls the STARS model, helps a leader assess and navigate the different situations they may encounter when in a new environment. STARS is an acronym that stands for five common business scenarios:

S – START-UP: Building something from scratch; no existing structure or processes. In this scenario, teams are forming or are new to agile.  This is an ideal time to introduce agility from the ground up. Leaders should focus on building a shared understanding of agile values and principles, guiding teams through the basics of frameworks such as Scrum and Kanban, and encouraging a mindset of experimentation and learning. The emphasis should be on simplicity, collaboration, and delivering small increments of value.

T – TURNAROUND: Organization or team is struggling; performance is poor or declining. In turnaround situations, the organization or team has attempted to be agile but is under pressure due to poor performance or crisis. Agile leaders must overcome low morale, mistrust, and resistance to change. They need to stabilize team(s), rebuild confidence, and demonstrate quick wins through agile delivery. The challenge lies in balancing urgency with sustainable transformation and ensuring psychological safety while driving accountability for creating value.

A – ACCELERATED GROWTH: Organization or team is growing rapidly; systems and processes may be lagging. When an organization needs to scale rapidly, agile leaders face the additional challenge of fostering agility while expanding teams, systems, and processes. Coordination across multiple teams becomes complex, and there’s a risk of missing the agile mindset in favor of speed. Leaders must coach the teams on the implementation of scalable agile frameworks, ensure consistent practices, and coach teams to preserve quality and alignment with stakeholder and customer value.

R – REALIGNMENT: Organization or team is stable but has underlying issues; performance is slipping. In realignment scenarios, the organization or team may appear stable but is drifting from its goals or losing effectiveness. Agile leaders must diagnose hidden dysfunctions, engage teams, and reignite the agile mindset. The challenge is to introduce change without disrupting what is currently working, and to help teams rediscover purpose and customer focus through agile principles and practices.

S – SUSTAINING SUCCESS: Organization or team is performing well; the challenge is to maintain momentum. Organizations in this scenario are performing well, but the challenge for agile leaders is to maintain momentum, foster innovation, and evolve agile practices to stay competitive. Leaders must encourage continuous improvement, support experimentation, and ensure that agility becomes a strategic advantage rather than a set of routines.

Each scenario requires a different leadership focus, and understanding which situation you’re in guides you in tailoring your strategy for the first 90 days. Here’s how I’d focus my coaching and the activities that can help in each scenario from an agile leadership perspective:

START-UP

Agile Focus: Establish foundational agile practices and culture.

Coaching Focus:

  • Introduce agile principles and frameworks (Scrum, Kanban). Help the team(s) determine which framework best suits how they create value.
  • Facilitate team formation and role clarity. Allow team(s) to be as self-organizing as possible.
  • Support backlog creation and MVP definition. Coach the team on prioritizing value and the importance of “Done” increments.
  • Encourage experimentation and feedback loops.

Activities:

  • Agile bootcamps and workshops. Create a common understanding of what it means to be agile.
  • Team chartering sessions. Ensure each team has created their own team working agreement.
  • Coaching on backlog refinement, right-sizing of product backlog items, estimation and sprint planning.
  • Regular retrospectives to build continuous improvement habits. Create and maintain a list of improvement items.

TURNAROUND

Agile Focus: Use agile to restore trust, transparency, morale and delivery capability.

Coaching Focus:

  • Diagnose root causes of dysfunction and help the team plan solutions.
  • Rebuild agile discipline and transparency.
  • Prioritize quick wins with “Done” increments to show progress.
  • Coach leaders on servant leadership and the importance of self-managing teams.

Activities:

  • Agile health assessments and morale surveys.
  • Targeted coaching for Product Owners and Scrum Masters.
  • Stakeholder alignment sessions.
  • Retrospective deep-dives and action planning to guide the team to the appropriate agile practices.

ACCELERATED GROWTH

Agile Focus: Scale agile practices to support rapid expansion while maintaining quality and culture.

Coaching Focus:

  • Support scaling frameworks (Nexus, LeSS, SAFe).
  • Strengthen agile governance and cross-team collaboration.
  • Coach leaders on agility at scale.
  • Ensure teams stay customer-focused.

Activities:

  • Scaling framework selection and rollout.
  • Communities of practice for agile roles.
  • Agile portfolio management coaching.
  • Metrics workshops to track value delivery rather than activity.

REALIGNMENT

Agile Focus: Reignite the agile mindset and correct course.

Coaching Focus:

  • Identify and address issues causing stagnation.
  • Reconnect teams with customer value.
  • Reintroduce agile principles and practices.
  • Coach leaders on change management and influence.

Activities:

  • Agile maturity assessments.
  • Refresher training and coaching.
  • Vision and strategy alignment workshops.
  • Leadership coaching on agile sponsorship.

SUSTAINING SUCCESS

Agile Focus: Maintain agility while fostering innovation.

Coaching Focus:

  • Promote continuous learning and improvement.
  • Encourage innovation and experimentation.
  • Support leadership in evolving agile practices.
  • Strengthen feedback loops and customer engagement.

Activities:

  • Innovation sprints and hackathons.
  • Advanced agile workshops (e.g., DevOps, Lean UX).
  • Leadership roundtables on agility and strategy.
  • Coaching on metrics that drive learning and growth.

The STARS model provides a powerful framework for helping leaders transition to a more agile way of working by aligning their leadership approach with the specific context of their team or organization. Each scenario, Start-up, Turnaround, Accelerated Growth, Realignment, and Sustaining Success, presents unique challenges and opportunities that influence how agile practices should be introduced or evolved.

In a Start-up, leaders can use agile to build foundational practices, foster collaboration, and establish a culture of experimentation from the ground up. In a Turnaround, agile offers tools for rapid feedback, transparency, and restoring trust through iterative delivery and team empowerment. During Accelerated Growth, agile helps scale operations while maintaining quality and alignment, enabling leaders to manage complexity and support distributed teams. In a Realignment, leaders can leverage agile to diagnose issues, re-engage teams, and drive meaningful change without destabilizing the organization. Finally, in Sustaining Success, agile supports continuous improvement and innovation, helping leaders maintain momentum and prepare for future shifts.

By using the STARS model, leaders can tailor their agile transformation strategy to the realities of their environment, ensuring that their approach is both context-sensitive and outcome-driven.

Posted on

What Really Makes Scrum Work

While I spent the first twenty years of my career as a software developer, during the last twenty I have been managing, leading, and coaching mostly software development teams. I learned about agile toward the end of the last century and used various agile practices with my teams to try and help them perform better (mostly XP, Scrum, and Kanban). I’ve also spent the last few years focused on training and coaching teams in the use of Scrum, sometimes finding success and other times… not so much.

As I look back on the teams that were successful, it has occurred to me that the common thread may not have been the practice of any particular framework or methodology, but that the successful teams seemed to just work well together. There seems to have been something beyond the process of how they worked.

I currently spend most of my time training individuals and teams in the use of Scrum, and I’ve noticed students are most interested in the mechanics of the Scrum roles, events, and artifacts. They want to learn how to “do” Scrum. They seem less interested in discussing what the Scrum Guide calls the “Scrum Values”. Although, it’s important to note the Scrum Guide states that the “successful use of Scrum depends on people becoming more proficient in living five values”.

These values are commitment, focus, openness, respect, and courage.

COMMITMENT

As defined in the Scrum Guide, the “Scrum Team commits to achieving its goals and to supporting each other”. To me, this means that the Scrum Team members put the needs of the team, or the many, ahead of any selfish personal needs of the few, or the one (to paraphrase Spock from Star Trek). They understand that working together on a Scrum Team is more like being a member of a soccer or basketball team, and less like golf or an individual track event. While you might take pride in being the high scorer on such a team, you won’t be considered great if your team does not win games.

The successful Teams I’ve worked with have been quick to help each other in any way they could and were willing to perform tasks that were not ones they most enjoyed. What counted most was the success of the team. Delivering something valuable to the customer was always the most important goal. Members of less successful teams tended to focus on “their” work and were not interested in working on things outside of their comfort zone.

FOCUS

The Scrum Guide states that the Scrum Team’s “primary focus is on the work of the Sprint to make the best possible progress toward these goals.” The best teams exhibit this trait and are not pulled in several different directions by competing or changing priorities. They internalize the needs of the customer and focus on doing whatever they can to meet these needs.

OPENNESS

In my experience, this is the toughest of the Scrum Values. The Scrum Guides says that the “Scrum Team and its stakeholders are open about the work and the challenges”, but this is easier said than done. In many if not most environments, it’s easier to get along or get ahead by telling people what they want to hear instead of what they need to hear. The best teams I’ve worked with had open and honest relationships with each other and with the customer.

RESPECT

Successful teams recognize that everyone brings their own skills and experiences to the work and don’t tolerate people being disrespectful to others. The Scrum Guide asks team members to “respect each other to be capable, independent people, and are respected as such by the people with whom they work.” In other words, don’t be a jerk.

COURAGE

If teams have an environment of respect and openness, and are committed to the work and each other, it becomes easy to show courage when hard choices must be made. Early in my career, I began putting up a poster in team rooms that stated, “It is better to do the right thing than to do things right.” The teams that got the meaning of this consistently outperformed those that struggled to understand its meaning. As the Scrum Guide states, they had “the courage to do the right thing, to work on tough problems.”

The more I discuss these values with students, the more I realize that these values were the main drivers of success for the high-performing teams that I was a part of. Whether the team was following XP, Scrum, or Kanban, the framework was a less important predictor of their success than the values being lived by the team. So, while I believe that the Scrum framework can be a powerful tool, I agree with the Scrum Guide when it says, “successful use of Scrum depends on people becoming more proficient in living five values.”

As trainers and coaches, we need to help teams create an environment where these values can thrive before worrying too much about the framework or methodology, they are following in completing their work. Teams that follow the Scrum Values become great teams that deliver great solutions for their customers.

Originally posted on 12/15/2021 at Improving.com.

Posted on

To Scale or Not to Scale: What is the Real Question?

Organizations look to scale their agile teams for any number of reasons. But is scaling the answer? And what exactly is the real question?

Why do you want to scale?

As agile software development is becoming the norm, we get asked a lot about scaling agile teams. Our first question is always “Why do you want to scale?”. Are you looking to have multiple teams working at the same time on loosely related projects (each with its own product backlog), or have multiple teams all working on a single project from a single backlog? What problem are you trying to solve by scaling? Do you believe that you need to scale because you have big projects, or because you have lots of developers that you need to keep busy? Are you hoping to increase your overall velocity by getting more done sooner? Or is it because your organization has announced an “agile transformation” and you’ve been told to “scale” to support that?

For most teams all of these factors are involved in their desire to scale. But is scaling really the answer?

Scaling is hard

Whatever your reason for scaling, our first piece of advice is to do everything you can to AVOID scaling. Creating great agile teams is hard; scaling them is even harder. Scaling magnifies any dysfunctions you have at the team level, so don’t consider scaling until you are really good at independent teams. Issues caused by scaling include:

  1. Cross-team dependencies, which are difficult to track and visualize. Each additional team exponentially increases the number of dependencies between units of work and the communication channels between the members of the teams.
  2. Integration of work becomes more challenging. At some point (at the end of each Sprint in Scrum) you need to integrate all of the work into something that is potentially shippable to the customer.
  3. Brooks’ Law. We’ve known since the seventies that adding people to a late software project makes it later (from The Mythical Man-Month: Essays on Software Engineering, 1975). Adding more teams does not ensure that more work actually gets done.
  4. The J-curve Effect. Any change made to a people-based process will cause productivity to initially decrease (disruption period) as people get used to the change. Hopefully productivity does eventually increase (making the curve look like a ‘j’), but the depth and length of the disruption period is difficult to predict.

What to do instead of scaling

There are several things that you can do to improve velocity and throughput with just a single team. Things to consider before scaling include:

  1. Are you really being Agile? Make sure you are not just DOING agile but are BEING agile by living up to the 12 principles outlined in the Manifesto for Agile Software Development. We see many teams that just go thru the motions of doing Agile and do not get the benefits of truly being Agile.
  2. Have you automated everything you can? Automation is the key to an Agile workflow, and manual processes cannot keep up with the pace of Agile software development.
  3. Is the work properly organized? You can minimize cross-team dependencies by creating feature-based teams that can work with minimum interdependencies.
  4. Be the best team you can possibly be. You may find that you can create enough value without adding new teams.

If you must scale

There are several frameworks and methodologies for scaling Agile teams:

  1. LeSS – Large Scale Scrum
  2. Nexus – Scrum.org
  3. SAFe – Scaled Agile Framework
  4. Others include DAD, Scrum@Scale, and RAGE.

Let’s take a look at the three most popular scaling frameworks.

LeSS (Large Scale Scrum)

LeSS was created by Craig Larman and Bas Vodde based on their experience working with large telecom and finance companies in Europe. Basic LeSS is designed to work with up to eight teams; LeSS Huge is meant for up to a few thousand people working on a single product.

The LeSS framework:

  1. Adds three new events to basic Scrum (Sprint Planning 2, Overall Retrospective, Overall Product Backlog Refinement).
  2. Is based on the following three principles:
    • Teams should be deep and narrow over broad and shallow
    • Requires top-down and bottom up support
    • Uses volunteering to get work done

The advantages of LeSS include:

  • It leverages what you already know about Scrum
  • It’s great for collaborative organizations

What LeSS does not do well includes:

  • It doesn’t address enterprise-level processes
  • There is no project/program management
  • Places lots of pressure on the single Product Owner

Nexus

Nexus was developed by Ken Schwaber (the co-creator of Scrum) and his team at Scrum.org. Basic Nexus is designed to work with 3 – 9 Scrum teams; Nexus+ is their framework for when ten or more teams are working on a single product.

The Nexus framework:

  1. Adds 1 new role (the Nexus Integration Team)
  2. Creates five new events (Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Review, Nexus Sprint Retrospective, Refinement)
  3. Adds three new artifacts (Nexus Sprint Backlog, Nexus Goal, Integrated Increment)

The advantages of Nexus include:

  • It is Scrum scaled by the father of Scrum
  • Nexus works well in collaborative organizations

The disadvantages of Nexus are:

  • It adds a large number of meetings to Scrum
  • As with LeSS it puts a lot of pressure on the single Product Owner

SAFe (Scaled Agile Framework)

SAFe was created by Dean Leffingwell as a scaling methodology for enterprises that require a more prescriptive framework at the program level. SAFe defines four framework levels; Essential SAFe, Large Solution SAFe, Portfolio SAFe and Full SAFe.

The SAFe framework:

  1. Is Scrum at the team level and Kanban at the program level
  2. SAFe is highly structured at the product and program level

The advantages of SAFe include:

  • SAFe works well in control-focused organizations
  • Creates top to bottom visibility into the development process
  • Gives detailed guidance at all levels

Disadvantages of SAFe include:

  • SAFe is very prescriptive and structured; does not encourage experimentation
  • Requires lots of training (or consultants) to implement

Which framework for you?

So you’ve done everything you can to make your single team as productive as possible, but you find that it’s still not enough and you need to scale. Which framework should you choose?

Choose LeSS if:

  • You’re committed to Scrum
  • Desire lots of flexibility
  • Value collaboration over following rules
  • Want your teams to be as agile as possible

Choose Nexus if:

  • You’re committed to Scrum
  • Value a framework created by the father of Scrum

Choose SAFe if:

  • Want a high level of team coordination
  • Desire more control over the process
  • Want formal process and reporting

Scaling is difficult and not for everyone. Start with small changes, inspect the results and adapt. And whichever framework you choose, make sure you have an experienced coach to guide you.