After a first article about Agile at Scale published in the Harvard Business Review in May 2018, Darrell K. Rigby issued a book in May 2020 on the same topic, “Doing Agile Right” with two other partners from Bain &Co, Sarah Elk and Steve Berez.
This book is a nice introduction to Agile at Scale and delivers a clear overview about its principles. It is definitively a must read to have the big picture on the subject. What are the topics covered in this book? How do they connect with the materials of this blog?
- What is at the core of Agile in Agile at Scale by Darrell K. Rigby?
- What is Agile at Scale by Darrell K. Rigby?
- How much of Agile to deploy in an Agile to be Enterprise ? And how to deploy Agile company wide as explained in this book?
- What are the changes coming with Agile at Scale by Darrell K. Rigby?
- What’s next? Learn more about Agile at Scale
- Find here the sources of this post on Agile at Scale by Darrell K. Rigby
What is at the core of Agile in Agile at Scale by Darrell K. Rigby?
The book starts with a reminder of what is the core of Agile: the Agile Team. Indeed, before thinking about spreading Agile in an organization, it is important to master it over some pilot teams.
Without surprise, we found here some of the key principles and characteristics of the Agile team, called in this blog Agile Squads.
Principles of Agile Team in this book
- First, the customer interaction is essential to get rich feedback and drive innovation.
- Second, the ceremonies, roles and artifacts (product and sprint backlogs) are a structuring frame that allows to keep activity under monitoring, reassuring management, so a move from command of control becomes possible. Indeed, empowerment and delegation is required in uncertain environment, so decision taking is pushed where the information and expertise is.
- At last, the authors remind that the purpose of a sprint is not to put more pressure on teams but to deliver faster value and get quicker feedback from customers. Team delivery rhythm should be sustainable to enforce quality and innovation.
Check my posts on the Agile and Scrum for more on the Agile foundations.
Characteristics of Agile Team for the authors
Darell K. Rigby and co-authors go more in detail with the characteristics of the Agile Team:
- Customer-centric on the customers that the team builds products and services for.
- Persistent and cross-functional so the team gains experience on the business context and gains trust from them. This accelerates value and innovation delivered to the business.
When the authors talk about cross functional, they mean that all IT activities are covered in the Agile Team: software development but also IT production deployment, operations and support, and even infrastructure maintenance.
The model described in this blog has all activities around an application delivered by a group of Agile Squads working on the same Value Chain, then supporting the related applications. As a matter of fact, one Agile Squad may work on several applications. But the IT infrastructure is managed as a shared service and supported by dedicated teams outside the Agile Squad. Yet, it is difficult to have this additional skill within an Agile Squad. In addition, as the infrastructure is managed as a service, all what the team members have to do is to deal with it through code and configuration. So not having the infrastructure staff in the team in not a limitation for speed, innovation and value to customer.
Review my post on Agile Squad for more. Beside that, read my posts about DevOps and Craftsmanship to understand how infrastructure can be managed as a service and how state of art coding practices are an accelerator to innovation.
What is Agile at Scale by Darrell K. Rigby?
Agile at Scale versus Agile Enterprise
Here, Darell K. Rigby and co-authors make the distinction between Agile at Scale that is in their book spreading Agile over a larger group of teams and the Agile Enterprise where transversal functions including for instance budgeting are transformed to work by an Agile way.
Note that, even if the authors mention main Agile and Agile frameworks, they remain framework agnostic and do not propose an overview of them.
In this blog, there is only one notion that is Agile at Scale where the transformation covers in addition to IT teams and business interfaces (e.g. Product Owners), all the supporting functions to IT. So budgeting and planning for instance are definitely in the scope and are required to get exponential benefits. If not, the benefits are just the sum of the benefits of each Agile Team transformed.
Check my posts on:
- Product Management Team to review how the organization switch from a project mode to a product mode with a dedicated capacity.
- Project Portfolio Management that turns to Product Portfolio Management.
Innovation versus operations
The authors also highlight the balance between innovation and operations:
- Agile supports innovation and makes sure that this innovation is not just delivered as features to business but also implies innovation in the underlying processes. Truly, there should be an integration between innovation and operations even if their organizations are separated.
- Operations, that run a routine way with reliability and efficiency, are adapted based on innovation coming from Agile. Target should be to reduce operations part for more innovation. Of course, to do so, quality of operations cannot be compromised.
To sum up, operations and innovation are complementary and should articulate frictionless. Authors propose some options to smooth join between these two parts of the company:
- Engage operating people in Agile Teams, adding some operators as full-time members to provide expertise.
- Launch Agile Teams with majority of operators to challenge current operating standards and to redesign business processes and related technology for a disruptive change.
Beyond this book
To go a little bit further from this book, we also can see innovation at two levels, Disruptive Innovation and Continuous Improvement. If Agile definitely brings disruptive innovation, CI can be directly integrated in the business part. Really, with routine usually comes the objective to reach the perfection through Continuous Improvement. And here, the cousin of Agile will help: Lean either Lean-6 Sigma or Lean Management. I am used to say that Agile and Lean share the same DNA. Agile is a just a form of Lean, pre-package for IT.
Challenge the perfection!
How much of Agile to deploy in an Agile to be Enterprise ? And how to deploy Agile company wide as explained in this book?
How much of Agile?
First Darell K. Rigby and co-authors stress the fact that there is an optimal level of Agile at Scale for each business and each activity. There is no one-size-fits-all and each company should find the proper level of Agile it should go for. There is no specific guidelines given on this topic except to experiment while transforming and adapt.
How to scale Agile?
Second, the writers focus on how to deploy Agile company wide.
At the beginning is identifying and estimating the potential benefits and costs of the Agile transformation. Definitively, this is a classic step of a transformation and it comes as an input to build a vision as described in my post about change management. In addition, this is to be refined while transforming. Still in my post about change management, it is supported in the steps around “marketing quick wins” and “accelerating the change” with adjustments of the change. All this, assisted by communication and change adoption steering.
Furthermore, the authors propose to leverage Agile for the Agile transformation itself. Why reinventing the wheel? Absolutely, Agile is a powerful tool when it comes to deal with uncertainty. And for sure an Agile transformation is full of unknown. This is also the adaptation I made on the classical change management process to iteratively test, learn, and adapt. In addition, this is the way I conduct transformations at Enterprise and Tribe level. At last, as adaption is possible only with the feedback of the transformation, identification and collection of metrics is key.
You can’t manage what you can’t measure.
To do so, the writers propose to use the framework of metrics from the Kellogg foundation to structure metrics over: inputs, activities, outputs, outcomes, and purposes. You can find here a more detailed document.
What are the changes coming with Agile at Scale by Darrell K. Rigby?
First, Darell K. Rigby and co-authors remind that at the beginning of a company there is:
- First, a purpose, a vision of what the company wants to achieve and values.
- Second, what the company is at the core, its mission.
The path to deliver the vision, taking into account the strengths of the company and the market environment, is structured by a Strategy. Indeed, it is an important reminder that the speed, value and innovation brought by Agile will go nowhere without a good direction established and communicated.
See my posts about competition and strategy including in the context of platform business to learn more about the topic.
Leadership also called traditionally management
It is not just the leaders who should change. But as their name stresses it, they should lead the change and be the change they want to happen. They should embrace Agile first to understand it but also to support it. Really, their mindset and how they illustrate with their behaviors should move from predicting and controlling to trusting and coaching.
Leaders for a successful Agile at Scale transformation should:
- Empower the different levels of the organization, so responsibility and decisions are at the level where information and expertise are.
- Let the customers tell what they need to the team instead of instructing the team what to do.
- Break the silos for teams to work on a greater good for the whole organization.
- Back actively the transformation taking decisions quickly, communicating, coaching and supporting learning.
Their change in leadership will eventually change the company culture and embed Agile in all its dimensions: routines, behaviors and mindset…
Empowerment will then allow them to refocus their mission on getting the big picture, defining the priorities, allocating means and removing road blockers from the teams.
Check here again my post on Change Management to review how the leaders of the company organize as a guiding coalition to support the transformation. Review also my post about Chapter to understand the new stance of management and about the switch to horizontal management to dig on the value of this change.
Planning, budgeting and reviewing
The myth of no planning in Agile
First, Darell K. Rigby and co-authors deal with the myth that there is no planning in Agile. This is a belief that I have often to deal with in organizations starting their Agile journey.
It is not because you have a roadmap that you cannot adjust it. But you should have the vision, the big picture where you are going. And this vision is useful to give purpose but also to provide consistency to all the small pieces built from sprint to sprint.
It is like the plan of a city. You need to known that an area is going to be offices, another residential and some commercial. But you do not need to have the detail on how the shops will be implemented in the commercial area…
Overview of Agile at Scale planning, budgeting and reviewing
For this topic also, the Agile principles are applied with frequent iterations to dynamically allocate means to initiatives and to maximize expected value. It is the same as done by the Product Owner at the level of a team but at a project portfolio level. Here the term used for project portfolio is Enterprise Backlog.
In this blog, we also use a different term to stress the move from project to product: Initiative Backlog. All start of course, with a strategy and a vision where the company or businesses want to go.
Then the authors review this theme over 3 topics, planning, budgeting, and reviewing.
Agile at Scale planning
Planning roots in bottom-up inputs, collects hypotheses of the most valuable opportunities and schedules when to test them. As usual in Agile, the work in progress and multitasking is limited. And planning is detailed only when needed. On this last point, it is the same approach as when refining the backlog for an Agile Team.
Agile at Scale budgeting
Budgeting strictly follows this iterative and adaptive approach to allocate means on the most promising opportunities. Space for unplanned initiatives is saved and budget and consequence means are adapted based on outcomes either value or learning.
The model described, funds persistent teams rather projects when opportunities last more than a year. If reallocating financial means is fast, building human capacity, Agile Teams, is not. There should be a balance between the flow of initiatives and long term needs of human capacity.
As customer needs and solutions evolve, persistent teams will pivot but still with value monitored. No additional approval to upper level is required when the direction change as far as value is there and outcomes demonstrate it. Indeed, funding is directly connected to outcomes, either financial or learning.
Agile at Scale reviewing
Reviewing is frequent and informal, and leverage simple metrics through all the organization and all the layers of hierarchy. Comparison between expected and actual for outputs and outcomes is to understand the reason of gaps and seek for improvements. This will adapt the approach and will change related plan and budget.
This shift reviewing focus to future and solution, instead of past and problem. It supports better satisfaction and engagement of the Agile Teams and business stakeholders involved.
The authors mention the persistence of the Agile Teams. To go further, as explain in this blog, alignment of organization and human means make planning and budgeting, project portfolio management, easier.
Capacity is stable but not fixed and moves with the trend. It evolves taking into account the real time and effort to skill people to do the work. Of course, transversal initiatives may remain. See my post on Agile at Scale Portfolio Management / Initiative Backlog to learn more about matching the capacity to initiatives and how to manage transversal opportunities.
For more on Agile metrics review my post on OKRs.
Organization and related operating model
Darell K. Rigby and co-authors explain that the main change with this topic is the alignment of all means at all levels of the company to the customer journey. This is what is explained in this blog with the Tribes aligned on business areas and Agile Squads aligned on Value Chain. Indeed, the Agile Squads have all needed skills to deliver the work autonomously and are moved close to the business they work for to foster innovation.
The authors also stress the importance of having a clear ownership with related responsibilities through all components of the organization.
At last, the writers point out that there is a need for more than a change of organization to break down silos and hierarchies. There should be specific change management so the way components operate, the operating model, evolves to reflect the actual new organization.
All those expected changes are an input for talent management transformation activities.
Talent management
Darell K. Rigby and co-authors introduce the talent engine that stands both for:
- What talents are required either hardskill and softskills to support business development?
- The strategy and actions to get, develop, motivate and retain these talents.
This talent engine monitors, by the flow, current talents and needs, to match them. It is a critical mechanism in the Agile at Scale transformation that will last after the main phase of this journey as it is essential to business development. It should be considered at early stages of the transformation due to the amount of work and the time to implement and get the actual talent hired or reskilled.
To go further this book, upskilling people requires more than training. It is actually a mix of building an appealing vision as described in the change management post of this blog, training and coaching. All this, to build the desire to change and a continuity between receiving training, coaching and then performing in the new role.
Processes, technologies and data
Processes
Darell K. Rigby and co-authors remind that innovation is more than creating new products and services for customers. Innovation should also pervade the business processes that produce those products and services.
Operations are stable and should be reliable and efficient. But they are not fixed. Standards are are met but adapted regularly as innovation reaches the business operations. Appropriate change management is delivered to make sure new standards are accepted, understood and properly applied.
Technologies
Here, the authors highlight the need to have a modular, flexible, and service-oriented architecture with a Continuous Delivery empowered by DevOps and related tooling. This helps the IT to become more flexible and break down functional silos within and outside IT.
See my other posts, for more on DevOps: in this blog the topic is covered with Craftsmanship, for the state of art of coding, and DevOps, for the collaboration between Dev and IT production.
Data
At last, the authors point out the importance of Data created and captured by the company and that allows to improve the quality, speed, and cost of making decisions. Obviously, due architecture to manage Data should be in place. To learn more about Data and how critical it is in our digital world check my post on the Data Revolution in the Digital series.
What’s next? Learn more about Agile at Scale
Check my other posts about Agile at Scale:
- Review my posts on Agile at Scale foundations:
- What are
- What are the team topologies?
- How to synchronize Agile Squads in Agile at Scale when there are dependencies?
- Check another of my posts introducing Agile at Scale that leverages the book “Doing Agile Right”.
- Review my post on the Agile best practices from the GAO the Government Accountability Office from the USA.
- Read my posts on advanced topics around Agile at Scale:
- What are Leagues in Agile at Scale?
- How to design Agile Squads so they are aligned on the Value Chains.
- Why going for horizontal management? What does it mean and what is the value?
- How roles are reallocated with Agile at Scale?
- Check my posts on project management in Agile at Scale
- What is the impact of Agile on Project Management?
- How does Project Portfolio Management change with Agile at Scale?
- Then, how does Cost of Delay Divided by Duration (CD3) contribute to Agile at Scale?
- How does Beyond Budgeting support Agile at Scale?
- Can an Agile Project be fixed price?
- How to manage Release Management in Agile?
- Review my posts on how to forge a good strategy:
- What are competition and competitive advantage?
- What is a good strategy?
Find here the sources of this post on Agile at Scale by Darrell K. Rigby
- The article published in the Harvard Business Review.
- The book Doing Agile Right from Darrell K. Rigby, Sarah Elk and Steve Berez.
Other posts from the authors and other partners from Bain &Co: