It is easy for a team to transition to Lean-Agile software development: Pick a good pilot project, get some training, re-arrange the workspace, learn the process, maybe use a coach. It has been done thousands of times. It is easy but all too often, there is no benefit for the organization. The goal is not making teams agile but making the business agile. This is a bit harder. Build your transition plan around the business and everyone—customers, business, and teams—will succeed.
A successful transition plan focuses on the complete set of work that is required to turn an idea into a product that customers can use. It will minimize the time and effort required. This requires looking at opportunities in business, management, team agility, and technical practices that will have the greatest impact on removing impediments and improving the flow of work.
Where to Start? Where Do You Want to Go?
The starting point for any journey should be to know where you are going. As obvious as it sounds, many organizations we see are not clear about this. They know they want to become more “agile” and much of the literature on Agile focuses on development teams. It seems natural to start introducing Agile in development teams. But making teams more agile is not the correct destination: it is a way station on the true journey of making the business more agile. Business agility focuses on enabling a business to respond quickly to competitors, to internal insights, to changes in industry or technology, and so on. All of your efforts should lead to becoming more and more agile as a total organization.
With business agility as the goal, it is easy to measure progress. One good measure is the elapsed time from when the idea is first developed until it is implemented, delivered, and customers can begin to use it. This is called the “cycle time.” The shorter the cycle time, the better because short cycle times let the business penetrate the market faster and respond to competitive pressures more effectively. The value of this metric is that it focuses on the entire “value stream” for the product. A value stream is the whole set of work that is done to create a product, beginning to end. Ideas arise from interactions with customers who could be external or, in the case of IT, internal to the organization. Business stakeholders and product managers create a list of product enhancements to be built by the development organization and back to the customers (either external or internal for IT organizations).
Product development is just one part of the value stream. If you have good product development but some other step still takes too long or is blocked, then cycle time may be unaffected. Reducing cycle time requires optimizing the whole value stream which is a key focus of Lean. Lean suggests that removing impediments to work (delays which cause waste) improves speed to market while raising quality and lowering cost.
The Major Impediments to Agility
At Net Objectives, we have helped dozens of companies improve their software development capabilities. Most of these have involved development organizations with 50-300 people and the largest had over 4000. In their transition to Agile, all of these organizations have faced four general kinds of impediments.
The business side does not properly select, size or prioritize their product enhancements: Yearly planning forces stakeholders to ask for too many product enhancements and these tend to be too large. Faced with long delivery cycles, they pile on requirements just to be sure they get what they anticipate they will need. It results in working on too many projects at one time. It virtually ensures that the features have not been properly prioritized relative to each other. This means that some of the features the team is working on are not the most valuable to the business yet, because they were already started, they have to be finished before the team can turn to the next, more valuable feature.
Improper allocation of resources: To manage this crushing workload, teams are often isolated into “silos.” Unfortunately, this dilutes the efficiency of the organization even more. Developers end up waiting for others to start work or to share information. In an attempt to remain productive, they start more projects. But this just adds to their overwhelm, reducing efficiency and causing more delay.
Non-existent teams: Team agility holds the promise of shorter development times: take a statement of need and build a system to meet it and then deliver the software quickly. Unfortunately, true teams often don’t exist and are difficult to form. Just creating them without solving the cause of too many projects may result in a pilot team doing well with the rest of the organization being more overwhelmed than before.
Poor technical practices: Too often, code becomes complex and brittle and hard to maintain over time. With discipline, it doesn’t have to. The proper use of acceptance test-driven development (ATDD), (unit) test-driven development (TDD), design patterns, and refactoring can keep code robust over time. While these techniques have been around for a long time, they are still not in widespread use. And that means there is a lot of poor code.
Start Where the Problem Is
If you want to make a car go faster, where would you start? Maybe you would put in a bigger engine. But what if the problem is in the transmission? Or the parking brake is locked? Or your tires are completely worn through? Of course, you should start where the problem is. The transition to Lean-Agile is no different. Staring with development teams is like starting with the bigger engine—if impediments lie elsewhere, then even if the individual team gets better, overall agility might be less! Even worse, if an Agile pilot project ends up causing headaches for the organization, people will turn against it. Who wants that? And it becomes very hard to try again. Unfortunately, we have seen this many times. It is much better to start where the problems are. Table 1 offers ideas to help you identify problem areas to focus on.
Table 1. Identifying problem areas
Problem area | If any of these are false… | Then focus on this challenge area… |
Business side | The product management organization maintains a list of prioritized product enhancements. Product enhancement requests are broken into the smallest pieces that can be released. The development organization is never overwhelmed by enhancement requests. Enhancement requests are prioritized individually; they are not released in one package. | Product portfolio management. Create a prioritized list of smaller enhancements, each of which can be released when completed. Product enhancement packaging. Keep the number of product enhancements being worked on small enough to not overwhelm your teams. Cycle time. Focus on delivering value on a regular basis with short cycle times so that the business can reevaluate its plans. Focus on the length of your projects rather than interval between releases of different projects. |
Management side | Effective teams work well together. Except for people with truly specialized skills, everyone in the development organization works on one team. The organization is free of “silos” that separate resources from each other. Management clearly describes the order in which to build and deliver product enhancements incrementally. Teams can get feedback from the business and customers quickly, when they need it. | Value. Management must create an environment that supports the creation of value quickly. Impediments. Many impediments to teams are due to forces outside the team’s span of influence. Management must act intentionally to remove these impediments on behalf of the team. |
Team agility | Teams are able to deliver software incrementally. Teams build only what they are requested to build without adding new features in anticipation of the future. Code is tested virtually at the same moment that the code is built. Teams write acceptance tests before writing any code. | Flow. Have teams learn an agile process that is based on flow (that is, the elimination of delays). It could be based on iterations or on kanban. Cadence. Create a cadence of work that delivers product to customers and gets feedback from them at regular intervals. Work-in-Process. Ensure that the team keeps the amount of Work-in-Process (WIP) as small as possible. Test first. Ensure that the teams write acceptance tests for a story before writing any code for that story. |
Technical skills | Development teams spend most of their time writing code and working with customers to write requirements. Teams easily understand how to introduce a feature into existing code. Testing and debugging takes place throughout the iteration. Testing and debugging is not a major focus at the end of a development cycle. There are relatively few errors detected during integration testing. | TDD. Teach teams how to do Test-Driven Development (TDD). Continuous build. Have teams use continuous build and integration. Design patterns. Teach teams the proper use of design patterns. |
Start Where You Can
The good news is that the transition does not require great organizational changes before seeing improvement. You can start where you are. Here are two effective and relatively painless approaches that we have used.
- Limit work-in-process. Limiting the amount of work-in-process (WIP) in those places where people are clearly working on too many things. This naturally frees up the parts of the value stream that get clogged up and overwhelmed with work and, therefore, create delays. It will have a ripple effect to unblock the flow of development. It will not seem natural at first but this does work.
- Make product managers your allies. If your company works on many large projects at the same time, you can enroll product managers into modifying the way they manage the portfolio of products. Not only will this focus the organization on building the right products, it will lower the amount of work that is almost certainly overwhelming development teams.
You have many more options available to you today than we had in the past for deciding where to start the transition to Lean-Agile. Increasingly, there are business leaders and management who recognize the need to become an agile organization. They may have been trained in Lean thinking. They have been exposed to the Toyota Production System and the Toyota Product Development System. They are more likely to see the need to develop strategic plans for the transition to Lean-Agile software product development. In our experience, involving leadership to create a top-down vision with a bottom-up implementation is always better. Developing this top-down/bottom-up approach requires careful, strategic thought. Consider using a coach who is experienced in working with senior leadership. Such a coach can bring to bear the experience of others to create a strategic plan that is likely to succeed and will have the proper business justification.
Summary
In your transition to Lean-Agile software development, it is critical to keep focused on the goal: Business agility. Creating more agile teams is good but only as it helps the entire value stream deliver product to customers more quickly and sustainably. Work on those changes that will produce the greatest results overall. This involves looking at all four of these critical areas:
- Business
- Management
- Team agility
- Technical skills
In an interview with Agile Collab, Ken Schwaber, co-founder of Scrum, said, “I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.” Since Scrum implementations typically start with team agility—just one of the four critical areas – a one in four rate of success is not surprising. It often is a question of doing the wrong thing—not doing the right thing wrong. Keep the larger picture in mind and you will naturally enjoy greater success.
Note: This article is based on the Lean-Agile approach to software development described in Lean-Agile Software Development: Achieving Enterprise Agility (Shalloway, Beaver, Trott, 2009).
About the Author
James R. Trott is an senior consultants for Net Objectives a global consulting/training firm focusing on corporate-wide lean-agile transitions. He has collaborated on several books including of Lean-Agile Software Development: Achieving Enterprise Agility , Design Patterns Explained: A New Perspective on Object-Oriented Design, and the Lean-Agile Pocket Guide for Scrum Teams.
