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.