Reality checkpoint: Bain & Company, "Doing Agile Right"
Agile has become such a buzzword it’s almost lost its meaning. So we thought it a good time to review. Overly cumbersome and bureaucratic processes and data silos create sluggish business models that are unable to react quickly to changes in plan and slow, rather than foster, innovation. But agile isn’t a destination. It’s a means to becoming an effective and prosperous organisation. As we learned long ago, Jack be nimble, Jack be quick, Jack jump over the candlestick. Organisations need to learn to be like Jack, learning to jump before disruptions impact their business.
Agile is being hailed as the magical antidote to organisational woes. But although it does have the power to transform how you work, it must be implemented in the right way, in the right areas to get you there.
Bain & Company thought leader and HBR author Darrell Rigby and colleagues Sarah Elk and Steve Berez check us on what agile really means, clearing up the myths and misconceptions surrounding all the buzz. Agile teams can, in fact, fuel innovation and make jobs more rewarding, but only if done right. It is not, however, a magic pill and can’t transform your company with a single swallow. Nor should it be used in all types of work or in every function.
As is with most things in life, the key is in finding the right balance, identifying where there is a need for tight control and strict governance for optimisation. As says, “Agile, done well, frees and facilitates vigorous innovation without sacrificing the efficiency and reliability essential to traditional operations.”
- How Agile Really Works
- Agile Planning, Budgeting and Reviewing
- Agile Organization, Structures and People Management
- Agile Processes and Technology
- Scaling Agile
- Agile Leadership
- Agile in Crises
- Doing Agile Wrong
- The (Un)balanced Company
Author Darrell Rigby responds to a question on how organisations can work together effectively and whether common goals should be established. “In my experience, Agile teams actually do better when they have separate rather than shared goals. The goals should be aligned so that teams are not wasting resources or working at cross-purposes, but aligned goals are different from shared goals. Take Saab Aeronautics, which develops the most cost-effective fighter jet in the world (the Gripen) using about 100 Agile teams. The teams are aligned on the goals for the overall jet, but teams working on propulsion have different goals from those developing brakes, for example.
“We often create what we call taxonomies of teams to show how Agile teams fit together and to make those relationships transparent to the entire organisation. We design the taxonomy to minimise interdependence while making sure that each module quickly and easily plugs into the others. This gives teams autonomy to act quickly without wasting time and energy on constant coordination. We think of it as creating a microservices architecture for technology, deploying loosely coupled applications that are self-contained but with clear interfaces. Amazon, as you probably know, uses microservices. Those microservices are mapped to autonomous teams that are generally capped at 10 members. We, too, consciously design business architectures and taxonomies so that each service ties closely to a development team.”