Part 2 - 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 Part 2 of a very long read that I decided to split into 3 blog posts :) where I 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.
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:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
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
Doing Agile vs. Being Agile: What's the Difference?. https://kanbanize.com/blog/doing-agile-vs-being-agile/
Tuckman, B. (1965). Developmental sequence in small groups. Psychological Bulletin, 63(6), 384-399.