Part 1 - 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 - a 3 part blog.
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
Agile Alliance. Minimum Viable Product (MVP) Glossary. Retrieved from https://www.agilealliance.org/glossary/mvp/
Ntask Manager. How to use Agile: A Step-by-Step Guide. Retrieved from https://www.ntaskmanager.com/blog/how-to-use-agile/
CIO.com. (2017, January 6). Agile project management: A beginner's guide. https://www.cio.com/article/3156998/agile-project-management-a-beginners-guide.html