How many times have you heard this in your organization?
“We need more people!” “We need to scale!”, ‘We’re scaling!”, “It’s time to scale”, “How do we scale?” If you are on a management team, you might hear these statements in clandestine executive strategic meetings, or at your company Town Hall where senior executives sprout tales of expansion / growing bigger.. Sometimes it feels like a celebration, (“Yes! We are scaling”). Other times it feels like an ominous thread, (“Oh no! We better scale…”) Very few times do we really understand how we’ll do it, or even, why we should ‘scale’. In this article, I will share how to scale your organization using agile methodology, to meet business objectives, stay competitive and deliver with quality. I will also share why slapping a bunch of people on a problem, thinking that more people provides more results, could make things worse. Scaling teams require a strong base. You cannot scale on a weak foundation and it starts at the core of the wannabe ‘high-performing’ agile team. Tap below to read more. 
Let’s break down the concept of ‘scaling’ a little. What does ‘scaling’ actually mean?
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 similarity. Scrumdictionary.com says 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 the agile geeks out there, yes, you, who are reading this blog, ‘Scaling Scrum’ refers to actual team structure: “… has more than one Team (either Scrum or Development) working together to produce Results.” Now with the definitions out of the way, let’s understand why we should scale anything. For the sake of this article, I will focus on product development in a Technology-centric company. But you can apply this to any organization. I’ll use one of my past work experiences as an example. One day, the Head or Product came to me in our modest-sized Tech Startup and said, “Gilli, we 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 look at how we are currently working too.” Scale people or scaling agility? That is the question. Slapping a bunch of people on a problem, thinking that more people provides more results, could make things worse because you always have to consider the costs of hiring, including but not limited to:
Quite frankly, slapping on a bunch of people to solve a problem, is myopic. You have to take a look at the whole picture. Adding even one more person may not just be expensive and time-consuming, it may not even be the answer, and certainly may not be the root cause of the problem. Improving success and getting more done, does not mean necessarily that we just increase in people, team size or amount of teams. That’s like putting a band aid on a broken leg, expecting it to heal. We can only consider increasing people and teams as an additional solution, but it’s not necessarily the first go-to fix. We have to heal the wound first. Just like ‘scaling’ your teeth, and removing all the food waste, the first thing to do is to ensure the mechanics of the product development’s organizational capabilities are truly functioning well, to remove waste, increase speed and build high-performing teams. So, before we consider the expensive exercise of scaling with people to get more done, it is important to assess and potentially optimize the existing internal processes, including tuning your agile product development approach, methodology and frameworks. Fixing the internal dynamics and operations of how the existing people in the organization work together, communicate together, interact together and plan together around business objectives, is the fundamental first step. Then, if all that is optimized, you can then consider adding people. Scaling teams require a strong base. You cannot scale on a weak foundation. Just like teeth, an organization’s internal development processes need a little ‘scaling’. Or maybe 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 ponder, isn’t it? Unless there is a clear business KPI that says we need to meet an x% increase within a certain time period, the most prudent solution is to do proper capacity planning – which is: 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 does not have the capacity to complete it, (no matter how hard you push them) sets the team and the company up for failure. It is physically impossible. Instead, plan to the capacity of their output in that given time. This starts with getting clear with what you want to accomplish by when. There is so much to consider, but the first question to ask is, “What do we need to accomplish?” Taking a hard look at the Strategic objectives of the organization or specific project is a first step. I always like to look at the Roadmap. What are we trying to accomplish this month, this quarter, this year? No matter what, resource planning (managing people capacity) should align critically with the strategic planning strategy (what we are trying to accomplish). It all goes back 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 continue to improve it over time? Naturally, as an Agilist, I’m going to say, “Yes, let’s do it this way”. Because if we can be more agile in our delivery approach, time is subjective. What we end up talking about 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 like quick results, right? Take option 1, then. Incremental value. It doesn’t matter how big or small your team-size is (except for productivity metrics and I’ll get to that later), we instead change the dialog to Value. If you haven’t introduced agile and lean processes to improve the delivery of your high value quality products to your customers, then, (cough), this whole subject is way too advanced for you. Go back to square one – adopt agile methodology to your organization. But what if, indeed, your agile health sucks? Maybe you think you’re ‘doing agile’ but what you’re really doing is saying your agile, and everything points to just slapping more people on the problem, instead of actually fixing the problem. Let’s see how using the value of time actually works within agile methodology: Timebox - Adopt an MVP development mindset.A minimum viable product (MVP)[1] is a Lean Startup concept around delivering a product or features of the product to users that can provide enough feedback and learning about the customers experience with it, but requires the least amount of effort to deliver it. I have always enjoyed this diagram (1) and use it for all my agile training and planning moments. Consider that you want to always deliver something useful. Not something that a user cannot use, and delivered in a short amount of time (eg at the end of a 2 week sprint). If you want to build a Porsche, with all the bells and whistles, it is going to take a long time. But maybe you can ride a skateboard first. Then iterate and build a scooter. After that, a small car. Then you can add the bells and whistles. You cannot, however, do anything with one wheel. Seeing what people actually do with your product is much more reliable than asking people to imagine what your Porsche will be like, by holding a useless wheel. [1]https://www.agilealliance.org/glossary/mvp/#q=~(infinite~false~filters~(tags~(~'mvp))~searchTerm~'~sort~false~sortDirection~'asc~page~1) 
Timebox the work. Agile is a project management methodology[1] that consists of small development cycles, aka ‘sprints’, to keep the focus on bringing continuous improvement in a product or service[2]. It’s funny – I have had so many people tell me that agile is not about deadlines. But indeed a Sprint IS ALL ABOUT a time-bound period, where the team finishes tasks within a pre-determined timeframe of usually 2 weeks. Therefore, plan the work to the capacity of the Sprint, to the capacity of the people in the team. Don’t over plan. In Agile SAFe (agile at scale), we also plan to the capacity of the quarter of 5 (or so) Sprints. Whatever the timebox, plan to that, based on the people you actually have. This is a loaded statement. It requires pretty robust Agile maturity in order to do this really well, including but not limited to the ability for a team to estimate/size well; the maturity of scrum and sprint process; the maturity of agile release processes, Dev Ops continuous integration and delivery maturity, and maturity of your agile planning processes and ceremonies.
It is important to note that MVPs do not mean to deliver minimal products quickly for no reason.[3] It means we are delivering to market, regularly, for a deliberate purpose: to gain user feedback in order to improve the product further (incremental improvement). And this means that each sprint we want to provide some user value, even if small in order to get the 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 improve the experience further. It requires conscious effort and discipline. When I was working for a Hollywood Startup run by a very famous musician, building AI integrated music apps and products, we didn’t launch anything of note in the 2 years I was there much to the chagrin of all of us, especially me. What’s the point of working on something you don’t know if customers will even like? At another company, I was able to get their product releases down to every month instead of every 8 months. That was a big improvement. We then accelerated to every 2 weeks. All of which required root canal therapy on their agility to get to this release nirvana. Suffice to say, if we get to an MVP Mindset, and we plan, execute and deliver in short increments, you will advance a long way towards working within the capacity of the current people. This is very healthy not just for business, but also for culture. Everyone gets excited when they finish something. It costs less to keep current people happy, and costs way more to hire and replace. [1] https://www.ntaskmanager.com/blog/how-to-use-agile/ [2] https://www.cio.com/article/3156998/agile-project-management-a-beginners-guide.html [3]http://www.startuplessonslearned.com/2009/08/minimum-viable-product-guide.html 
Ship FrequentlyOne of the 12 principles of agile is to ‘deliver working software frequently’.
This can be within a couple of weeks to a few months, but the recommendation is shorter rather than longer. One of the reasons for this is to ensure the key piece of agile which is to gain feedback early, in order to improve the product. Many long release timeframes can end up with dissatisfied customers and clients simply because the team, incubated without feedback, could easily go down the wrong rabbit hole. That’s a lot of waste right there, when you have to re-do features or directions simply for not gaining feedback early. So, the heart of Agility is incremental delivery, within short timeframes. This is eloquently provided in ‘Sprints’. At the end of each sprint (iteration/cycle), the team deliver something of value. Note the word ‘incremental’. This is a key word that is often misunderstood. Every time we want to deliver something to users, we want it to be incremental and rapid. Consider a new feature. Sometimes a whole new feature could take months to develop and release. But if we’re able to slice it down to several parts of the feature release, that can still provide value to the user, then we are able to test it with our customers early before we finalize the whole feature. This is the MVP: Minimal Viable Product. Or even more microscopic: Minable Viable Feature (MVF). Here’s a good example: Let’s imagine the whole feature (for a pretend travel site) is to be able to sign up to the site, search flights and book the flight of my choice to a destination, as well as get an email receipt. At first glance, this is quite an undertaking. Maybe even more than a month of work for one team. But to release incrementally, MVP style, one approach is to slice this down to shippable increments, meaning in the first increment, a mineable viable feature works on it’s 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 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 could get an email confirmation. And so forth. I’m over-simplifying this feature of course, but you get the gist. Break it down into bite-sized, incremental releases. The kicker is this: the releases come after each sprint. Ideally we Sprint and Ship. I practice and preach this all the time. The more we can get into a routine of releasing after every sprint, we not only have a predictable timeframe for releases that the team and stakeholders can rely on, but it also sets an excellent team discipline to ensure they only plan just enough in the sprint that the team, as a unified whole, can, together, design, develop and test. That means, we learn to slice features, and user stories, down to smaller chunks of work that allow the team to complete, all the while collaborating, communicating and working together more effectively. The cherry on top is that the team feel a sense of achievement by being able to deliver to and delight customers frequently. “Yes! We did it! We launched xyz!” We all like those feel-good moments, don’t we? 
Step 2: Optimize your agile predictability to scale
What is your organization’s agile health? Have you looked at any clear KPIs – key performance indicators - to qualify how well your teams are performing? Optimizing your current agile health for predictability is the next step before considering to scale people. This article is not here to expound on the notions of agile. That takes about a hundred books. What I will endeavor to share is some of the key aspects of agile adoption that is a fundamental precursor (or solve) to the next step of scaling: predictability.
Setting agile metrics At its core, Agile methodology offers a framework that allows teams to perform well, when adopted successfully. Agile was originally developed to streamline, improve and rapidly speed up the development process[1] through short, iterative, interactive time-boxed sessions that provide early feedback of the product. It is an art to be agile. Most organizations say they are agile by sprouting all the ceremonies, practices and structure, but usually there are inherent flaws in their formula. I can write a whole book about just that. Suffice 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 decrease risk to hit the strategic objectives. If done right. Agile development practices include but not limited to a common development practice (whether pair programming, Extreme XP, or other forms of speedy development); Scrum or Kanban team structure and project management; as well as how code reviews are performed; branching and merging strategies should be adopted, testing principles and how test cases are formed and followed; plus how to continuously integrate, and ultimately, how the team will deliver working product through frequent releases. All these engineering practices are critical for building and maintaining high-performing teams and should be upheld to enforce delivery performance and excellent customer value. Agile methodology also relies on a set of simple but 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 striving for high-performing agile teams. As a key milestone for organizational growth, I am a big believer in predictability. When Agile practices are clearly defined and standardized – such as predictable ceremonies of standup, sprint planning, sprint review and restrospective – as well as operating in a predictable MVP delivery cadence, it provides a foundation for organizational predictability. And when you have predictability, you can start to measure the health of your teams. You can measure your company’s success. Once agile teams are truly doing and being agile, and their agile health can be measured, you can then use these metrics to assess improved accountability, faster performance and greater collaboration. Then you can scale/expand to eternity. The more orchestrated and aligned together, the easier to add teams and people to the framework. (We’ll talk about the different frameworks later.) Getting the ceremonies and agile practices right, as highest priority, will ensure an easy transformation to a scaled approach. The intrinsic agile infrastructure has to be set up first before adding more people, and indeed, more process. One last word on this: doing agile is different to being agile. You can pretend to follow all the practices but still miss. Being agile is about an organizational mindset around transparency, responsibility, understanding that change is inevitable and embrace it, as well as more involvement from everyone.[2] There are really only 4 key values to agile[3] and yet so many organizations try to complicate it. 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 sets the org up for a true agile mindset. Autonomous, cross-functional team-structure For an agile team to truly be successful, it needs to be cross-functional. This means that everyone who is responsible for developing, testing, delivering and maintaining the product as well as those who receive the feedback from users, should be on the team and have a predictable cadence for ruthless prioritization. Here are the core contributors to an agile team
The most successful agile teams I’ve seen have been 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 outside dependency, even minor, will slow the team down. If you have an agile team all with backend API developers, and another agile team all with frontend developers, and they need each other to deliver the user story, then this creates cross-team dependency. This will slow the team down, waiting for the other team to deliver a piece of functionality to the other team. Similarly, if you do not have testers on the team, and you have to deliver code to another team to test, that will slow down the team. Keep quality testers and developers on the same team. (Actually, train everyone on the team to test!) When a team is self-organized and autonomously able to deliver product to market, it provides increased productivity, transparency and communication. The minute you have to depend on another team to develop and integrate, you are setting your team up for constant impediments, and this slows the pace of the team, as well as drops the 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. [1] https://www.cio.com/article/3156998/agile-project-management-a-beginners-guide.html [2] https://kanbanize.com/blog/doing-agile-vs-being-agile/ [3] https://www.scrumalliance.org/resources/agile-manifesto 
Sure and Steady
For an agile team to be successful, it needs to be steady and stable. This means that the scrum team members are dedicated to the same, one, team on an ongoing basis, developing, experimenting, sprinting and delivering together. Benefits of a steady team includes building positive culture, stronger communication and effective collaboration. Over time they become more predictable in what they can deliver by when, increasing their ‘velocity’. With a steady team, the backlog, then, may change, while the team does not. Tuckman’s ‘Stages of Team Development’ of teams are forming, storming, norming, and performing. According to Tuckman[1], every team needs to go through these stages to ultimately be successful. If team members are constantly changing, or even if one member leaves or one arrives, they start all over again. It takes time to create high performing teams. So, keeping all team members together over a long period of time, fosters predictability. And with predictability, we can assess the success of our teams. Team defines ‘Done’The team also comes up with their definition of ‘done’ as a collective. This is built into using acceptance criteria in 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.”[2] It defines how a particular feature or desire could be used from an end user's perspective and focuses on business value. The AC establishes the boundaries of the scope and guides development. Without AC, the scrum team often lack clarity, or interpret differently, what connotes acceptance for a story or task. In my world, I've seen multiple cat fights over what is acceptable to mark a task 'done' in a sprint, and this is exclusively around the confusion or non-clarity and lack of agreement of what "acceptance" means. Therefore, AC is critical for the success of the story to complete, 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.
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. [1] https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development [2] https://www.seguetech.com/what-characteristics-make-good-agile-acceptance-criteria/ 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[1]. 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 in to 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.
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. [1] https://ascendle.com/ideas/scaling-agile-theory-and-execution/ 
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.[1] 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. [1] https://digitalspirit.dbsystel.de/en/how-the-agile-release-train-is-moving-freight-transport-forward/ 
Teams at ScaleThere 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. [1] 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.[2] 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. Eg 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.[3] 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@ScaleThe 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’, [4] 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 (eg month to month). However you scale Agile teams to beyond a few, there key drivers for a scaling framework are
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 foundationYou 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-inIn 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 changeBuy-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:
[1] https://qualitance.com/blog/3-strong-reasons-why-use-agile/ [2] https://www.scaledagileframework.com/ [3] https://less.works/ [4]https://www.amazon.com/Scaling-Done-Right-Competition-Irrelevant/dp/B08YK8B9PL/ref=sr_1_4?dchild=1&keywords=scrum+at+scale&qid=1625070555&s=books&sr=1-4 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 continue to improve the collective teams’ ability to add more work. But do not add to the existing teams. Again, add more teams. Consider upping your software engineers, testers, designers. Consider LESS managers. With the framework defined, you actually need to keep only a lean management team. I cannot tell you how many times I have witnessed resource planning to be so top heavy with management. The fallacy is leadership misinterpret the need by thinking we need more managers to manage the work more effectively, but really what we need are more people to do the work and less managers, so that managers can get out of the way and allow teams to be more autonomous and self-organized. When adding people think wholeistically. If Engineering need more developers, you want to look at it from a Team makeup point of view. You will need a scrum master, a product owner and tech lead. You will need quality testers or automation engineers. Maybe a designer. Maybe other members. You also may need a scrum of scrum master/ agile release train program manager to oversee this tribe/program/pod/team of teams. And maybe an Area Product Owner, or SAFe Product Manager for the team of teams. What I’m saying is, you don’t just hire in a vacuum for one particular need. You hire teams. And once you bring a new team, you want to give it some time to be well-performing. It takes about 3 months for a team to get to some sense of velocity. 3 months! This is why just slapping on more people to solve quick problems and expect fast results, does not work! People are valuable. And should not be underestimated. But should be added with care, and into a disciplined agile system that can nurture their growth, build 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 form the 2001 agile manifesto[1]:
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 [1] https://www.scrumalliance.org/resources/agile-manifesto Recommended reading:
1 Comment
11/3/2022 09:02:11 pm
Rock should from court thank early require. Any around pattern sell. Leave a Reply. |
AuthorAgile Ninja, Gilli Aliotti, leads agile coaches, scrummasters, scrum product owners, tech disrupters and lean startup entrepreneurs to become “agile warriors” in their careers and lead their teams through rockstar agile transformation. All articles are © Copyright of the Author and this site www.theagilewarrior.com and cannot be reprinted or distributed without permission. If you would like to re-post these articles, please contact us. Or you can tap the social share buttons to share these blogs, with links intact, to your network. Categories
All
Archives
July 2021
|
RSS Feed
ROCK YOUR
AGILITY
Join the Community and Thought-Leadership Think Tanks
Copyright © 2016-2022