Because in the traditional world, the Project Manager is the center of gravity. They own the plan, manage timelines, track dependencies, and report status. They’re accountable for scope, cost, and time, and success is measured by how well the plan is delivered.

Then agile steps in and changes the game.

We move from delivering against a fixed plan to delivering value in increments. From control to empowerment. From outputs to outcomes. And in that shift, the responsibilities that once sat with one person don’t disappear… they split.

In a Scrum-based world, what used to be the Project Manager role is effectively unbundled into two distinct accountabilities: the Product Owner and the Scrum Master.

As Roman Pichler puts it so clearly, the Product Owner is responsible for the “what” – creating the right product – while the Scrum Master is responsible for the “how” – using Scrum the right way. And only when you get both right do you create sustainable success.

That distinction matters more than most organizations realize.

The Product Owner is focused on value and direction. They decide what gets built, in what order, and why. They represent the customer, the business, and the vision. They’re constantly making trade-offs to ensure the team is working on the highest value outcomes.

The Scrum Master, on the other hand, is focused on flow and effectiveness. They make sure the team is operating well, following agile principles, removing blockers, and continuously improving. They protect the team from noise and help create an environment where great work can happen consistently.

And then you have the team itself, a cross-functional group that owns delivery end to end. No handoffs, no silos, no waiting in queues. Just a team that can take an idea and turn it into something real.

This is one of the biggest shifts I’ve had to drive in PMO transformations. Moving from functional silos to true cross-functional teams. In the old world, work moves from one team to another, which slows things down and diffuses accountability. In agile, the team owns the outcome. That changes everything.

Now, one question I hear all the time is:
“Why can’t the Scrum Master and the Project Manager just be the same person?”

And on the surface, it sounds efficient. One person, one role, less overhead.

But in reality, it creates a fundamental conflict.

Because you’re asking one person to be responsible for both the what and the how.

You’re asking them to decide what needs to be delivered while also protecting how the team delivers it.

And under pressure, something gives.

In my experience, it’s almost always the “what” that wins. Deadlines, stakeholder demands, and business pressure start to override team health, quality, and good practices. The system slowly drifts back toward command and control, just wearing agile language on top.

That’s why the separation matters.

When you have a Product Owner focused on value and a Scrum Master focused on team health and process, you create a healthy tension. One is pushing for the right outcomes, the other is protecting the system that delivers those outcomes. Together, they keep the team balanced, focused, and sustainable.

That balance is what replaces the old Project Manager role.

So is the Project Manager obsolete?

Not exactly. But the role, as it existed, has been redefined and redistributed.

What I’ve seen, time and time again, is that great Project Managers evolve. They step into Product Owner roles, owning value and direction. Or they step into Scrum Master or Agile Coach roles, enabling teams and improving systems.

But trying to hold onto the old model, where one person manages everything, is where things start to break.

Because agile isn’t asking, “Who’s managing the project?”

It’s asking, “Are we building the right thing, and are we building it the right way?”

And the answer to that question is no longer one role.

It’s a partnership.

What’s the growth path for a traditional Project Manager?

There isn’t a single path forward, and that’s actually the opportunity.

A traditional Project Manager can evolve into a Product Owner, Scrum Master, Agile Coach, or program-level leader, depending on where their strengths lie. The skills don’t disappear, they shift. From managing timelines to owning value. From driving teams to enabling them. From controlling delivery to improving the system that delivers.

But staying in the exact same role, trying to operate the same way as before, is where things start to break down.

Agile doesn’t need someone to manage the work in the old sense. It needs people who can unlock it, shape it, and guide it in the right direction.

To your agility,

Gilli

P.S. 🌸 find time to talk about improving agility in your world, or read about me

So what is a high-performing PMO - Project/Program Management Office? With agile as its backbone, it becomes an incredible center of excellence and toolkit for an organization to operate well and delivering the companies biggest bets - projects and products - for the highest ROI 🚀

1️⃣ Vid courtesy PinchForth. Watch the full Bad Ideas podcast we did:

2️⃣ Also I really love this podcast I did with the amazing Louise Gardner - "2 Powerhouse PMO Women Leaders Walk Into A Room". We really dive deep on PMO.

Watch / Listen now (on my other substack xo)

xo,

Gilli

I’m really enjoying digging more into organizations that truly empower agility, whether officially as "agile framework" or as a keen appetite to deliver value through high-performing, self-organizing, trusted teams. It feeds my core values around belief, trust, creativity, and progress. Not just moving fast, but moving with intention; moving as "One-Team" mentality.

As a PMO leader, an Agile 'Model', when done right, isn’t a control tower hovering over delivery. It’s a living system that creates the conditions for teams to thrive. As Jim Highsmith (co-author of the Agile Manifesto) puts it, “Agility is principally about mindset, not practices.” That line always lands for me. Because agility isn’t a framework you install. It’s a belief system you model. It shows up in how leaders listen, how decisions are made, and how safe it feels to adapt when the plan no longer fits reality.

The shift from traditional PMO thinking to agile leadership is profound. A traditional project manager protects the plan. An agile leader protects the outcome. That subtle distinction changes everything. From governance to talent retention to how value is measured. Agile reminds us that we’re not managing projects as much as we’re stewarding product lifecycles, learning continuously, and delivering value in motion rather than perfection in hindsight.

And perhaps the most human truth of all: “If we want to build great products, we need great people. If we want to attract and keep great people, we need great principles.” Agile PMOs, at their best, are principle-led. They create clarity without rigidity, alignment without fear, and momentum without burnout. It's about empowering self-organizing teams with a ton of heart. That is the secret sauce to organizational ROI...

🧏‍♀️ Curious to hear your thought. How is your organization evolving its PMO mindset to support agility, not just efficiency?

To your agility,

Gilli

Agile Leadership is not merely a set of good management practices. It is a dynamic approach that evolves and improves over time, transforming “good leadership” into great leadership. This mindset allows an organization to adapt to changing market conditions and maintain a competitive advantage.

1. The Foundation: It Starts With Self-Leadership

The journey to an agile organization begins with the individual leader. Agile leadership starts by focusing inward, through Self-Leadership.

• Be the Change: Leaders must lead by example, demonstrating the behaviors they wish to see in the organization. As a leader, your actions speak louder than words, and you must actively engage in your own development.

• Take Ownership: This self-leadership involves developing self-awareness and taking personal responsibility and accountability for your decisions and actions.

2. Shifting from Command to Coach

In an agile environment, the leader’s role transforms from a traditional command-and-control structure to one of a mentor and coach.

• Servant Leadership: Agile leaders practice Servant Leadership, focusing on developing the full potential of all team members. The core work of an agile leader is to actively develop leadership capability throughout the organization, providing opportunities for others to lead.

• Empowerment and Trust: The key to this model is empowerment. Agile leaders provide their teams with the necessary autonomy and tools to make decisions, which fosters a sense of ownership and accountability, ultimately boosting engagement and productivity.

• Collaboration Over Handoffs: For business leaders, this often means getting directly involved, such as stepping into the Product Owner role to champion and shape the product. Collaboration with IT and engineering teams becomes a daily, side-by-side activity, moving away from a traditional hand-off model.

3. Thriving in Uncertainty through Continuous Learning

Agile leadership thrives in the face of complexity and uncertainty.

• Adaptability is King: Leaders must be capable of adapting quickly to dynamic situations and embracing ambiguity. They need the flexibility to take quick, assured actions, which means constantly adapting to new challenges rather than relying solely on past experience.

• Prioritize Quality Thinking: Agile leaders focus on high-quality thinking, which means seeking input from those closest to the problem to ensure decisions are informed by reality, not just electronic reports.

• Cultivate a Growth Mindset: A crucial component is a commitment to continuous learning. Agile leaders foster a culture of emotional and mental safety where experimentation is welcomed and learning from failures is celebrated.

By cultivating these behaviors and principles, business leaders can transform their organizations, ensuring they are not just “doing agile” but being agile, flexible, adaptive, and prepared to deliver continuous value in an ever-changing world.

4. From Teams to “Team of Teams”

As highlighted in General Stanley McChrystal’s book Team of Teams, traditional organizational structures built for control, predictability, and efficiency crumble in the face of today’s complexity. Agile leadership embraces this reality by shifting from hierarchical command chains to networks of empowered teams.

Each team operates autonomously, yet all are unified by a shared consciousness. A common purpose, strategy, and set of values guide decision-making across the enterprise.

This model of decentralized leadership is not chaos. It is coordinated agility. It allows modern organizations to scale without losing coherence. Every team has clarity of mission and trust in one another’s intent. They move independently, yet remain rhythmically aligned, each pulse contributing to the same heartbeat of transformation.

In this way, Agile Leadership becomes less about direction and more about connection. Less about commanding, and more about creating the conditions where leadership can emerge everywhere.

📖 Buy your copy of TEAM OF TEAMS

5. Marching to the Same Rhythm

The beauty of agile organizations lies in their ability to self-organize while staying in sync. This is what McChrystal calls “empowered execution”, a system where people have the freedom to act but the discipline to align.

In Agile terms, it is the balance between autonomy and alignment. Leaders do not tell teams what to do. They ensure everyone knows why they are doing it. This shared sense of purpose allows teams to pivot swiftly without waiting for orders from the top.

It is like a symphony. Every musician plays their own part, but all follow the same tempo. When leaders build this rhythm through trust, transparency, and clear communication, the organization hums with collective intelligence and momentum.

6. Insight in Practice

A great example of these principles in action is discussed in the video “Agile Leadership: How to Achieve Team Success” on YouTube. It explores how leaders can empower decentralized decision-making while keeping teams aligned around a unified purpose, a concept at the very heart of Team of Teams and modern Agile Leadership.

This is not about dismantling hierarchy overnight. It is about evolving it. Replacing layers of control with layers of connection. Leaders become catalysts who inspire alignment, not administrators who enforce compliance.

7. The Future Belongs to the Adaptive

As markets shift and technologies evolve faster than ever, organizations that cling to old control systems will struggle to survive. Agile leadership represents the evolution of management itself, a living system that learns, adapts, and grows through its people.

When leaders master self-leadership, empower others, and orchestrate decentralized collaboration around a shared mission, transformation stops being a buzzword and becomes a way of being.

That is the true essence of Agile Leadership. Not just doing agile, but becoming the agility your business needs.

Sharing

I don’t have all the answers. And sometimes other authors and thought-leaders have encapsulated the concepts well. For this reason, I definitely encourage watching this video with General Stanley McChrystal about the principles behind his book Team of Teams and how leaders can implement agile, decentralized decision-making in corporate settings. McChrystal explains why agility and decentralization go hand in hand but also why they require extraordinary discipline to avoid chaos. It’s pretty awesome.

If you want to learn more on how I can evolve your organization, following some principles from Team of Teams and others, find time below.

🎥

Buy your copy of General Stanley McChrystal’s book Team of Teams👇

BUY THE BOOK

Find time with me:

You can’t simply host a sprint planning session, stick a few sticky notes on a Kanban board, and call it Agile.

💡 So, the question of the day is,

Is Agile just planning or does Agile span the entire SDLC?

It’s a great question. I happened to get this question recently because while agile and scaled agile frameworks support stronger sprint planning and incremental planning (aka PI Planning), some people just think it’s all about the “upfront” preparation of product discovery and planning, or throwing some cool tools like Jira at the teams, and “let’s just leave the rest to product development, engineers, the release team, and Dev Ops teams.

Oy vey. Don’t get me started. So let me answer the first question.

But first, before I answer it, Welcome to The Agile Warrior. Hi, I’m Gilli Aliotti — executive coach, tech leader, creative rebel, and your agile hype woman.

Over the last 20+ years, I’ve led agile transformations and strategic programs at Google, Yahoo, Paramount, PayPal, Disney, and a bunch of startups, helping teams and businesses thrive at scale. I’m a certified master business executive coach, SPC5 Scaled Agile Consultant, Six Sigma Black Belt, ICAgile Coach (ICP-ACC), MBA Grad, and founder of a few startups myself, and a passionate advocate for agility in tech, business and entrepreneurship. < 😮‍💨 Breath 🧘🏼‍♀️ >

My superpower? Helping bold humans lead with clarity, creativity, agility and courage — in work and in life.

SO

Agile … YES, it in fact runs across the entire Software Development Life Cycle (SDLC), from ideation all the way through delivery and operations.

Agile isn’t just how we plan. It’s how we think, build, and grow together.

It’s a mindset, a rhythm, and a way of working that touches every part of how modern organizations create value. Also, it should not really be conflated with other SDLC shadow processes. It should all run in rhythm…

Together.

Yes, planning is part of it — but Agile principles shape every phase:

• Ideation & Prioritization: where ideas are formed and prioritized based on customer value.
  Development & Testing: where collaboration, iteration, and feedback loops fuel continuous improvement.
  Release, Launch & Operations: where delivery, learning, and adaptation keep teams in sync with business goals.

Unlike the linear Waterfall model, Agile is iterative and incremental, cycling through all these phases repeatedly in short bursts (sprints), each delivering a potentially shippable product increment.

Agile doesn’t just help teams plan better — it helps them think, build, and evolve smarter.

⚙️ Where can the Agile PMO fit in?

When people hear “PMO,” they often think governance, reporting, and control. But a PMO is more than a reporting function.

An Agile PMO (APMO) flips that script.

It’s not a control tower. It’s an enablement hub for SDLC agility.

The APMO’s role is to enable agility across the organization — guiding frameworks, mentoring teams, and ensuring the business and technology arms of the company are marching to the same beat.

And I’ve lived this firsthand.

🧭 Real Talk: When I Built an APMO from the Ground Up

When I was asked to grow a small PMO of seven Scrum Masters into what eventually became more than fifty Scrum Masters, Program Managers, Release Train Engineers (RTEs), and Agile Coaches, I had to completely rethink structure and purpose.

We were scaling fast — how can we influence agility across 100 Scrum teams? One Hundred. And the PMO had to evolve from managing projects to enabling agility at scale.

We couldn’t be “the project police.” Oooh yuk.

We had to build capability, culture, and clarity. Fast.

So I created three layers of the PMO:

Team Execution Layer: Scrum Masters supporting day-to-day delivery and team excellence across the SDLC.
Program/ART Layer: RTEs and Program Managers driving coordination, strategy, and delivery alignment through the Scaled Agile Framework (SAFe).
Portfolio & Coaching Layer: Agile Coaches and Portfolio Managers ensuring consistent flow, performance, and leadership visibility.

We also owned Agile onboarding, Jira and Confluence governance, Slack integrations, and training for every new hire.

Every PMO member was trained as an Agile Coach, with a leader dedicated to coaching and capability growth.

It was the perfect blend of PMO and APMO — structure meets agility.

The result was a scalable framework that kept teams empowered, projects on track, and leadership confident in the organization’s delivery rhythm.

💥 The Flip Side: When the APMO Is Too Narrow

In another organization, I was brought in as an Agile Coach to support an APMO that had a much narrower scope, focused primarily on planning and coaching.

Other parts of the SDLC — release, deployment, DevOps — were managed elsewhere.

The result? Silos, misalignment, and confusion.

Each team had its own interpretation of “Agile best practices.” Different tools, different workflows, different languages.

You’d hear things like:
“Well, she said do it this way.”
“I don’t report to you — my team uses this tool, not that tool.”
“We manage releases over here, but sprints over there.”

When an organization isn’t marching to a shared rhythm, you lose transparency, you lose flow, and sometimes… you lose people.

That’s when frustration, waste, and even toxicity creep in.

A well-structured APMO doesn’t just provide templates; it provides cohesion. It’s the steady drumbeat that helps teams play in harmony.

🥋 The Real Job of the APMO

When done right, the Agile PMO becomes the bridge between strategy and delivery, ensuring that Agile isn’t just living in the standups, but flowing through every layer of the organization.

Its superpowers include:

• Enabling consistency without rigidity

• Training and mentoring at scale

• Keeping delivery transparent and aligned to business strategy

• Creating psychological safety through clarity and shared practices

Because Agile isn’t just how we plan.
It’s how we think, build, and grow together.

💭 Final Thought

If your PMO is just tracking projects, it’s time to evolve.
If it’s enabling agility, guiding, teaching, and improving continuously, then congratulations, you’re building an organization that can adapt, learn, and thrive no matter what comes next.

xo,

Gilli

P.S. Share your thoughts about your experiences below. I’d love to hear them. And find me here for a clarity call for your next growth needs whether as an organization or agile coach.

Find time to discuss your Agile needs

My answer was: “Yes, and… …we also need to take a hard, honest look at how we are currently working too.”

Scale people or scale agility? That is the question.

Simply throwing a bunch of new people at a problem, believing that more individuals automatically translate to more results, can paradoxically make things much worse. That’s my hypothesis, and I’m sticking to it.

So if you didn’t read Parts 1 and 2, find them here

And if you’re ready, let’s end this thesis:

​Step 3: Scaling process

Now that we’ve performed agile practice “oral surgery”, and created a sense of ‘all together now’ predictability, for a single scrum team, the next phase is to work out how to meet your organization’s ever-increasing requirements and this means that the process and the teams need to scale. Your Head of Product just announced that we need to double our product features to market, to triple the user base. Aggressive goals have been placed at the strategic level. The Roadmap is ambitious and long. “We have a lot to accomplish”, says the CEO. How are we going to do it all?

Fortunately, your current agile teams are high-performing and predictable. But the amount of work that can be delivered at the same time is based on our tried and trusted Scrum, where we can only do as much as the capacity or velocity of the teams. We’re really good at timeboxing. Just, there isn’t enough time to do everything on the ever-increasing ambitious roadmap! Doing the math, if you have 3 teams, you can develop and deliver 3 things at a time, each team working on their backlog’s highest priority, set by the Product Owner. What if we had to now do 20 things?

Check if the teams can split.

The best agile team size is between 4-7 people (not including the SM and PO). Any larger than this, and communication and productivity diminishes. It’s not just an agile “know-how”, it’s basic economics. It’s called diminishing marginal product. Basically, the more people you add to a team, the less results you will get. The team productivity actually slows down.

You would think that if there is more work, you can just add more people to the team. Seems simple, right? But there is a limit to a team’s productivity – a point of diminishing return. Just take a daily standup as an example. There is a limit to its effectiveness with more people attending. As with any interactive meeting, the more people that join, the diminishing quality of the outcomes of a meeting. Beyond seven team members, meetings tend to run too long, transparency into task ownership is muddy and communication starts to crumble. Simply put, bigger teams create more problems.

If you have a scrum team that’s larger than 7, maybe even bloated to around 10 or 12 (fess up, I know you have some of those….), consider splitting that team into 2. ​ Take half the developers and half the QA, and create 2 teams from 1. Your Scrum Master may be OK in managing 2 teams, as with your Product Owner (though ideally they are also dedicated to 1 team to be high-performing). But even this slight adjustment of team split may actually increase productivity and results, without even adding people. The backlog for each team becomes micro-focused and ruthlessly prioritized. The meetings become more productive and communication within the smaller team increases.

Expanding agile release trains

I spoke about predictable releases for the team. But what if you have multiple teams? Agile teams who need to deliver similar features, or under a common product, can roll up into an agile release train. I really love this word, ‘train’. Why? Because it’s very visual. It offers a clear assumption of what happens: There is a Train, and it departs. You either get on it, or you don’t. But the train always departs. Ready software either releases with the train, or it misses it, and catches the next one. But the cool thing is, there is always a train coming to the station, able to take ready work off to users.

Note, this is not about the ‘ART, Agile Release Train’ that Scaled Agile speaks of. Though I will touch on that in a second. I’m speaking about multiple, predictable, synchronized releases across multiple teams. ​ To get to this, you need all related teams to be on a similar sprint cadence. This way, you can synchronize the release ceremonies and schedule across the teams. With this concept, multiple teams can ‘hop on’ to the Release Train, collectively. If you have, say, 4 teams that are working on iOS codebase for one (1) iOS app, then rightly so, the 4 teams can collectively deploy together on the same Release Train. While it might involve some coordination, it therefore allows several/multiple/many teams to deploy together collectively for one product, on a similar platform. Even in a CICD delivery model, we can further refine deployment to be even daily, if the teams are mature enough and have adopted DevOps mindset. Still, even a daily deployment, teams need orchestration and predictability.

Agile Release Train is also a key component of SAFe® methodology. The ART can be imagined as a train with a permanent crew whereby the teams within the ART form a virtual organization that are delivering “in step” with the journey. As in the case of a train, teams are synchronized within the Program Increment timetable (a series of 4-6 sprints) and at the end of the increment, they ‘deliver’. I suggest, however, that Release Trains (1st definition) occur within ARTs. This way you are delivering value to the customer at least by the end of each sprint (frequently) – customer predictability, yet the teams deliver their collective value at least by the end of each PI – stakeholder predictability. When the stakeholders see predictability, we see team success. When we see team success, we can then scale. When we can scale, we see expanded results, and when we see expanded results, we see company success, and when we see company success, well, we hit nirvana.

Teams at Scale - let’s review the Agile frameworks for scale

There are several Agile frameworks that offer methodology around “many teams” collectively working together. I, for one, am not a stickler for a specific one, and call me the agile rebel in all this, but I’ll tell you why - most of them are made to make money off you and your company in training their framework, as well as to keep certifications current. Quite frankly, putting aside different jargon, they’re all pretty similar, simply because when you break it down to simple common sense, they do mean the same thing. Of course, all of them have slight nuances, which merely is them branding themselves to find their niche. For example, Scaled Agile (the company who offers SAFe® – Scaled Agile Framework) cannot use the word ‘SPRINT’ because it’s trademarked, so they use the word ‘ITERATION’. It means exactly the same thing.

Discipline and Freedom: How they Work Together with Agile

All of these agile frameworks work. They all solve the same core problems. Whichever framework you choose, the key success factor to them is how WELL they are implemented. Suffice to say, the context of this section is to share with you that going from one solo team to many teams, just takes a little organization, and perhaps, might I say, standardization. This is the part where some pure agilists may conflict with this, because agile teams are self-organization. However, what those purists tend to forget is, agile methodology is strictly managed in a system. Agile is super disciplined. It is not a cowboy, free-for-all approach to development. Everyone follows the simple ceremonies, and they work. It’s like a kindergarten sandpit. Here are the boundaries of the sandpit, now,… go have fun and play! But there are boundaries, and once these boundaries are set, then yes, management should give the teams the time and space, and trust them to get the job done (autonomous, self-organized, least micromanagement). So in scaling agile, we are aligning a system of teams in an orchestrated, disciplined way, but fostering freedom and autonomy to stay super nimble, adaptive, fast-moving and iterative.

Let’s briefly explore some of the frameworks available. Keep in mind, expanding or scaling agile across the organization does not work if agile at the team level is flawed. Scrum must be working first, at its core. Without solid agile health, at scrum/team level, none of the scaled agile approaches will work effectively.

• Scaled Agile Framework (SAFe®) SAFe® speaks to teams and people fitting under a System that ultimately can manage agile teams enterpise wide. Their main ’schtick’ is all about planning at scale through ‘Program Increment (PI) planning’. This, quickly, is gathering all the many teams that work on a common set of features or products, into a 2 or 3 month increment, plan for it, and manage the work accordingly along the way. The key to SAFe® working well, is everyone, including the Business, need to be invested in medium range planning beyond the ‘sprint to sprint’. More like 5 or 6 sprints at a time. Everyone also needs to respect this PI just like a sprint, and protect it like a time box iteration, for it to work. I, for one, love the PI Planning event, because it provides transparency and accountability for all teams and all stakeholders around a common set of goals and deliverables. I even make a big party about it, so that it provides 4 big moments a year where teams can celebrate. What I don’t like about SAFe® is it’s loaded with new terms, acronyms and definitions that need to be trained and creates a little more rigid process than is ideal, which is a little counter-intuitive to agile. Plus I find the certifications expensive to certify an entire organization. You either go all-in, or you don’t with SAFe, and because of the price tag, it’s ‘Big Business’. SAFe has a lot of processes and nomenclature that, if not adopted to a tee, can seem like your agile transformation has failed. That being said, I prefer SAFe to foster an ‘all together now’ practice of teams working together. The way I do this is I ensure that all the scrum teams are starting at the same time. E.g. PI1, S1. Program Increment #1, and then Sprint #1. All teams start on the same day, and therefore can adopt same release train schedules. SAFe also provides a clear growth path hierarchy for team members - scrum master to RTE, developer to solution architect, Product Owner to Product Manager. You can stay at team level, or you can move to program level across multiple teams, within the ART, agile release train (all the teams required to deliver from $0 to cash).
  
  

• Large Scale Scrum (LeSS) LeSS is a framework for scaling scrum to multiple teams who work together on a single product, starting with a foundation of one scrum team and applies to multiple teams who work together on one product. It keeps a simplified model to expand teams, and fosters several teams sprint planning together with not just the scrum product owner but an area product owner to help coordinate both refinement and planning. There are many similarities between LeSS and SAFe. Both start with scaling a scrum team and incorporating principles such as lean thinking, continuous improvement, and customer-centricity. However, LeSS differs in that it focuses on simplifying organizational structure by remaining flexible and adaptable, where teams are feature-oriented, customer-centric and their approach is multi-component. LeSS teams are a little larger, with 8-12 members. Basic LeSS has 2-8 Teams and LeSS Huge is designed for more than 8 teams. These teams coordinate and collaborate together but in this framework, the scrum master may facilitate 1-3 teams, and then there is an area product owner manages 1 common backlog for up to 3 teams, working with the scrum product owners. A chief product owner leads the area product owners and focuses on the entire product.
  
  

• Scrum of Scrums / Scrum@Scale The Scrum of Scrums methodology was first implemented in 1996 by Jeff Sutherland and Ken Schwaber, who founded the Scrum framework. It simply connects multiple teams who need to work together in a set of ceremonies and best practices to keep the teams aligned. Scrum of Scrums offers a way to connect multiple teams who need to work together to deliver complex cross-functional solutions. It also promotes small team sizes, as I’ve previously discussed, to keep collaboration and communication effective. Scrum of Scrums is an ideal first step for scaling teams without all the hoopla bureaucracy of acronyms, certification costs and need for management buy-in. It’s extremely nimble and easy to start doing, in any part of the organization, and in fact, most agile organizations do Scrum of Scrums organically. LeSS is Scrum applied to many teams working together on one product. With SoS, each team is working from their own backlog. With LeSS each team is working from the same backlog. It sounds simple but can become complex, in either solution. It just depends what problem you are trying to solve. The expanded methodology around SoS is Scrum@Scale. This brings in a full organization into the SoS discipline, by adding more Scrum of Scrum of Scrum (SoSoS). There is a fabulous book recently published called, ‘Scaling Done Right’, by Gereon Hermkes and Luiz Quintela. I highly recommend this book. It breaks down how to scale ceremonies and teams across entire organization. Simply put, by having all the ceremonies, from standup to SoS standup, to EAT standup (executive action team) all before 10am, the entire organization is in the know and unblocked before starting the day.
  
  

• Nexus Framework Nexus is an Agile framework that has 3-9 Scrum teams, each made up of 5-9 team members, and there is one common product backlog used by all of the teams, similar to LeSS. The essence of the Nexus framework is the integration team - the Product Owner, Scrum Master, and one or more members from each team, usually high-performing developers, who coordinate the work across the teams to ensure work that is completed is integrated without conflict. This can be particularly useful when different teams are working on the same code base and/or working on the same product backlog. During the sprint, multiple integrations occur daily identify and resolve coding conflicts, and the rule is the teams must integrate their code at least once daily. While this sounds like their core value prop, ideally all teams in all agile frameworks should attend to proper code practices. This is not isolated to Nexus Framework.
  
  

Outside of following SAFe, Scrum LeSS, Scrum of Scrum/Scrum@Scale (team of teams), or Nexus, there are various other scaled agile frameworks and planning approaches that can help many teams in an organization synchronize together, including but not limited to big room, midrange, quarterly, or rolling-wave planning (e.g., month to month). However you scale Agile teams to beyond a few, there key drivers for a scaling framework are:

• a need to collectively align several or many teams together – e.g., to work on common feature sets, or release cohesively, or integrate into one codebase

• to ensure better collaboration and communication across the organization

• to plan together so all teams are aligned on a common vision

• to manage and mitigate risks and dependencies more cohesively, and therefore reducing bottlenecks, wait time and dependencies.

Waste in an organization is the number one slow down of teams. Reducing waste through careful team of teams orchestration can help speed things up. Providing a structure like SAFe, LeSS, Scrum of Scrum, or Nexus certainly provides that.

When Agile at Scale Does Not Work

• When there is a lack of a strong engineering foundation. You cannot scale scrappy code. If there is a lack of engineering best practices for architecture, coding, code review, branching and merging strategies, technical documentation, as examples, then using any scrum or agile at scale methodologies will not fix inherent problems.
  
  

• When there is a lack of management buy-in. In one company, I managed agile transformation, overseeing the PMO and all agile practices. In another company, I also managed agile transformation, overseeing the PMO and all agile practices. In both companies I implemented the exact same practices, to a tee. But it only worked successfully in one company. Why? I believe it was tied directly to management buy-in. In the company where it worked, I had complete trust and understanding from leadership to lead a team to transform the company. And this trust also infused into the culture of the company, where the teams also trusted the process. This kind of trust allows opportunity to take positive risks for change. Whereas if you don’t have buy-in from management, then the culture around you also doesn’t ‘buy-in’ as there is a lack of trust. And therefore, it’s very hard to create positive change. But if we get back to basics and ensure agile and scrum is working at the basic level, with optimum agile health, then you will get buy-in from management, as they see it working.
  
  

• When the culture cannot adopt change. Buy-in on new processes by teams is bred by them feeling self-empowered and self-organized, rather than feeling oppressed and prescribed to. Teams will not adopt change if they don’t see that it will work. Here are some ideas to help build change culture:
  
  

  • building a culture of transparency, communication and collaboration.

  • allowing for self-organized teams, rather than overly-managed teams.

  • giving opportunities for employees to have a say in the future of the roadmap, e.g., a forum for ideas, innovation (Hackathons are a great way to do that).

  • creating a feedback loop – written or in-person feedback sessions where teams can talk through process and practices, give ideas, and learn more about how new practices can help improve. This starts with really strong and predictable team retrospectives. But It’s also good to do it cross-organizationally with various think tank groups.

Step 4: Scaling resources, uh hum, people

I hate that word: Resources. Have you ever looked your web developer in the eye and said, “Hi, resource”?

No, you haven’t. That engineer is a person. A real person. Not a dot on a map. I have too often been involved in ‘headcount meetings’ where we are talking about heads, resources and budget. But we forget we are talking about human beings. Let’s change the dialog and start calling our team members who they really are: people.

Ok, now that I’ve gotten that out of the way, the final Coup D'état in the whole SCALING conversation is this: when you have fixed your agile process, like, literally, all the mechanics under the hood; when you have worked through how you will plan and execute as multiple teams collectively; then, and only then, is it time to talk about scaling up with more people. This is the time, and only the time, you knock on your HR and Finance Department doors to open dialog on scaling up with more people.

As a reminder, from the first section of this piece, slapping people on top of poor process will not fix the problem. It just exasperates it. But if you feel that you’ve established some fundamentals in how everyone works and delivers together, then we take a look at the size of the teams.

As mentioned earlier, the best size of a team is about 4-7 people. To be able to burn down multiple, competing, and equal sized backlogs at the same time (therefore delivering more, in the same release train), we may need to consider expanding the teams. Not adding more people to the same team. That is counter-productive. Adding more to the team, as previously mentioned, will not speed things up. It actually slows things down, due to the point of diminishing return. With small, stable, and steady teams, they remain efficient.

So, with that all clear, now is the time to evaluate whether adding more people will genuinely improve the collective teams’ ability to deliver more work. But do not add to existing teams; instead, add more teams. Consider bringing in more software engineers, testers, and designers. Crucially, consider fewer managers. With the framework defined, you actually need to maintain a lean management team.

I cannot tell you how many times I have witnessed resource planning that is so top-heavy with management. The fallacy is that leadership misinterprets the need, believing more managers will manage the work more effectively. However, what we truly need are more people doing the work and fewer managers, so that managers can step aside and allow teams to be more autonomous and self-organized.

When adding people, think holistically. If Engineering needs more developers, you want to approach it from a team makeup point of view. You will need a Scrum Master, a Product Owner, and a Tech Lead. You will need quality testers or automation engineers. Perhaps a designer, and other necessary members. You may also need a Scrum of Scrums Master or an Agile Release Train Program Manager to oversee this tribe/program/pod/team of teams. And perhaps an Area Product Owner or SAFe Product Manager for the collective teams. What I’m emphasizing is, you don’t just hire in a vacuum for one particular need. You hire teams.

And once you bring a new team onboard, you want to give it some time to become well-performing. It takes about 3 months for a team to develop a reliable sense of velocity. Three months! This is precisely why simply slapping on more people to solve quick problems and expect fast results does not work! People are valuable and should not be underestimated. They should be added with care, and integrated into a disciplined agile system that can nurture their growth, build a positive culture, and ultimately bring high value to the organization.

Where along the path has your company traveled in scaling agile?

Is your company willing to invest in the time it takes to establish high performing agile teams? Are you clear with your planning, in a consolidated fashion that supports team of teams/agile release trains?

To end, a little agile lesson: the 12 principles of agile

from the 2001 agile manifesto1:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

• Business people and developers must work together daily throughout the project.

• Build projects around motivated individuals.

• Give them the environment and support they need, and trust them to get the job done.

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

• Working software is the primary measure of progress.

• Agile processes promote sustainable development.

• The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

• Continuous attention to technical excellence and good design enhances agility.

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

• The best architectures, requirements, and designs emerge from self-organizing teams.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Alright. I think I’ve overdone it. Three parts to one article. Everything you need in one kit to scale with agility.

Time for a vino.

To your agility,

Gilli Aliotti

CONTACT ME FOR MORE ABOUT THE AGILE WARRIOR STRATEGY SESSIONS - I WORK WITH C-SUITE AND LEADERSHIP ON TUNING AGILE ORGANIZATIONS

If you missed Part 1, read it here first. I particularly dove into some misconceptions about how to scale your teams to deliver results - and it wasn’t about just adding people….

It requires surgery. So let’s dig in to the next part.

But before I do, let me remind you of who I am and why you’re reading this:

Welcome again to The Agile Warrior. Hi, I’m Gilli Aliotti — executive coach, tech leader, creative rebel, and your agile hype woman.

Over the last 20+ years, I’ve led agile transformations and strategic programs at Google, Yahoo, Paramount, PayPal, Disney, and a bunch of startups, helping teams and businesses thrive at scale. I’m a certified master business executive coach, SPC5 Scaled Agile Consultant, Six Sigma Black Belt, ICAgile Coach (ICP-ACC), MBA Grad, and founder of a few startups myself, and a passionate advocate for agility in tech, business and entrepreneurship. < 😮‍💨 Breath 🧘🏼‍♀️ >

My superpower? Helping bold humans lead with clarity, creativity, agility and courage — in work and in life.and I’m going to share a 3 Part article around how to scale your teams using AGILE because, this is The Agile Warrior, my favorite side hustle all about, well, agile. Welcome to Part 2, or Step 2. Read on and stay subscribed to read all 3 parts (the final post will follow soon into your inbox).

P.S. Know Agilists? Coaches, Scrum Masters, Product Owners or Tech Leaders? Forward this to them to subscribe.

​Step 2: Optimize your agile predictability to scale

What is your organization’s true agile health? Have you rigorously analyzed any clear KPIs – Key Performance Indicators – to truly quantify how well your teams are performing? Optimizing your current agile health for predictability is the crucial next step before ever considering scaling headcount. This article isn't designed to be an exhaustive tome on the entire spectrum of agile concepts – that would fill a hundred books. What I will endeavor to share are some of the key aspects of agile adoption that serve as a fundamental precursor (or a vital solution) to the ultimate goal of scaling: predictability.

Setting Agile Metrics

At its core, Agile methodology offers a powerful framework that enables teams to perform exceptionally well when adopted successfully. Agile was originally conceived to streamline, improve, and rapidly accelerate the development process through short, iterative, interactive time-boxed sessions that provide early, invaluable feedback on the product. It is an art to be agile.

Most organizations claim to be agile, proudly showcasing all the ceremonies, practices, and structures, but usually, there are inherent, subtle flaws in their execution. I could write an entire book on just that! Suffice it to say that Agile can standardize company-wide processes and methodological alignment and thereby scale cross-organizational ability for increased flexibility, productivity, transparency, stakeholder engagement, satisfaction, quality, and ultimately, significantly decrease risk to hit the strategic objectives.

If done right.

Effective agile development practices include, but are not limited to: a common, robust development practice (whether pair programming, Extreme XP, or other forms of speedy development); Scrum or Kanban team structure and project management; meticulous code review processes; well-defined branching and merging strategies; rigorous testing principles and clear guidelines for forming and following test cases; seamless continuous integration; and ultimately, a clear path for the team to deliver working product through frequent releases. All these engineering practices are absolutely critical for building and maintaining truly high-performing teams and must be upheld to enforce delivery performance and consistently deliver excellent customer value.

Agile methodology also relies on a set of simple but profoundly effective agile ceremonies, fostering the time-bound increment such as a sprint, or a WIP model within Kanban, committing to shipping to customers iteratively with predictability, and relentlessly striving for high-performing agile teams.

As a key milestone for sustainable organizational growth, I am an unwavering believer in predictability.

When Agile practices are clearly defined and standardized – such as predictable ceremonies of standup, sprint planning, sprint review, and retrospective – as well as operating in a predictable MVP delivery cadence, it provides an unshakeable foundation for organizational predictability. And when you achieve predictability, you can truly begin to measure the health of your teams. You can accurately measure your company’s success.

Once agile teams are genuinely doing and being agile, and their agile health can be precisely measured, you can then use these metrics to assess improved accountability, accelerated performance, and heightened collaboration. Then, and only then, can you scale/expand to eternity.

The more orchestrated and aligned your current teams are, the easier it becomes to thoughtfully add new teams and people into the established framework. (We’ll delve into different frameworks later.) Getting the ceremonies and core agile practices right, as your absolute highest priority, will ensure a smooth and successful transformation to a scaled approach. The intrinsic agile infrastructure must be solidly established before adding more people, and indeed, before adding more process.

One last, critical word on this: doing agile is fundamentally different from being agile. You can meticulously follow all the prescribed practices and still completely miss the mark. Being agile is about cultivating a deep organizational mindset centered around transparency, shared responsibility, understanding that change is inevitable and embracing it, as well as fostering greater involvement from everyone1.

There are truly only four key values to agile, and yet so many organizations needlessly complicate them:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan Living by these values unequivocally sets your organization up for a true agile mindset.

Autonomous, Cross-functional Team-Structure

For an agile team to truly achieve sustained success, it must be cross-functional. This means that everyone directly responsible for developing, testing, delivering, and maintaining the product, as well as those who receive feedback from users, should be on the team and have a predictable cadence for ruthless prioritization.

Here are the core contributors to an exemplary agile team:

• Scrum Product Owner: Responsible for the team's delivery, the ‘PO’ serves as the crystal-clear voice of the business and, ultimately, the customer. The PO relentlessly focuses on providing the highest priority features based on maximum user value (attuned to continuous feedback). They are accountable for ensuring the work for upcoming sprints (aka ‘Product Backlog’) are groomed and ‘stack-ranked’ (ordered top to bottom by priority). This way, the next sprint can be planned seamlessly, and the team can ‘pull in’ the next highest priority PBI (Product Backlog Item).

• Scrum Master: The Scrum Master is the guardian of the process and acts as the servant facilitator of the agile team, expertly shepherding them using agile ceremonies, meetings and practices. The SM ensures the team remains laser-focused on the right work and keeps the team unwaveringly committed to completing the sprint with minimal distractions. They are responsible for proactively helping to remove impediments by clearing potential roadblocks and escalating as needed.

• Scrum Members: These individuals are the heart and pulse of the team and include developers, testers (both QA as well as any other members who will test), designers and anyone else responsible to ensure the cross-functional team can act independently to develop, test and deliver the product to market.

The most successful agile teams I’ve witnessed have been inherently cross-functional, where they have the minimum amount of outside dependencies to get the work done, and everyone needed to do the work is on the team as scrum members. Every single outside dependency, no matter how minor, will inevitably slow the team down. If you have an agile team composed entirely of backend API developers, and another agile team consisting solely of frontend developers, and they depend on each other to deliver a user story, this immediately creates a cross-team dependency. This will undeniably slow both teams down, waiting for the other team to deliver a piece of functionality to the other team. Similarly, if you lack testers on the team and are forced to hand off code to another team for testing, that will drastically impede progress. Keep your quality testers and developers on the same team. (Better yet, train everyone on the team to test!)

When a team is self-organized and autonomously capable of delivering product to market, it profoundly increases productivity, transparency and communication.

The moment you become dependent on another team to develop and integrate, you are setting your team up for constant impediments, and this drastically slows the pace of the team, as well as significantly drops morale because team members are having to wait on outside forces to finish their work, and therefore, they are ‘stuck’ and feel like they have failed their sprint commitment. Self-organized means that the team doesn’t need constant governing from outside the team. Between the product owner, scrum master and the scrum members, the team can effectively make decisions for a successful delivery.

You need everybody on the Island that needs to be on the island to complete the work. This means that if the team is relying on another team to complete the work, then they will never be self-organizing because they always have to hand-off to another team, or wait for another team, to meet their acceptance criteria, and this creates waste – delays, bottlenecks and dependencies that will slow the team down.

Sure and Steady

For an agile team to be truly successful, it needs to be steady and stable. This means that the scrum team members are dedicated to the same, single team on an ongoing basis, developing, experimenting, sprinting and delivering together. The profound benefits of a steady team includes building positive culture, fostering stronger communication, and enabling highly effective collaboration. Over time they become more predictable in what they can deliver by when, dramatically increasing their ‘velocity’.

With a steady team, the backlog, then, may change, while the team itself remains a constant.

Tuckman’s ‘Stages of Team Development’ – forming, storming, norming, and performing – are critical to understand. According to Tuckman2, every team must progress through these stages to ultimately achieve peak performance. If team members are constantly changing, or even if one member leaves or one arrives, they start all over again. It takes significant time and dedication to forge truly high performing teams.

So, keeping all team members together over a long period of time actively fosters predictability. And with predictability, we can accurately assess the true success of our teams.

Team Defines ‘Done’

The team also collectively establishes its own definition of ‘Done’. This crucial agreement is built into using acceptance criteria (AC) for every user story that is planned in every sprint. Microsoft Press defines acceptance criteria as “Conditions that a software product must satisfy to be accepted by a user, customer or other stakeholder.” Google defines them as “Pre-established standards or requirements a product or project must meet.”

It defines how a particular feature or desired outcome could be used from an end user's perspective and places a strong focus on business value. The AC clearly establishes the boundaries of the scope and directly guides development. Without clear AC, the scrum team often lack clarity, or interpret differently, what constitutes acceptance for a story or task. In my experience, I've witnessed multiple "cat fights" erupt over what is acceptable to mark a task 'done' in a sprint, and this invariably stems from the confusion or non-clarity and lack of agreement of what "acceptance" means.

Therefore, AC is absolutely critical for the successful completion of the story, and quite frankly, for the success of a high performing scrum team. Creating a common understanding and standardized use of the ticketing tool, like Atlassian Jira, helps productivity, reporting visibility, and ultimately the ability to scale teams with a ‘rinse & repeat’ formula. We want to make sure, as we grow, that while teams are self-organized, they are not renegade and ambiguous in how they operate and their definition of done. All teams under the same agile release train should share a common understanding of development and code practices, plus workflow and communication processes. This will help create a common understanding of definition of done for teams, when scaling. This creates predictability in process. Common use of ticket types (epics, stories, bugs) as well as how feedback is provided (commenting, or other mechanism) should be consistent across the agile teams within a release train. Standardizing the development workflow within the team’s ticketing tool can ensure a common understanding of the ‘Definition of Done’ and remove ambiguity on the approvals and completion of work, as well as reduce impediments during the sprint. i.e., when does code review happen, or handing to QA or at what stage is product review? In using Jira, Rally or a ticket tracking tool in a common way, one can modify the board workflows so that there is a similarity across teams, under the same release train. Providing documentation on development and code practices, branching and merging strategies, tools like bitbucket, GitHub, Jenkins, as well as specific tech stack practices should be well documented for team members. How scrum ceremonies are practiced for the team, and the expectations of sprint, should be outlined by the SM, and easily understood and respected. Clear and easily understood Feature documentation provided in well-written user stories and acceptance criteria, within the ticketing tool as well as supporting documentation, should be available and likely similarly written for all teams and release trains.

​All of the above should be available and transparent to anyone in the organization, so that everyone contributes to the success of all the teams in a unified way. We want to avoid silos of information, ambiguity or rabbit holes. When everyone is aligned, we all can successfully deliver to market, together.

OK stay subscribed because Part 3 is coming next.

To your agility,

Gilli Aliotti

CONTACT ME FOR MORE ABOUT THE AGILE WARRIOR STRATEGY SESSIONS - I WORK WITH C-SUITE AND LEADERSHIP ON TUNING AGILE ORGANIZATIONS

How many times have you heard this echo reverberating through your organization? “We need more people!” “We need to scale!” ‘We’re scaling!” “It’s time to scale” “How do we scale?”

If you’re part of a management team, these statements might surface in clandestine executive strategic meetings, or publicly at a company Town Hall, where senior executives proudly tout tales of expansion and ambitious growth. Sometimes it feels like a triumphant celebration – “Yes! We are scaling!” Other times, it carries the ominous weight of an impending threat – “Oh no! We better scale…”

Yet, very few times do we truly grasp how we’ll achieve it, or even, why we should “scale” in the first place. In this article, I will reveal how to strategically scale your organization using agile methodology, enabling you to meet critical business objectives, sharpen your competitive edge, and consistently deliver with unwavering quality. Crucially, I’ll also expose why simply throwing more bodies at a problem, under the illusion that more people equals more results, can actually make things dramatically worse. Scaling teams demands an unshakeable foundation. You cannot build growth on a weak base; true scaling begins at the very core of a truly high-performing agile team.

Welcome to The Agile Warrior. Hi, I’m Gilli Aliotti — executive coach, tech leader, creative rebel, and your agile hype woman.

Over the last 20+ years, I’ve led agile transformations and strategic programs at Google, Yahoo, Paramount, PayPal, Disney, and a bunch of startups, helping teams and businesses thrive at scale. I’m a certified master business executive coach, SPC5 Scaled Agile Consultant, Six Sigma Black Belt, ICAgile Coach (ICP-ACC), MBA Grad, and founder of a few startups myself, and a passionate advocate for agility in tech, business and entrepreneurship. < 😮‍💨 Breath 🧘🏼‍♀️ >

My superpower? Helping bold humans lead with clarity, creativity, agility and courage — in work and in life.and I’m going to share a 3 Part article around how to scale your teams using AGILE because, this is The Agile Warrior, my favorite side hustle all about, well, agile. Welcome to Part 1, or Step 1. Read on and stay subscribed to read all 3 parts (the other posts will follow soon into your inbox).

P.S. Know Agilists? Coaches, Scrum Masters, Product Owners or Tech Leaders? Forward this to them to subscribe.

OK,… back to the writing…

Let’s unearth the real meaning of ‘scaling’ in our context.

Dictionary.com defines Scaling as, “the removal of calculus and other deposits on the teeth by means of instruments.” You know, also referred to as a deep cleaning. You all go to your dentist on a regular basis to do this, right? At least I hope you do. Alas, for the context of this article, I don’t mean this type of scaling. But funnily enough, I’ll explore how there is quite a profound similarity.

Scrumdictionary.com offers a more relevant perspective, stating Scaling is, “the changes in Structure and Governance that enable successful growth (or reduction) of production." "In general, the increase or decrease in one or more dimensions of an organization in order to improve success.” "The word 'scale' is often used as shorthand for 'scale up', which means “to increase the size, amount, or extent of something.” "The terms 'scale back' and 'scale down' are used to mean "to decrease the size, amount, or extent of something.”

Further, for all you agile geeks out there – yes, you, reading this blog – ‘Scaling Scrum’ explicitly refers to actual team structure: “… has more than one Team (either Scrum or Development) working together to produce Results.” Now that we’ve navigated the definitions, let’s deeply understand why we should scale anything at all.

For the sake of this article, I will focus on product development within a technology-centric company, though these principles are universally applicable. I’ll share a firsthand example from my past work experiences. One day, the Head of Product at our modest-sized Tech Startup approached me, his brow furrowed: “Gilli, we desperately need more output. We’re not finishing our feature development on time, we have a very long roadmap of features to do; the boss keeps asking for more; there’s a lot of pressure to succeed, and we’re noticing our teams never finish the tasks in their sprints. We need to improve our success at delivering our features. Can we hire more people and scale up?”

My answer was: “Yes, and… …we also need to take a hard, honest look at how we are currently working too.”

Scale people or scale agility? That is the question.

Simply throwing a bunch of new people at a problem, believing that more individuals automatically translate to more results, can paradoxically make things much worse. Consider the significant, often hidden, costs of hiring, including but not limited to:

• Financial Cost: Whether a full-time hire or a contractor, there's a substantial financial outlay. This includes not just salary dollars, but also the costs associated with recruiting time and comprehensive onboarding.

• Time & Administrative Burden: The entire hiring process – from recruiting and interviewing to the extensive administrative tasks of onboarding – takes time and administration. This extra overhead can become a heavy burden on an already strained internal workload, time that would be far better spent focusing on development.

• Ramp-Up Time: Once a new hire joins, plenty of data shows it can take a full three months before they become truly “useful” (blunt, but true!). There’s always a vast amount of knowledge and culture to absorb before they genuinely provide value. Within an agile team, adding any new person means they have to start their velocity all over again, and that can feel like a tangible step backward in performance. This translates to a considerable investment in knowledge transfer and ramp-up, actively diverting time and focus from the productivity of your existing team members.

Quite frankly, attempting to solve complex problems by merely slapping on more people is myopic. You must take a holistic view of the entire picture. Adding even one more person may not just be expensive and time-consuming, but it might also completely miss the true root cause of your underlying problem.

Improving success and getting more done does not inherently mean we just increase headcount, team size, or the number of teams. That's akin to slapping a band-aid on a fractured leg and expecting it to heal. We can only consider increasing people and teams as a supplementary solution, never the primary go-to fix. We have to heal the wound first.

Just like “scaling” your teeth by removing all the food waste, the foundational step is to ensure the mechanics of your product development’s organizational capabilities are truly functioning optimally, to remove waste, increase speed and build high-performing teams. So, before you even contemplate the expensive exercise of scaling with people to get more done, it is absolutely critical to meticulously assess and aggressively optimize your existing internal processes, including fine-tuning your agile product development approach, methodology, and frameworks.

Fixing the internal dynamics and operations – how your existing people in the organization work together, communicate together, interact together, and plan together around core business objectives – is the fundamental first step. Only once that is optimized, can you strategically consider adding people. Scaling teams demands a strong base. You simply cannot scale on a weak foundation.

Just like teeth, an organization’s internal development processes don’t just need a little 'scaling'; they might even need root canal surgery! Oxygen. Tools. Light. Let’s dive in.
​

​Step 1: Understand the Value of Time.

Should we ramp up resources to meet the capacity of the work? Or should we work to the capacity of our people? That’s something to deeply ponder, isn’t it?

Unless there is a crystal-clear business KPI that mandates an X% increase within a specific timeframe, the most prudent and effective solution is to implement proper capacity planning. This means:

Plan X amount of work based on the X capacity of the team to achieve X results within X time period.

Seems simple, right?

Adding work to a team that demonstrably lacks the capacity to complete it – no matter how hard you push them – sets both the team and the entire company up for inevitable failure. It is physically impossible. Instead, plan strictly to the capacity of their actual output in that given timeframe. This begins with gaining absolute clarity on what you genuinely need to accomplish by when.

There is so much to consider, but the very first question to ask is, “What do we truly need to accomplish?” Taking a hard, strategic look at the Strategic objectives of the organization or specific project is the essential first step. I always gravitate towards the Roadmap: What are we striving to accomplish this month, this quarter, this year? Regardless of the timeframe, resource planning (managing people capacity) must critically align with the strategic planning strategy (what we are trying to accomplish).

It all boils down to Time. Do we need to accomplish our objectives this week? This Sprint (2 weeks)? This month? This Year? Or do we not know?

Even better, do we need to be time-bound at all? Can we incrementally deliver results? Can we start with something small and then continuously improve it over time? Naturally, as an Agilist, my answer is a resounding, “Yes, let’s do it this way”. Because if we can embrace a more agile delivery approach, time is subjective. What we ultimately discuss instead is, “What value can we deliver in 2 weeks, based on the capacity of our team?” versus “When can we finish this giant project that seems to be taking forever?”

We all crave quick results, right? Take option 1: incremental value. It doesn’t matter how large or small your team-size is (except for productivity metrics, which I’ll touch on later); instead, we fundamentally shift the dialogue to Value.

If you haven’t yet introduced agile and lean processes to genuinely improve the delivery of your high-value, quality products to your customers, then, (cough), this entire subject is likely far too advanced for your current stage. Go back to square one – adopt agile methodology throughout your organization.

But what if, indeed, your agile health sucks? Perhaps you think you’re ‘doing agile’ but what you’re really doing is saying you're agile, and everything points to simply slapping more people on the problem, instead of actually fixing the problem.1 Let’s explore how leveraging the value of time actually works within agile methodology:

Timebox - Adopt an MVP Development Mindset.

A Minimum Viable Product (MVP) is a core Lean Startup concept centered around delivering a product or its features to users that provides just enough feedback and learning about the customer's experience, while requiring the absolute least amount of effort to deliver. I have always cherished and utilized this diagram for all my agile training and planning sessions. Always strive to deliver something immediately useful. Not something a user cannot use, and delivered within a short timeframe (e.g., at the end of a 2-week sprint). If you aspire to build a Porsche, complete with all the bells and whistles, it will take a considerable amount of time. But perhaps you can start by riding a skateboard. Then iterate and build a scooter. After that, a small car. Then you can add the bells and whistles. You cannot, however, do anything useful with just one wheel. Witnessing what people actually do with your product is infinitely more reliable than asking them to merely imagine what your Porsche will be like by holding a useless wheel.

Timebox the work. Agile is a project management methodology2 that consists of small development cycles, also known as ‘sprints’, specifically designed to maintain focus on bringing continuous improvement in a product or service.3

It’s funny – I’ve had so many people tell me that agile isn't about deadlines. But indeed, a Sprint IS ALL ABOUT a time-bound period where the team commits to finishing tasks within a predetermined timeframe, typically two weeks. Therefore, plan the work strictly to the capacity of the Sprint, and critically, to the capacity of the people within the team. Do not over-plan. In Agile SAFe (agile at scale), we similarly plan to the capacity of a Program Increment (PI) – usually a quarter, comprising five (or so) Sprints. Whatever the timebox, plan to that, based on the people you actually have. This is a loaded statement. It requires incredibly robust Agile maturity to execute truly well, including but not limited to: a team’s ability to estimate/size effectively; the maturity of your Scrum and Sprint processes; the maturity of agile release processes, Dev Ops continuous integration and delivery maturity, and maturity of your agile planning processes and ceremonies.

It is crucial to understand that MVPs do not imply delivering minimal products quickly for no inherent reason. It means we are consistently delivering to market, regularly, for a deliberate purpose: to gain rapid user feedback in order to incrementally improve the product further. And this means that each sprint we aim to provide some tangible user value, even if small, to elicit that crucial feedback. Simply put, your customer needs to be able to use or experience whatever is delivered/provided to them, and in small, incremental ways, so that you can continuously enhance that experience.

This requires conscious effort and unwavering discipline.

When I was working for a Hollywood Startup, spearheaded by a very famous musician, building AI-integrated music apps and products, we launched nothing of note in the two years I was there – much to the chagrin of all of us, especially me. What’s the point of tirelessly working on something if you don’t even know whether customers will actually like it? In stark contrast, at another company, I managed to slash their product release cycles from every eight months down to monthly releases. That was a monumental improvement. We then accelerated even further, to releasing every two weeks. All of which required deep "root canal therapy" on their existing agility to reach this release nirvana.

Suffice it to say, if we embrace an MVP Mindset, and we plan, execute, and deliver in short increments, you will advance tremendously towards working effectively within the capacity of your current people. This is incredibly healthy, not just for business outcomes, but also for organizational culture. Everyone gets genuinely excited when they actually finish something. It costs significantly less to keep your current, happy people, and exponentially more to hire and replace them.

Ship Frequently

One of the 12 foundational principles of agile is to ‘deliver working software frequently’.

This can range from within a couple of weeks to a few months, but the resounding recommendation is shorter rather than longer. One of the primary reasons for this is to ensure the core tenet of agile: gaining feedback early to continuously improve the product. Lengthy release timeframes can often result in deeply dissatisfied customers and clients, simply because the team, operating in an insulated bubble without feedback, can easily venture down the wrong rabbit hole. That represents immense waste when you're forced to re-do features or change directions simply because you failed to gather early feedback.

So, the very heart of Agility is incremental delivery, within short timeframes. This is eloquently embodied in ‘Sprints’. At the end of each sprint (iteration/cycle), the team delivers something of tangible value. Note the word ‘incremental’. This is a key concept that is often profoundly misunderstood. Every time we aim to deliver something to users, we want it to be incremental and rapid. Consider a new feature. Sometimes a comprehensive new feature could take months to develop and release. But if we’re able to slice it down into several parts of the feature release, each still providing value to the user, then we are able to test it with our customers early, before we finalize the entire feature. This is the MVP: Minimal Viable Product. Or even more microscopically: Minable Viable Feature (MVF).

Here’s a good example: Let’s imagine the complete feature (for a pretend travel site) is to allow a user to sign up, search flights and book the flight of their choice to a destination, and receive an email receipt. At first glance, this is quite an undertaking – maybe even more than a month of work for a single team.

But to release incrementally, MVP style, one powerful approach is to slice this down into shippable increments, meaning in the first increment, a mineable viable feature works on its own, and then we add more in the second increment, and then in the third and so forth. Consider it like making a cake and then adding the layers, the frosting and then the cherry on top.

One suggestion for the first release could be to allow anyone to search best flights and add to a saved history. These flights could be searching the internet using other travel carriers like Expedia, booking.com or the like. For the second release, the user could then create an account on xyz travel site and save the search settings in their own personal user account. The third release could provide a way for the user to purchase from xyz travel company (rather than a third party). The fourth release could be that the user receives an email confirmation. And so forth.

I’m over-simplifying this feature, of course, but you absolutely get the gist. Break it down into bite-sized, incremental releases. The kicker is this: the releases happen after each sprint. Ideally, we Sprint and Ship. I practice and preach this relentlessly. The more we can establish a routine of releasing after every sprint, not only do we create a predictable timeframe for releases that the team and stakeholders can reliably count on, but it also instills an excellent team discipline. This discipline ensures they only plan just enough in the sprint that the team, as a unified whole, can, together, design, develop, and test. This means we master the art of slicing features, and user stories, down to smaller chunks of work that allow the team to complete, all while consistently collaborating, communicating, and working together more effectively.

The cherry on top? The team experiences a profound sense of achievement by consistently delivering to and delighting customers frequently.

“Yes! We did it! We launched XYZ!”

We all love those feel-good moments, don’t we?

OK, PAUSE there. Lots of info, right?

More coming in upcoming posts. Remember, there are 3 Parts to this article.

Till then,

To your agility,

xo,

Gilli

CONTACT ME FOR MORE ABOUT THE AGILE WARRIOR STRATEGY SESSIONS - I WORK WITH C-SUITE AND LEADERSHIP ON TUNING AGILE ORGANIZATIONS

Once upon a time, I was just another project manager, navigating the often-murky waters of software development. My role? A bit of a mystery to most. I was there to help, to guide, but often felt just outside the spotlight, the glory reserved for the product visionaries and the engineering wizards. Until it hit me: I wasn't just managing projects; I was illuminating the path for my teams through the sometimes-confusing landscape of Agile. I became their beacon, helping them decipher how to plan with purpose, execute with speed, launch those crucial MVPs, and deliver tangible value to our users, sooner rather than later. That's when I realized: I wasn't just a project manager anymore. I had evolved. I was an Agile Coach. And being an Agile Coach transcends mere planning and execution. It's fundamentally about "shipping" – getting those innovations out the door and into the hands of our users. You have to think release, launch, and market in a single breath. The team isn't just building; they're counting on you to make it real.

Forget just shipping code – we're talking about launching game-changers! As an Agile Coach, you're not just guiding teams; you're igniting innovation across the entire product lifecycle. Let's break down how mastering release rhythms and PI Planning isn't just about delivery – it's about fueling the next big thing.

Decoding the Release Flow in Hyper-Speed Development

Think of releases as more than just dropping features. They're the heartbeat of your product, the pulse that keeps innovation flowing. Understanding how to orchestrate these releases is your superpower as an Agile Coach.

What's Release Management Really About?

It's the art of moving brilliant ideas from concept to reality, smoothly and without the drama. We're talking about a coordinated dance across dev, test, staging, and the big stage – production. It’s about making sure everything is prepped, tested, and launched with precision, so those "oops" moments become ancient history.

The Evolution of Launching Awesome Stuff

• Old School (Waterfall Era): Remember those marathon development cycles? Months, even years, before seeing the light of day. Releases were HUGE, manual testing was the norm, and a late snag could send the whole thing crashing down. Talk about pressure!

• The Agile & DevOps Revolution: Fast forward, and it's all about speed and iteration. We're talking multiple deployments a week, sometimes daily! DevOps brought in automation, killer monitoring, and streamlined deployment. The result? CI/CD (Continuous Integration & Continuous Deployment) – the bedrock of rapid-fire innovation.

CI/CD: The Engine of Innovation Velocity

• Continuous Integration (CI): Imagine a constant flow of code merging into a shared space. Every merge kicks off automated checks, catching any hiccups early. It’s like having a quality control superhero on the lookout 24/7.

• Continuous Deployment (CD): Taking it to the next level, CD automates the entire release journey. Once the code passes the tests, it's on its way to users with minimal fuss. Faster feedback, quicker iterations – that's the innovation sweet spot.

Why This Matters to You, the Agile Coach Extraordinaire: You need to be the CI/CD guru, understanding how ideas translate into code, what makes them tick together, and how releases are orchestrated across all your awesome teams. This isn't just tech – it's about enabling the rapid experimentation that fuels innovation.

PI Planning & Agile Release Trains: Aligning for Breakthroughs

While CI/CD gives us the speed, PI Planning and Agile Release Trains (ARTs) provide the strategic alignment to ensure we're innovating in the right direction.

PI Planning: The Innovation Summit

Think of PI Planning as your quarterly pow-wow, where the big picture comes into focus. Every 5-6 sprints, teams sync up on priorities, map out dependencies, and tackle potential roadblocks. It’s about forging a shared vision for the upcoming innovation sprint.

The Innovation Gold That Comes Out of PI Planning:

• A Crystal-Clear Innovation Backlog: Everyone knows what we're building and why it matters.

• Dependency Mapping for Seamless Flow: No more innovation bottlenecks caused by teams working in silos.

• A Strategic Release Roadmap: We know when key innovations will hit the market.

Agile Release Trains (ARTs): The Innovation Powerhouse

In the Scaled Agile Framework (SAFe), ARTs are your cross-functional innovation squads. They work together like a well-oiled machine to deliver value incrementally and predictably.

Why ARTs Are Innovation Accelerators:

• Consistent Innovation Cadence: Reliable release cycles mean a steady stream of new value.

• Cross-Team Synergy: Breaking down silos unleashes collaborative innovation.

• Laser Focus on Business Impact: Innovation isn't just about cool tech; it's about delivering real value to users and the business.

Crafting Your 5-6 Sprint Innovation Blueprint

As an Agile Coach, you're the architect of this blueprint. You're helping teams:

• Map Innovation Delivery Across Sprints: Ensuring key milestones are hit and the innovation pipeline stays on track.

• Orchestrate Dependencies for Smooth Innovation Flow: Keeping backend, frontend, and infrastructure teams in lockstep.

• Define "Innovation Ready" Criteria: Establishing clear quality gates and deployment checkpoints for new features.

• Collaborate with Release Engineering: Aligning code freezes, staging environments, and final innovation launches.

The Agile Coach as Innovation Driver: More Than Just Process

As an Agile Coach, you're not just a facilitator; you're a catalyst for innovation. You sit at the crossroads of product vision, engineering muscle, and operational excellence. Your role is to ignite that spark of innovation and guide it through to impactful delivery.

Your Innovation-Focused Responsibilities:

• Orchestrating Release Rhythms for Timely Innovation Delivery: Ensuring that groundbreaking ideas see the light of day without unnecessary delays.

• Facilitating PI Planning to Align Teams Around Bold Visions: Guiding teams to collaboratively define and commit to ambitious innovation goals.

• Championing CI/CD Best Practices for Risk-Mitigated Innovation: Ensuring that the rapid pace of innovation doesn't compromise quality or stability.

• Navigating Dependencies to Unleash Unhindered Innovation: Removing roadblocks and fostering seamless collaboration between teams.

• Driving Stakeholder Engagement for Innovation Buy-In: Keeping leadership and teams aligned and excited about the innovation journey.

By weaving together masterful release management with agile planning prowess, you empower teams to not just ship software, but to launch innovations that disrupt markets and delight users.

Wrapping Up: Unleashing the Innovation Engine

In today's lightning-fast tech landscape, mastering release management, CI/CD, and PI Planning isn't just about efficiency – it's about unlocking your organization's innovation potential. As an Agile Coach, your ability to orchestrate these elements, align teams around a shared vision, and anticipate challenges directly fuels product breakthroughs.

Becoming a master of these domains doesn't just make you a more effective coach; it positions you as a pivotal leader in the innovation lifecycle. Whether you're in a nimble startup or a sprawling enterprise, understanding these frameworks will make you an indispensable force in driving meaningful change and shaping the future of your products. So, let's not just manage releases – let's unleash innovation!

Gilli

Gilli Aliotti doesn’t just lead agile coaches, scrum masters, product owners, tech disruptors, and lean startup entrepreneurs — she ignites them. Known for transforming teams from chaos to clarity, she helps bold humans step into their power and become true Agile Warriors.

Over the past two decades, Gilli has orchestrated epic agile transformations and strategic programs at Google, Yahoo, Paramount, PayPal, Disney and a bunch of Startups, helping teams and businesses thrive at scale. She's a certified master business executive coach (Fowler School of Business), SPC5 Scaled Agile Consultant, Six Sigma Black Belt, ICAgile Coach (ICP-ACC), MBA Grad, an efficiency expert, ..and the founder of theCrea8ve (also on Substack) which fuels startup entrepreneurs and creatives to create bold ideas, …and is developing Hummm — a platform on a mission to elevate women in tech and leadership.

< 😮‍💨 Breath 🧘🏼‍♀️ >

At the core of everything she does? A fierce belief that agility is more than a framework — it’s a mindset that unlocks momentum, mastery, and meaningful results.

Her superpower: Helping leaders rise — with clarity, creativity, and unapologetic courage.

Now, through her no-BS platform The Agile Warrior, she’s channeling her fierce wisdom into bold thought-leadership and practical tools to help teams thrive, leaders evolve, and agility get its groove back.

"Agility isn’t just how you work—it’s how you win. Success starts with the mindset to adapt, the courage to lead, and the grit to keep moving forward."

🌀 Read about The Agile Warrior on this site

💥 Learn more about Gilli at gilli.net
💼 Connect with her on LinkedIn

Check out this Interview with AdvisoryCloud.com and Gilli

"I'm always curious about how we can collaborate and communicate better. In this often dispersed technology industry, we don't always have our development teams in the "same room" able to incubate and execute together. Often we have teams in different countries working together. We're always up against bottlenecks because of this, and lots of waste is created due to separation."

AC - Tell us more about your main areas of expertise?

GA - I would say I'm an 'agile productivity coach' in the product development space. I work with C-suite to development teams to effect change and deliver fast and smart, in fast-paced technology culture, through agile methodology and various matrix team productivity processes. I'm an executive "master business coach" as well as an agile-trained coach, plus have many years experience in the digital space across technology, media, and entertainment.

AC - Describe your main motivation?

GA - I've always enjoyed advising and coaching, it's in my nature to share what I know to others once I learn them.
​I enjoy motivating people to do great things.

AC - Elaborate on the types of situations, challenges or decisions, you feel you could add the most value?

GA - I think the most challenging, and rewarding, scenarios for me are when I'm able to make an impact at the organizational level. I've been involved with several startups and seen them grow from scrappy and lean to high-performing scaling teams, launching great products. As an advisor/coach, I feel I can add the most value at an executive/leadership level, helping to change the mindset of old-thinking behavior and decision making, so that teams can be empowered to run with their roadmaps and deliver a great product.

AC - Do you see any disruptive trends on the horizon in your industry or position?

GA - I'm always curious about how we can collaborate and communicate better. In this often dispersed technology industry, we don't always have our development teams in the "same room" able to incubate and execute together. Often we have teams in different countries working together. We're always up against bottlenecks because of this, and lots of waste is created due to separation. I am fascinated by some new technologies coming out to bring people together, such as VR and AI, to make collaboration and answers delivered easier.

AC - Tell me about the most impactful project or decision you’ve been involved in as an executive.

GA - I have run many large-scale projects internationally, and for various companies, from Startups to Fortune 500. One is launching, with a dispersed, highly-motivated but lean team, AI-powered earphones plus an accompanying mobile IOS/Android App to Beta (pre-launch) phase, for the music celebrity, will.i.am, and his awesome startup. We had near impossible deadlines to get into the stores, and all of us playing multiple roles to ensure we launch on time. My most exciting launch was Paramount+, the widely adopted streaming platform. It’s an incredible thing to be able to enable over 50 scrum teams to execute and ship one of the world’s most successful media outlets, and during the lock-down Pandemic times, mind you! Oh don’t get me started on ‘back to office’ policies…. Yes, you can make shit happen without going into the office every day!

Find time to discuss your Agile needs

Agility in tech organizations is often tossed around as if it’s a buzz word, but very few are actually agile. “Oh, we are agile”, “We’re an agile shop”, “Yes, we run sprints”. But when you take a look under the hood, there are several KPIs to determine if truly an agile operation. Let’s measure your team’s agility with some of these digestible, real-life examples following the 12 principles of agile.

By Gilli Aliotti

1. Are you delivering working software that is valuable to the customer at the end of the sprint, or even better, several times within the sprint? Good job. Continuous delivery is key and delivering working software in weeks versus months.

If you are spending weeks or even months in different development phases, from analysis (requirements phase), to design, to development, to testing, and then if all is approved, released to the customer after a long period of time, you are not agile.

Requirements change over large periods of time, and by the time you gain stakeholder acceptance, they’ve changed their minds all together, let alone our customers may no longer need that feature or functionality. That is why a true agile team have smaller, iterative releases, where you can gain feedback quickly (preferably after a 2 week sprint, or even CI continuous deployment scenarios).

This way the team can learn and adjust quickly, and experiment again, without too much time in between. Rapid deployments also foster the ability to get features to market quicker.

2. Are you delivering extremely large and complex requirements to the team?

If your product owner has handed over a manifesto of 20 pages for the next feature to develop, stop right there. These waterfall type requirements are a thing of the past, and don’t allow the team to experiment on several approaches to come up with the solution, and don’t capture changing requirements as we sprint.

Simplicity is essential. Also, large requirements fosters bad habits of long-winded months on end waterfall type projects. Welcome changing requirements is key, through smaller iterations. Also clear requirements, both good design, and effective user stories enhances agility.

3. Do you not know what’s going on, and one team is siloed off from another team? How independent and self-organized is your team really?

Working together daily, together, is extremely important. Do you daily standups and share what you worked on yesterday, what are you working on today, and what are your blockers. Be self-organized in that each of the team members work as a whole to decide the implementation, and be like glue working together
to solve and test the problem.

4. Is your team self-organizing and true to their velocity? Are your team’s sprint tasks completing within a 2 week (or iterative) period? Good Job. A self-organized team with the ethos of simplicity is essential.

If your tasks are carrying over to the next sprint regularly because they are just not completing then you’re not in touch with the velocity of your team, and perhaps the team are not as self-organized as they could be. Planning according to the velocity of the team is the key to a self-organized agile team. If product
owners are pushing more work into the sprint than what is digestible, you are not allowing for a self-organized team, but instead taking a command and control waterfall approach. Allow the team members to estimate the planned tasks with story points to understand their capacity and break down those stories into
bite-sized chunks to keep the sprint actionable. Simplicity is essential both in priority, prioritization and process.

5. Are you often bringing in unplanned work mid-way into a sprint because the product owner or stakeholders say so? Consider that the best agile teams work with boundaries.

Whether you work in sprint cycles (plan and protect for 1 or 2 weeks), or Kanban (regular planning that only allows up to 8 tickets in progress at 1 time), you are always helping the team with limits, so that they can stay self-organized and working to the velocity of their team by promoting sustainable development. Build projects around motivated individuals and let them fly.

6. Are you just going from one sprint to another without reflecting on lessons learned, or areas to improve?

One of the key agile principles is to reflect how to become more
effective. We want the team to continuously improve, and the only way to do that is to reflect on what worked well, and what didn’t. As a self-organized team, they can measure their own success, be accountable for failing, be OK to fail, and continuously improve.

Sprints are, indeed, an experiment. Allowing the team to try new things, to come up with new solutions to problem statements, fosters a healthy and high-performing team.

What do you think?

Leave a comment

Read in CIO Review