The right management approach will always differ between companies. lean has recently been breaking down barriers in its application to a range of industries stemming from its strong manufacturing background. But how does it compete against similar, yet slightly different management practices such as agile? and more so, can the two happily co-exist?
agile coach Karl Scotland, explains how cloud-based solutions provider, Rally, used both lean and agile practices together to best meet its customer’s needs.
Agile is best described by the Agile Manifesto, a statement of values and principles created in 2001 by a group of individuals who had all broken from traditional ways of delivering soft ware projects. They spent a weekend together exploring similarities in the new ways in which they were working and came out with the following value statement:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working soft ware over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
While the agile movement grew out of the software development community, its focus on empowering the people doing the work, working directly with customers, delivering product early and continually improving makes it extremely compatible with the lean mindset and with wider applicability than just software. What we have learned at Rally is that agile execution combined with lean strategy creates an organisational capability to continually adapt to meeting customer’s needs.
In particular, the common focus of both agile and lean on the customer is one of the aspects that ties agile and lean together. At Rally we believe that collaborating with our customers at all levels of the business is necessary for us, and them, to be successful.
When Rally first began developing its ALM product, the most popular and well-known agile approach was Scrum. Partly inspired by Nonaka’s HBR article The New New Product Development Game, Ken Schwaber and Jeff Sutherland created a process where a team worked together to progress a software project in the same way a rugby team passes the ball back and forth to move up the field together. As shown in Figure 1, Scrum begins with a product backlog containing functionality to be developed. The Scrum team plans a small amount of the highest priority work, just enough to be able to complete within a timeboxed Sprint, to create a Sprint backlog. They then work collaboratively to “burndown” that work, completing it as a product increment that can be demoed, reviewed and potentially released. At the end of the Sprint, the team also holds a retrospective meeting to reflect on the process and what improvements can be made.
In lean terms, Scrum can be viewed as a way of reducing batch size and shortening lead time. The Sprint, which typically runs two weeks, forces a limit on the amount of work that can be started. This in itself encourages work to be broken down into small valuable increments that can be completed in the timebox. In software development, and knowledge work in general, the unit of inventory can be thought of as the unproven hypothesis, so having working software every Sprint leads to reduced work in process by continually validating ideas about how the software will meet the customer’s needs. Further, the fast feedback can be used to continuously adapt and improve both the product and the process.
At Rally we have adapted and evolved the development process over the years, exploring alternative value streams, cadences and synchronisation points. One key aspect is now a weekly release cadence, where as a cloud-based product, we are able to make updates to the product every week. Some updates, such as minor enhancements or fixes, become available to everyone straight away. Other updates are larger functional changes or significant new features which we are able to make available to only selected customers. Further updates are changes which are not yet ready for release, but which we want to deploy early to manage risk and reduce work in process.
By implementing an agile approach to development, we are able to give our customers rapid and early access to new functionality. Techniques such as feature toggles, which configure how code is made available to users, allow us the flexibility to be able to manage what we release, how often, and to whom. Often this new functionality is available in both existing and new forms, through a staged rollout. Thus selected, strategic customer partners can opt in to new features, providing us feedback through both subjective survey results, and built in objective diagnostics. This all combines to start giving us an understanding of whether we have built the right thing for our customers.
Disciplined exploration and empirical learning
As well as striving to deliver working software to our customers as early as possible to get feedback and validation, we also need to understand if it is worth any significant investment in the first place. To help us with this, we have adopted the McKinsey Three Horizons Model, as described by Geoffrey Moore in his book Escape Velocity.
From this perspective, most iterative and incremental development using agile techniques is Horizon 1 work. This can be seen as optimisation of our current business through interaction with our customers. However, our portfolio of work also needs to include offerings which will meet future customer needs in Horizon 3. For this we have taken ideas from the lean startup movement in order to learn what those future needs might be. This can be seen as exploration of our future business through experimentation with our customers. The opportunities that we choose to pursue are moved into Horizon 2 where we enable the business in readiness for them becoming Horizon 1 revenue generators.
The exploration of an idea starts by forming a dedicated team with a vision and funding in what we call an innovation sandbox. That team identifies a number of plausible offers, with assumptions behind them that need to be tested. Discovery work follows to refine a set of possible offers by understanding the problem space more and identifying solutions with business models. Those offers are further refined into probable offers by validating that we know we can go to market and sell them. This is the point at which we transition those offers through Horizon 2 until they are proven and operating as part of the core business in Horizon 1.
All the refinement is done through empirical learning experiments that frame the assumptions, build something to test them, measure the results and learn from the outcomes. Each experiment is run by collaborating with customers in order to get knowledge about what they value. As a result, the offers that transition through the portfolio into Horizon 1 are those that are pulled by the customers as a result of real demand.
Continual learning and adaptation
Working out what will meet our customers’ needs, and iterating to ensure that we do, is still not enough.
The third piece of the puzzle is how to create a strategy and direction which the whole company understands and follows, in order to maintain a coherent customer understanding. To do this we have a quarterly organisational planning cadence with which we collectively define and review our goals and objectives.
The cycle starts at annual planning where we reset our direction by defining True North and Mother strategies. Inspired by the ideas in Pascal Dennis’ book Getting the Right Things Done, True North is the single goal which sets direction and guides all decision making. Mother Strategies are the next level of focus areas that will help us arrive at the True North. We have learned to only have 2-3 Mother Strategies, otherwise, we lose focus too easily.
The True North and Mother Strategies guide the day to day departmental work that is done, as well as cross-departmental initiatives, which are known as Rocks. Rocks are inspired by techniques described in Verne Harnish’s book Mastering the Rockefeller Habits. The metaphor is based on the basic idea that if you have a bucket, you should fill it first with a few big rocks. These are the big things you want to accomplish. If there is more space, you can then put pebbles in – medium-sized projects. With any remaining space you can put sand in – the tactical things. Finally, you can still add water – any ad-hoc things that arise. Now if you fail to put the big rocks in first, you can inevitably fill your bucket with just sand and water.
True North, Mother Strategies and Rocks nicely map into Simon Sinek’s Golden Circle model, which he describes in the book Start with Why. In short, Sinek says that “People don’t buy WHAT you do, they buy WHY you do it” and he proposed the Golden Circle as a natural law occurring in many forms, in the same way as the Golden Ratio. Thus, he suggests that we should start with WHY, before determining HOW, and finally WHAT, rather than starting with WHAT.
Every quarter following annual planning, we review our progress on the mother strategies towards the True North. This is known as quarterly steering. As well as readouts of mother strategy status, we ask each department and their teams to work on strategy A3s, which roll-up and are also brought into quarterly steering. These strategy A3s are the means by which we can enable everyone having some input, when only a small subset of people can attend in person. The similarities and differences of the various perspectives and experiences provides a context in which we can reset or refocus our efforts by changing plans or creating new Rocks.
What has this got to do with understanding our customers? We have learned that by inviting some of our strategic customers into annual planning and quarterly steering, not just to observe but also to help contribute to our work, we can gain from the unique insights they bring. Our customers are not just customers, they are our partners in a mutual quest to learn how to achieve a factor of four increase in productivity and effectiveness.
At Rally, we want to understand our customers in order to help our customers be successful. If they are successful then we are confident that we will be successful. We believe that frequent and regular collaboration and interaction with customers is key to achieving this, and I have described some of the primary techniques which we are currently using to understand our customers. However, while we are constantly striving to understand our customers better, we will always be able to learn new and improved approaches and we will always need to adapt. Our own organisation is changing, our customer’s needs are changing, the market is changing, and the competitive landscape is changing. Thus, we will continue to evolve as we seek to further improve the ways that we work.
We have learned a lot already over the years, starting with agile and bringing in lean, and more recently exploring areas such as complexity and design thinking. We also believe that just understanding customers is not enough. We also need to understand more about the category of business we are in in order to learn more about how we can continually improve. One way we do this is to go and spend time with other organisations who are facing similar challenges or using innovative approaches. Similarly, by supporting industry bodies with similar perspectives and goals, such as the Lean Systems Society, we an keep up to date with the latest thinking and help catalyze new breakthroughs. As Ryan Martens likes to say “If we want to be the best surfer, we need to go to where the best people are surfing.”