What is the Lean-Agile Roadmap?
Why a Roadmap Is Needed
The Principles of Lean Software Development
Knowing the Territory
Our Roadmap's Destination
Symptoms of Being Off the Road
How to Get Started
Continuing Your Journey
The Net Objectives Lean-Agile Roadmap is a proven method to achieve agility at Scale. We use Lean-management and Lean-flow to a business driven approach for stakeholders with a combination of Scrum and Kanban at the team. Net Objectives has the longest track record of success of any consulting company in the world. Our Lean-Agile Roadmap is what we've used to help our clients achieve dramatic success in Agile methods across the enterprise. The Lean-Agile Roadmap can provide guidance to avoid the stagnation after initial team success that so many companies hit. While this page is where to start and get an overview of the roadmap, detailed information on different parts of the roadmap is available on our Enterprise Agility Roadmap Essentials.
While there is no one-size fits all, there is a set of basic practices that virtually all companies must do to maximize their effectiveness. But knowing what these are is only half the battle - getting there is the other. Merely saying "Use this structure," or "Do these practices," won't work for several reasons. First, too much change is difficult for most people. Non-managers know all too well how to outlast management initiatives. Second, while companies need to achieve certain results, the way to achieve them will be different for different companies. Applying someone else's best solution to your company may work, but will certainly involve more pain and cost than is necessary and will certainly not be the most effective way of doing things. Finally, and perhaps most importantly, this change is occurring while the organization needs to meet current commitments. Change must be managed so that improvements are certain and continuous.
These issues require a roadmap, so to speak, of going from where one is to where one wants to be. The roadmap will layout the changes necessary for the organization and the order in which to achieve them. This order is established by a combination of several factors:
Who is sponsoring the transition must also be considered. When anyone short of the CEO is the sponsor, creating visibility of what is needed to those above the sponsor is essential.
This page starts with the main principles of Lean Software Development. Understanding these is essential to create the context for the practices described. People often ignore the importance of mindset in implementing practices. We call our approach “Lean-Agile” for a particular reason. ‘Lean’ provides the context, the big picture, the theory, the management style, the science of the approach. ‘Agile’ means the methods (Scrum, Kanban, XP) the teams, within this context, use. This top-down context (Lean) bottom-up implementation (Agile) is essential. An only top down approach creates a command-and-control mindset that fosters micro-management. An only bottom-up approach leads us to the lack of cross-team success we see so rampant in the Agile world today.
After understanding these principles, I’ll describe the high level actions that must be recognized and implemented for Agile at scale to be effective. Later I'll be adding the practices that enable all of this.
The key insight is that there are methods required for effective software development. The trick is getting there. That requires a bigger view and a roadmap.
Optimize the whole means
Taking a systemic view means that one must attend look to the system within which people operate to understand why people are achieving the results they are. Changing the system will help improve their results. Effective results require good people and good systems.
Systems thinking implies taking an holistic view since systems are more than the sum of their parts. This is one of the big differentiators of Lean and Agile. One must understand that the development team is only a part of the process. Many of their challenges are due to upstream problems. If we can see the whole we can more easily change behavior of those upstream of the development team.
Eliminate waste by removing delays, only working on things of value that you know how to achieve and only starting work you know you can complete. We must remove delays in our workflow because these literally create additional work to be done – redoing requirements, finding errors (while the fixing cost often stays the same, but finding bugs found late increases dramatically), integration errors (caused by the delays from when teams get out of synch until they are discovered in the integration process.
Removing delays requires not working beyond the capacity of your teams as this injects delays into the workflow because people have to switch between projects and are often waiting for other people working on other projects. People often point to the cost of task-switching here, which, while considerable, pales in comparison to the additional work created by the delays themselves.
Build quality in means to avoid errors, not test them out. Shortening feedback loops is a big help here. In particular, the adoption of acceptance test-driven development is a method that virtually every team we’ve run across in the last dozen years would benefit from.
Deliver fast is essentially the same as time to market. Not a new concept. But Lean adds the insight that if we focus on shortening the time of delivery by removing delays and focusing on quality, our productivity goes up and costs come down. Quick delivery also allows for quick feedback and can help avoid building features that aren’t needed.
Defer commitment means to make decisions when you have the right information yet always attend to the cost/risk of making decisions too early or too late. Too many decisions are made too early. Deferring commitment requires taking steps so that delaying the commitment does not incur more risk while achieving better decisions when more information is available later.
Create knowledge means to create, capture, update, and put to use the knowledge learned from product value. Measure cycle time, work-in-progress, and which work-items have value.
Empower people to make decisions which they are best able to make. Teams must be given clear boundaries within which to work, however. It also means to recognize the psychology of people. People are tribal, have a psychology that is sensitive (and averse) to significant change. People also often identify with their work, so changing roles can be very difficult for them emotionally.
Focus on flow of value. We accomplish this by managing our queues so work flows from concept to consumption smoothly. Managing work-in-progress (WIP) is an effective way of doing this. In particular, we must pay attention to delays, which literally increases the amount of work to be done.
Continually improve with a scientific method. While software development appears complex, that is often because many of us have taken a simplistic approach.
The Lean-Agile Roadmap is designed to help you achieve one of two related goals - implementing the Scaled Agile Framework or the Lean-Agile Framework. Both can be used to effectively manifest agility at the enterprise level. Which you use depends on many factors including:
We, unfortunately, see many companies attempting to do only one or two of these. Ultimately, all 9 must be worked on to get true enterprise agility. Symptoms of these not being done include:
Not focusing on value and/or lack of product portfolio management. Too many, too large, projects are in play. The development team is overwhelmed with work. This is often attributed to the team’s ineffectiveness, but is mostly due to the team being overwhelmed by the unregulated onslaught of work to be done.
No holistic, architectural, view of what is being worked results in one application adversely affecting others. When integration time comes, problems that were unexpected pop up, often taking almost as much time to fix as it took to write the function that is being integrated in the first place.
A significant amount of software has not been tested by the time the end of the sprint arrives. Incremental construction of software means that small pieces of functionality are built at one time. This allows for full testing to take place within the sprint.
Management insists on injecting new requirements into the teams' sprints. These interruptions cause significant extra work and derail the sprints. This damage can be avoided if management understands why these are harmful and two the team understands how to do proper sprint-backlog management so that some changes to the backlog do not cause a problem.
Thrashing occurs when different teams try to integrate their work. Having teams work independently and then try to integrate their work is a method that has more than demonstrated its ineffectiveness. A much better approach is to have teams share backlogs so that they work on related items at the same time.
Test being well behind coding and/or developers building the wrong thing. Both of these are more common than not. A way to solve both of them is to do acceptance test-driven development with the QA folks creating test specifications with developers and customers (or their representatives).
Technical debt being high, difficulty maintaining automated test suites and/or difficulty adding in new functionality to existing code. In our focus on agile process, we’ve not attended enough to the way we write our code. Agile development does not require a different programming style, but it is more sensitive to poor coding methods.
Unfortunately, companies often take detours without realizing they are violating rules of the road. Some of these include;
Taking a team approach to guide an enterprise transition. One must often start with a pilot. It therefore seems reasonable to take the approach that one should spin up teams and then try to get them to work together. However, this is not unlike taking the first road that heads in the right direction. We may discover later that it is not the best road or even that it dead-ends. We do need to take a pilot, but we need to do this within the context of our destination (see How Successful Pilots Often Actually Hurt an Organization).
Attempting to coordinate the workflow across teams with Scrum-of-Scrums (SoS). While Scrum-of-Scrums is fine for providing consolidated information across teams, this model has a very poor track record for achieving proper coordination of teams working together when part of the job is figuring out what work must be done. Unfortunately, the commitment to a bottom-up, team driven approach often makes it difficult to see the proper road. See Alternatives to Scrum of Scrums.
Overly focusing on the team and delegating management's role to one of just removing the teams' impediments. While management should remove impediments to the team, they have a much larger role. This includes creating and providing the overall context within which teams must work. Delegating them to a subservient role or insulting them by calling them chickens is an impediment to enterprise agility in and of itself.
Attempting to use Scrum-of-Scrums. Scrum-of-Scrums is still a popular approach even though it has a horrendous track record of ineffectiveness. See Alternatives to Scrum-of-Scrums.
Webinar: Beginning an Agile Transition (registration required).
Blog: Why You Need a Hybrid Method (understand what team method to use before you start).
Before starting a pilot, understand the risks of hand-picking folks for the project: Successful Pilots Can Hurt An Agile Organization.
If you have a significant number of these symptoms or detours and want to learn how to improve your software development organization, please contact Mike Shalloway at firstname.lastname@example.org
Much of this is covered in our past Lean-Agile at Scale and the Team: The Value Stream series (recordings available) and our ongoing Business and Agile webinar series. Our Enterprise Agility Roadmap Essentials site also covers the insights and skills needed to implement the roadmap.
We will also be covering much of this at our 3rd Annual Lean-Agile Conference in August in Seattle. And, of course, search me out at Agile 2013.
For more detail on these methods, look for our new book detailing this called Lean Software Development Applied: Making Lean-Agile Work at the Enterprise by mid-September. A first cut a the roadmap was a partial writing of Improving Collaboration and Planning With Lean Product Development: Patterns of Success and Challenge. Since then our understanding of Lean-Agile at the enterprise level has expanded considerably, allowing us to create a more complete explanation of the methods.