Are you in a role that’s responsible for leading or supporting your company's Agile transformation?
Are you looking for insight into the essential areas needed to better scale and align your organization’s Agile practices? If so, then this is the blog post for you!
Often the implementation of Agile ways of working is concentrated and measured on how well individual teams adopt them. In today’s fast-changing business environment, being Agile is not only important for teams but also for the entire business.
This is the first in a series of blog posts I’ve written where I’ll highlight the core Agile practices that are fundamental to achieving scalability, starting with the team layer.
The goal is to understand why each of the selected practices highlighted is so important and how they support and connect to the Agile practices in the layers above. It is this thread of connectedness that is essential for scaled Agility.
The “big three” Agile practices for teams
Teams need a cadence they are committed to
The iteration or sprint cadence your team establishes for itself is one of the first and potentially most important practices necessary for Agility.
The sprint cadence defines the pattern for how your team will work and structures the ceremonies necessary to plan, refine, and review those ways of working on an ongoing basis. Without a cadence, teams won’t be able to continually improve or understand what’s needed to do so.
The main ceremonies—backlog refinement, sprint planning, daily stand-ups, retrospectives, and sprint reviews not only guide your team’s way of working, but they also help to communicate critical information to product and portfolio management (information that is directly connected to higher-level objectives). I like to think of the sprint cadence as the smallest operating part in the larger, Agile machine.
Sprint cadence also provides the base increment for calculating your team’s efficiency in terms of velocity—a metric that is essential to understanding how changes impact your team’s throughput and establishing a predictable planning cycle.
Story points are essential
To avoid the “human hamster wheel” that results from overloading teams with work, you need a method to define effort. Story points do this, plain and simple.
Without story points being assigned to all work planned for a sprint, there is no way to determine if the sprint plan is realistic, nor is there a way to base planning decisions on past sprint achievements.
Story points are one of the three core team practices because they form the basis for how your team’s capacity is calculated. Without a numeric metric to assign each piece of work planned in a sprint, planning turns into guesswork. It might appear that this is their only purpose too, but that’s incorrect.
Story points are also crucial to communicating predictability. Having a known consistency allows for better product and solution forecasting—something that’s very important to portfolio leaders who seek to track progress on key initiatives and make determinations for other projects to plan in the coming quarters.
One counterargument that often comes up in the story point discussion is, ‘’Why not just estimate work in man hours?’’ This might seem straightforward enough and is still applying an estimate of sorts to work, but in reality, estimating in man hours alone won’t capture the full story of what’s being planned.
Think of it this way, if you estimate all work in man hours, no matter how many stories you plan for a sprint, the one thing that is certain is that the team will burn through all of the working hours of the sprint. Regardless of whether hourly estimates match up or not.
Using man hours alone removes factors like the complexity of tasks, resource requirements, system dependencies, and other details that contribute directly to the overall effort, leading to a lack of consistency in sprint completions and less predictability. So, while tempting to go down the route of man-hour estimates only, the hours of your developers should only be one of several factors used to define a numeric effort score.
Teams will need to practice estimation of effort, and they will get better at it, sprint by sprint, leading to improved planning and more consistent completion of work for each sprint, which is something of real value to the layers above.
Understanding how work capacity is allocated
When a piece of work is completed, what area of the business has it contributed value to? I don’t mean contribution to a single project or a product but to something larger. Something that perhaps spans multiple projects or products. Something that drives the business needs more broadly. Knowing the answer to this is a simple way to understand and define why capacity allocation is so important to scaling Agile practices.
Having a link that connects your team’s stories to critical business drivers is the ultimate goal, in a way. Establishing that connection helps convey valuable insight to the layers above the team and may contribute to a specific annual or strategic goal.
When teams understand the relevance of work as part of a specific business driver, it helps them understand more clearly why certain work is planned now or priorities shift. Studies have shown a significant increase in productivity when knowledge workers know their work matters to the company’s larger mission and strategic goals.
Teams that understand how to categorize work against a set of predefined drivers can prepare and plan a percentage of work types so that it’s included in each sprint or at least kept up over a series of sprints.
Some examples of business drivers might include:
- New product experimentation
- Platform engineering
- Mobility expansion of services
- Cloud migration efforts
- Technical debt reduction
Allocating a certain capacity of work to these drivers in any sprint will provide a quantifiable metric that communicates to the layers above what progress is being made toward larger, business-driven outcomes. It also conveys relevance for why work is being done.
Cadence, capacity allocation, and story points
Looking at these three practices, you can begin to see how each provides an essential piece of what is a larger Agile practice—the lowest layer of an approach to achieving business Agility.
Cadence provides the planning structure. Ceremonies are the means to isolate and focus on areas of improvement recognized by the team. Story points help calculate efficiency and equate it to an accurate capacity load on your teams, and planning against a known capacity, allows for more realistic expectations and more predictable outcomes generally.
Allocating a certain capacity of work planned in your sprints to specific business drivers delivers measurable outcomes against broader themes of critical value in the layers above. It also shares the purpose of work with each team.
So, go take a look at all your teams today, assess whether these three core practices are in place and if so, how well are they contributing to your desire to scale? If they aren’t in place or the benefits aren’t yet clear, you know where to focus your attention.
The next blog post in this series will cover the layer where work is organized, the program or team-of-teams layer, and connect these practices to team practices.
Published: Mar 26, 2024
