Part 3 - Unleash True Scale: The Agile Warrior's Fast Guide to Organizational Agility
Stop Staffing, Start Scaling - Why More People Won't Necessarily Solve the Problem
Welcome to the final - part 3 - of my very long blog that I decided to carve up into 3 pieces so it fell into your inbox nice and tidy, and didn’t make you go crazy having to read a monologue. This blog post is all about‘Scaling Scrum’ and started ene day, when the Head of Product at a job-long-ago at modest-sized Tech Startup approached me, and said, with 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. 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
Scrum Alliance. Manifesto for Agile Software Development. Retrieved from https://www.scrumalliance.org/resources/agile-manifesto