In the transformation cases I coached in the past, the starting method was based on what Mr. David J. Anderson, the father of Kanban, called a successful approach (Note 1, the first step, focusing on quality) to start to change the organization. The behavioral model of the company starts from "requiring quality", more specifically, it starts from the development department.
This agile starting method seems very reasonable, because the initial stage of agile was originally developed for the development unit (the goal of the agile manifesto in 2001 was to focus on the development team), so it is reasonable to start from the development unit Now, it is an indispensable requirement for development and operation and maintenance units to request quality improvement. Therefore, it is rarely opposed to starting from here. Besides, quality improvement is an act in exchange for discipline. The team has advantages and no disadvantages, and few people object to it. But I found this to be wrong...
Agile transformation should start from the product department
Recently, I suddenly discovered that it’s right to start agile transformation from PO. Why? Because if it is a client, you will be asked to see the results every 2 to 3 weeks during development and require a functional review. , Is it right or not suitable for my purposes, and then seeks my feedback to make adjustments, isn’t this a small incremental and iterative development? This is agile! And the customer’s demand only requires One or two development cycles produced by the development team is enough, and the priority of requirements is also the customer's say.
The review meeting at the end of this small development cycle (review meeting, which is equivalent to the review meeting of SCRUM) seems to be an acceptance inspection. The team member who plays the role of the customer is not exactly our familiar PO (product Owner). )? His request will naturally lead the team to agile path.
In order to meet the requirements of the PO, the team had to adjust the pace into a small increment and small iteration mode. At this time, the development process naturally conforms to the spirit of agile, and the team’s development method is naturally agile. , It's really a multiplier. So agile transformation should start from the product department where the PO is located.
People's needs are what really changes the world.
Let demand agile to guide the development team
It all starts with making the requirements agile. Don't let the development department dominate the agile behavior anymore. You should let the requirements guide the behavior of the development team. Once the requirements become agile, the team will naturally become agile.
And how does the demand become agile? Naturally, the product planning department uses a method that conforms to agile development to plan the output of the demand. The inference from this is that the organization's implementation of agility must start with the product planning department.
In the past, my practice has always started from the agile work of the development department, based on getting developers to set foot on the correct agile principles, and using a small development team to successfully achieve agile as an example, as an organization agile I hope that this successful case will attract other teams to follow suit.
This kind of start-up is a suggestion in many books. A successful case allows the development team to lead the agile process, and use a good start to gradually implement agile.
To be honest; after so many years, if I were to do it once, I would choose to start with the agility of the product department. Perhaps this is due to the changes produced by the implementation of DevOps. Let’s use the following diagram to illustrate: First of all, the concept of DevOps should essentially include business operations, so the full name should be Business DevOps, and DevOps It is the abbreviation (Note 2.).
Contains DevOps icons for business operations
The above figure illustrates that if only the development unit implements the agile development model of Scrum, it is essentially running Water-Scrum-Fall rather than real agility.
Real agility must be promoted forward and backward. Therefore, starting from the product department to implement agility can be a more labor-saving way, that is, the most suitable starting point is to start from the place where it can be carried on.
Agile is not just a single department agile, which means that agility is successful. It must be agile from operation and maintenance, development to business departments, so that the enterprise can taste what kind of success it feels.
The agile approach from the development department is a bottom-up approach, while the approach from the product department to the agile approach is more biased towards the top-down approach. The relative success rate will be higher. Of course, the support of senior leaders is still a prerequisite for success. It's just that starting from the customer's standpoint to be agile will be more in line with a customer-oriented way of thinking.
Demand Kanban Up Stream / Development Kanban Mid Stream / Operation and Maintenance Kanban Down Stream
Demand Kanban is the source of agility
If you can start agile from the demand side, the downstream development and operation and maintenance side can naturally follow the demand and gradually become agile.
This principle is not difficult to understand, but where does the implementation start? From the needs of all parties, the operation can be roughly divided into two parts: planning and execution.
The green part of the above figure is the execution Kanban during operation, that is, the execution part. In addition, there should be a planning Kanban with a macro view of the enterprise, and it is also the planning part (it should contain many large-particle requirements, and the flow path Relative units need to cooperate with the value stream, so I won’t go into details here).
Its flow method determines the basis of all other Kanban boards downstream. Including which unit is responsible for when to start and what kind of cooperation is needed.
The quality of requirements determines the effectiveness of the development team, and the agility of requirements affects the team's development model .
Requirements must be visualized first; visualization may be the most important procedure. It can ensure that the development process can be carried out in accordance with lean principles and can appropriately eliminate the barn effect. Therefore, the starting point for the product department to implement agility is of course demand The Kanban is issued so that it reflects the progress and process of planning and execution in a pragmatic manner (the definition of completion of the definition of done is different. This is the biggest difference from the traditional Kanban. Instead, it will focus more on processing the definition. of Ready means that the information is ready).
Use transparent information to communicate with all relevant units. This step is the beginning and will be an important factor in the success or failure of agility.
Conclusion
If the "secret to success" of the father of Kanban's corporate transformation is a method to reduce the resistance to organizational transformation, then the agile startup method starting from PO requirements is a transformation method with half the effort.
The agility of development and operation and maintenance will be affected by the agility of PO's product planning, a kind of agility that is naturally formed based on customer requirements and in order to match the needs.
This way of thinking is that because of the demand from the client, the agile triggered is the agile that naturally responds to the demand. It is a kind of agile derivative process that is not smooth, and the premise is customer-oriented.
Therefore, using a kind of "agile demand" to trigger development, operation and maintenance cooperation and naturally change the mode of agility is a transformation method with half the effort, and also a development mode that conforms to the customer-oriented development.
Note 1. "The Kanban Method: The Way to Success in Technological Enterprises' Progressive Transformation" by: David J. Anderson
Chapter Three is a secret of success. There are six steps:
-
Focus on quality;
-
Reduce work-in-progress;
-
Frequent delivery
-
According to the delivery rate to balance demand (demand) request volume;
-
Prioritize;
- Eliminate the root causes of variability and improve predictability.
Note 2. BizDevOps (Business DevOps) Many organizations have reflected this doubt to the father of DevOps. Patrick’s answer agrees that DevOps should include business operations, but the term DevOps has been accepted by the public, and there is no need to make changes. To add more doubts, as long as the correct interpretation is good.