Lean ALM step-by-Step Guide

Lean ALM sounds like an empty word. For enterprise organizations, the adoption of ALM is not very successful. The lack of support and continuity in many of these implementations has led to a fruitless effort. Lean is a collection of great ideas that need to support and invest in organizations. But don't resist it, I'm not suggesting that you work with an expensive management consulting team, or change anything. On the contrary, my intention is to encourage you to use these ideas. Merging these ideas requires organizations to implement software delivery in a systematic, process-by-step manner, focusing on simple changes rather than adopting complex, unrealistic ideas.

The first step-identify the process owner

Identify the process owner. It's almost impossible to improve anything without a process manager. The traditional single discipline areas such as requirements, development, and testing are already paying attention to improvements in their functionality, but they do not consider the whole. Management or SDLC-driven approaches tend to focus on control, management, and products rather than end-to-end value chains. Real processes are the only processes that are unique to the team, the scenario, and the problem at hand, not those that remain at the abstract level. SDLC focuses on telling people what to do, not why, and not helping individuals improve their job skills. By combining lean and ALM, you define a process owner or a "teacher" role, focusing on improving the process and applying the changes to the right people, processes, or technologies. To do this, the process owner should:

Learn some lean technologies-you don't have to be a lean expert or read thousands of books related to the topic, but it's a good starting point to spend time learning some key concepts and techniques. James P. Womack's Lean thinking: eliminating waste and creating wealth in your company is a very good book to learn lean. The book introduces all the lean concepts through an example of car manufacturing.

Building a team--you're not alone in the process of change, software delivery is a value chain that contains many stakeholders. A team should include leaders in all areas of academia, such as testing, development, and operations. By including these people as change agents, it is possible to measure change and be more likely to achieve change.

Understanding the task of change-lean, ALM, and process improvement is a very interesting thing, it is difficult to gain momentum without clear change tasks and goals, and it is difficult to make the right improvement decisions. For example, is the change to shorten the cycle, to reduce costs, or to improve quality, or to deliver more business value? By selecting a subset of these goals, you can create and drive a plan.

Step Two-process flow

Understand End-to-end process flow. To follow the value rather than the data or the activity, the process owner is able to model the steps necessary to deliver the process objectives rather than the activities completed today. By reviewing the stages of the work process, the process owner can identify the participants in the process and the work they are doing. This batch of work will also become clear. For example, did all of the requirements move from the analysis phase to the development, or did you only develop a small part? One caveat to doing process modeling is that progress is more important than the perfect result. You can spend years building a perfect application lifecycle process model that describes all the possible paths and scenarios, but obviously the value comes from modeling the main steps. Therefore, it is important to focus on understanding the overall operation of the process, rather than spend a lot of time building a perfect flowchart. To focus on the process model you should:

Define the scene--identify all the scenarios and focus on the main scenarios. By listing all the scenarios, you can make a decision based on the scenarios that are relevant to the analysis. For example, a scenario such as a bug fix, platform upgrade, or product defect may not be important for a new project or primarily to enhance these scenarios.

Review work transformation--describe the stages of the work process in detail. Anyone familiar with process modeling can comfortably create workflow models, stages of work processes, and participants. Another possible point of view is artifacts, how to deal with defects and requirements, and what state these artifacts have undergone during their life cycle? A finite state machine such a technology can help you uncover some interesting states.

Activity modeling-It is clear who completes the operation to help you fully understand the process. Activities are both formal and informal in nature. Try to find social content in your work, because the interaction between groups or individuals may be as important as the formal process. Social graphics have become a very popular form of social interaction modeling, and it also provides a very interesting observation point that lets you know who is really using the application. By drawing social graphics in the history of application changes, you can identify the real process participants.

View tools and technologies-for many organizations, the tool defines process boundaries. You can determine process automation, data definition, and process boundaries by looking at how the tools are being used and how they are connected. It is also possible to use a variety of tools in the same process, which usually stems from a lack of a clear understanding of their connection points. By summarizing the usage of the tools, you can find the intersection of them.

Skill review--skill review is an interesting by-product of process review. Although tools and process skills are not necessary technical skills, they are required by the team to deliver the working software. For many organizations, they see the process as part of their own business DNA, but usually the DNA is not fully understood by the team that uses it.

Step three--road map

Lean provides a framework for improving process flow, so it is important to create a plan or roadmap that describes improved processes, significant changes, and improved areas. Sometimes, the roadmap identifies areas where the connections between groups are broken, and the implicit and explicit process models are not the same. A good example is the process assumed by the Test team (development of how to manage defects and the faulty understanding of engineers). Addressing these process issues does not necessarily require a change of process, but requires training, communication, and discussion. The nature of the roadmap is to provide a clear communication context for software delivery organizations that can improve understanding. To build a roadmap, application delivery experts should:

Mapping the current state to a change instruction is the first step-the existing process model provides a clear definition of what is happening now, and any future state should consider the goal of change. If the motivation for change is to shorten the cycle, it is necessary to review existing processes to identify the cause of the delay and identify areas for improvement.

Identify quick success Tips (WINS)--many people are labeling process improvements as slow, ineffective, and difficult to achieve the desired target. But it's possible to change the way you think about process improvement and create a culture of change within your organization by looking for quick, easy to use tips.

Build the roadmap-don't spend months building a comprehensive, detailed plan, but stand at a high level to describe the changes you need to make. For example, the first phase might be to introduce process automation instead of a spreadsheet between development and testing, and the second phase might be a dashboard that shows everything. The key is to provide some simple guidelines for change, allowing the team to plan their work. It is important that all plans be flexible enough to change, because experience can help change leaders understand realistic scenarios.