Lean ALM sounds like a mouthful. For enterprise organizations, the adoption of ALM was not successful. A majority of implementations ran out of support and follow-through resulting in nothing to show for the effort. Lean is a great set of ideas, but its approach requires support and investment for organizations. Don’t be put off by this; I am not proposing working with an expensive management consulting team, or changing everything. Instead I encourage you to draw on both of these ideas. Combining these two ideas requires organizations to approach software delivery in a systematic, step-by-step way, focusing on simple changes rather than adopting complicated and impractical ideas.
Step One – Identify a Process Owner
Identify a process owner. Ultimately it is hard to improve anything without a person who is responsible for the ‘it’. Traditionally individual discipline areas such as requirements, development, or testing have focused on improving their capabilities without considering the whole. Management or SDLC driven approaches have a tendency to focus on control, governance, and artifacts rather than the end-to-end value chain. The reality of process, other than at an abstract level, is that process is unique to the team, situation, and problem at hand. SDLC’s concentrated on telling people what to do rather than why or helping improve the skills of the individuals doing the work. By combining Lean with ALM, you define a role of the process owner, or ‘Sensei,’ focused on improving the overall process, applying changes to people, process, or technology as appropriate. To do this the process owner should:
- Learn some Lean techniques – You don’t have to be a Lean expert or read thousands of books on the topic, but spending some time learning a few key ideas and techniques is a great place to start. An excellent book to acquaint yourself with Lean is ‘Lean Thinking: Banish Waste and Create Wealth in Your Corporation’ by James P. Womack. It introduces all the ideas of Lean in the context of automotive manufacture.
- Build a team – You are never alone in your change process, and software delivery is a value chain with many stakeholders. A team should include leaders in all the discipline areas such as Testing, Development and Operations. By including these people as change agents the improvement will be quantifiable and more likely to be implemented.
- Understand the mandate for change – As much as Lean, ALM, and process improvement are fun things to do, without a clear mandate for change and objectives it is hard to gain the traction or make the right decisions about the improvement. For example, is the change to reduce cycle times, to reduce costs, to increase quality, or to deliver more business value? By selecting a subset of these objectives it is possible to create and drive a plan.
Step Two – Process flow
Understand the end-to-end process flow. By following the value, rather than data or activity, the process owner can model the steps necessary to deliver the objectives of the process rather than the activities completed today. By reviewing the stages work goes through, the process owner will be able to identify who is involved and what they do. Batch size also provides clarity. For instance, do all the requirements move from analysis to development or do only small batches make the transition? One word of caution when doing process modeling, progress is more important than completeness. You can spend ages building the perfect process model for the Application lifecycle, describing all the possible paths and situations, but frankly the value is modeling the major steps. It is therefore important to concentrate on getting a broad understanding of the flow rather than spending many hours building a perfect view of the process. To focus your process models you should:
- Define the scenarios - Identify all the scenarios, concentrating on the primary ones. By listing all the scenarios, you can decide on those that make sense to do analysis on first. For example, scenarios such as bug fix, platform upgrade, or production defect might be less important than new project or major enhancement.
- Review the work transitions - Detail the stages the work goes through. Anyone familiar with process modeling will be comfortable creating a process model of the work, the stages it goes through, and the people involved. Another possible point of view is the artifacts; what happens to a defect, a requirement, and what states do these artifacts move through during their life? Techniques such as finite state machines can help you uncover some interesting states.
- Model the activities - The actions completed, and by who, help you create a complete understanding of the flow. Activities often are formal and informal in nature. Try to uncover the social aspects of work; the interactions between groups or individuals may be as important as the formal process. Social graphs have become a popular way of modeling social interactions and provide interesting observations of who is actually working on an application. By directing a social graph at the change history of an application it is possible to identify who really is involved in the process.
- Look at tools and technologies – For many organizations the tools define process boundaries. By looking at tool usage today and how the tools are connected, it is possible to identify the process automation, data defined, and the process boundaries. It is also likely multiple tools are involved in the same process, often without a clear understanding of their connection points. By outlining the tool usage, you shed light on the intersection.
- Review skills - One interesting side product of a review of the process is a review of skills. Not necessarily technical skills, but tool and process skills necessary for teams to deliver working software. For many organizations the process is considered to be part of the DNA of their business, but often that DNA is not clearly understood by the teams working on it.
Step Three - Roadmap
Lean provides a framework to improve the flow of a process, it is therefore important to create a plan or roadmap describing the improved flow, highlighting changes, and areas for improvement. At times the roadmap highlights areas of disconnect between groups where implicit and explicit process models are different. A great example is an assumed process by the testing group on how defects are managed by development and a different, equally incorrect perception by engineering. Fixing this process does not always require process change, but instead education, communication, and discussion. Roadmaps, by their very nature, provide software delivery organizations a clear, communicated context allowing improved understanding. To build a roadmap, application delivery professionals should:
- Map current state to mandate to change is the first step - The existing process models provide a clear definition of what is happening today while any future state should consider the objectives for the change. If the motivation for change is to reduce cycle times, reviewing the existing process for what slows down the release identifies areas for improvement.
- Identify quick wins – Many people label process improvement as slow, ineffective, and not delivering on its promise. It is possible to change the perception of process improvement and create a culture of change in the organization by looking for quick and easy wins.
- Build a roadmap - Do not spend months building a comprehensive, detailed plan; instead focus on describing the needed changes at a high level. For example, introducing process automation to replace a spreadsheet between development and tests might be Phase 1, and Phase 2 might be a dashboard showing burn down, etc. The key is to provide some simple guidelines for change allowing the team to plan their work. It is crucial that any plan is flexible enough to change as experience helps the change leader understand the reality of the situation.
Step Four – Incrementally introduce change
Big bangs rarely work; instead focus on incremental process improvements that slowly introduce improvements and change. If development teams are working in an incremental or iterative way, it is possible to include increments of change into their work plans or backlogs. By treating process improvement as a natural part of normal work, balancing it with other more traditional project work makes it possible to include more people in the change. More importantly, it gets direct feedback from real projects doing real work. A great example is the introduction of an improved build process: if teams are currently doing their own builds, have that development team do the additional work to improve their existing build process. Don’t try to skip steps by having some central team create the “perfect” build process, such attempts usually fail. Incremental changes require:
- Building a change backlog – The change tasks need to be put into a backlog and incrementally allocated into normal project work iterations or sprints. By having this aggregated view, it is possible to report progress against these work items both inside and across iterations.
- Involve an architect – Not all work items require the adoption of new technology or tools, but it is likely technology will form some part of any change. Incremental, distributed change can increase the risk that the individual teams adopt technology they choose rather than what is right for the organization. To manage this, allocate an architect to the project responsible for ensuring the work conforms to the overall organizational objectives and supports everyone, rather than just one team.
- Pivot as necessary - There is nothing that replaces experience. Incremental adoption has the benefit of providing real usage experience and data, which can be fed back into overall program, allowing the change leader to change the direction of the program. It is likely the best-laid plans will need to adapt when up against the hard, often surprising, realities of the real world.
Step Five - Measure
It is almost impossible to improve anything without clear measurements in place. By looking back at the overall mandate for change, it should be easy to identify key measures. Those measures should be implemented throughout the process, allowing cause and effect to be determined. Measures however are often the hardest thing to implement. as many organizations concentrate on measures such as plan-to-actual, production outages, and budget as key indicators. These indicators are important but are focused on effect rather than cause. Augment those measures with measures driven by the mandate for change – For example, if cycle time is the overall objective, start measuring deployment times in development, test automation coverage, and include a time task to complete the work being included in a deployed build. Measurement requires application delivery professionals to:
- Identify key performance indicators – Evaluate the mandate for change with a view to cause and effect. Undertake some experiments to review how certain actions and associated measures would provide insight in delivering against this objective.
- Put a scorecard in place– but do not think the criteria on the scorecard are fixed. It is likely that during the practice of improvement the measures you thought were important are not. Remember to include stakeholders from both inside and outside application delivery to ensure their needs are clearly understood. Sometimes this requires a re-evaluation of the mandate for change as what they care about, and why, is reflected in the measures. Lean techniques, such as Kanban, can help visual the flow, and are often a key first part to any scorecard.
- Automate the collection of data – manual data collection has many faults, not least of which being it takes time and costs money. Manual data collection often costs more time and money than any use of the data would remove from the process. Thus, overhead measures should be avoided if possible; instead concentrate on the use of technology and tools. This may require engineering work; work that should be included in the improvement project and inserted in to the engineering process.
Conclusion
It is clear that 21st century development needs to both better managed and more flexible. The friction between these two philosophies creates the opportunity for you to re-evaluate your use of ALM and introduce the ideas of Lean Thinking. ALM encourages the use of measurement and connected tools; Lean provides the underlying motivation, techniques and community to pursue reducing waste and increasing value. The combination not only gives you a destination, but the techniques necessary to get there. As an industry, it is time to accept our processes and practices lag behind the great technology we have available to us. By looking to industries that have gone through similar revolutions, not only can we deliver amazing software, we can extend and grow our craft.
About the Author
Dave West is the Chief Product Officer at Tasktop. In this capacity, he engages with customers and partners to drive Tasktop’s product roadmap and market positioning. As a member of the company’s executive management team, he also is instrumental in building Tasktop into a transformative business that is driving major improvements in the software industry. As one of the foremost industry experts on software development and deployment, West has helped advance many modern software development processes, including the Unified process and Agile methods. He is a frequent keynote at major industry conferences and is a widely published author of articles and research reports, along with his acclaimed book: Head First Object-Oriented Analysis and Design, that helped define new software modeling and application development processes. He led the development of the Rational Unified Process (RUP) for IBM/Rational. After IBM/Rational, West returned to consulting and managed Ivar Jacobson Consulting for North America. During the past four years he served as vice president, research director at Forrester Research, where he worked with leading IT organizations and solutions providers to define, drive and advance Agile-based methodology and tool breakthroughs in the enterprise. You can also connect with Dave via Twitter @DavidJWest.