The Key to the Implementation of Scaled Extreme Programming: Development Process Management

For the real implementation of scaled extreme programming, the key lies in the matter of "development process management": it requires someone to disassemble the user story into a series of simple processes, and the person who writes the code must realize it in a standardized and high-quality manner in a simple process.

I. What is Development Process Management ?

The so-called development process management is to manage the work steps of developers so that their output code can meet the code quality expected by the organization.

II. Why Process Management is Needed ？

There is a chasm of development process management in front of the ideal and reality of DevOps. When many organizations implement DevOps, they only set up the toolchain and platform, but no projects are running on this platform at the pace expected by DevOps, that is, they cannot be released quickly. The value does not flow continuously, and they are stuck.

This is because developers cannot produce software that can be quickly returned and naturally cannot be released quickly. Even if it is released quickly, quality problems may be hidden.

The reason why this problem can not be solved is that developers lack the ability to self-test and the ability to write tests at scale. Therefore, we can not form software that can be quickly regressed and verified. If we can't develop the ability to write tests at scale, the implementation of DevOps will eventually be like driving a convertible sports car into space. Even if you fly once, you may not have a second time.

Before scaling, let's first look at what an individual who can be competent in process management looks like. When we compare the work of a developer with strong self-testing ability and a programmer with weak self-testing ability, we will find that their work steps are completely different.

Developers with a strong ability can decompose requirements into processes composed of testable steps according to the architecture design and can write test-protected code efficiently according to the process. Developers with a weak ability can only disassemble requirements into the steps of writing code. As for whether the code can be tested or not, they are no longer considered. Although their follow-up work time is almost the same, one of the output codes has been tested, and the other has not, and it is also difficult to add.

In our past process improvement experience, it is not easy to decompose requirements into testable steps according to the architecture design. It requires specific competencies - analytical thinking and a small amount of conceptual thinking, which are scarce among software developers. Therefore, the former process is difficult to be popularized. If we do not solve this problem, the software we produce is always software that is difficult to return quickly. Therefore, we need process management, which can help us standardize the behavior of developers and enable developers to produce test-protected code on a large scale efficiently.

III. How to do Process Management？

Before explaining how to do process management, we should first talk about a concept: leverage ratio.

Leverage ratio is the ratio between senior personnel who can be competent (we will call them Sr. later) and junior personnel who are not fully competent (we will call them Jr. later), such as 1 Sr. with 5 Jr. The leverage ratio is 5, which is called high leverage. On the contrary, if there is 2 Sr. with 1 Jr, Then the leverage ratio is 0.5, called low leverage. Then the purpose of introducing this concept is naturally that the means of process management are different in the case of different leverage ratios.

If the leverage ratio is relatively low, that is to say, junior staff are precious, and senior staff are everywhere in the team, then it will not be troublesome. We can set up a mentor for junior staff, and if one is not enough, we can set up several more. Many teachers teach a student at the same time (this statement should not be out of date). A group of teachers stare at the code you output and teach strictly. I don't believe you can't learn.

This is also why this concept was rarely mentioned in the early engineering practice methodology because low leverage was a common phenomenon in western society.

However, in China, this phenomenon is completely untrue. Our industry has exploded with a growth rate of 25% for so many years. The current situation is that the leverage ratio is high, and Sr. may not be competent. At this time, we need to carry out process management more suitable for Chinese characteristics according to the current phenomenon.

First, we need to talk about architecture because architecture guides us on how to decompose the processes and has a strong guiding significance for how to do the daily coding work. If the architecture is not easy to test, then the corresponding process is difficult to form, or the testing cost of some steps is too high. Due to our industry's rapid development, I am unsure whether our current architects are generally competent in this matter. From the current situation, general incompetence may be closer to the truth. Perhaps the first step of process management is to help the architect to create an architecture with high testability. At least we don't need to add hardware or deploy it to the UAT environment for testing, which is not suitable.

Next, we need to train our Sr. staff to " decompose requirements into processes composed of testable steps according to the architecture design and write test-protected code efficiently according to the process. "Then junior staff writes code according to the process.

Finally, what we want to discuss is working hour management. Each task we split should be completed within a fixed time. If it is not completed within a fixed time, we regard it as an incident and need to analyze it and propose an improvement plan. Usually, we can find that there is either a problem with the dismantling of the process or a problem with the ability of junior staff so that we can carry out capacity building in a targeted manner.

IV. Details of the Implementation

1. Whether the Architect Disassembles the Process ？

The Architect should learn this first. After all, he should be able to solve the problem of how to split the processes. Therefore, we need to make a sample to see how the process is split and whether it can be split into a process for producing testable code. Then he also needs to write the code to see if there are any obstacles in mapping the process to code. Sometimes when he writes it himself, he will find that many key details have not been thought out before, which is also good for the Architect.

2. Sr Should be Competent First.

This is not a very common thing. After all, incompetence is too common in our industry. First of all, Sr should be able to disassemble the steps that can be tested, which is not easy. For many people, it is very challenging to decompose each step into testable steps. When mapping these steps into code, we find that more people cannot map correctly according to their assigned tasks. The steps of writing code may not match the steps of dividing, let alone each step that can be tested. This is a key point of capacity-building.

3. Continuous Optimization 

By tracking the completion time of the process, we can not only get efficient individuals but also find bottlenecks in efficiency and further improve the process, such as by developing some tools.

4. Does Process Management Repeat the Concept of Software Blue-Collar

First of all, the conclusion is not. Because of software, blue-collar workers only write code, compress the programmer into a small part of the code, do not consider the problem end to end, regardless of requirements, and do not consider how to test.

Process management is only compressed into a smaller problem domain, but this problem still needs to be understood, thought about and tested. We have to admit that ordinary developers may not have a high level of cognition at the current stage, so our process management is a working method of cooperation between novices and skilled staff, and it is a scene of cooperation between novices and skilled staff in the pursuit of a larger leverage ratio.

Through a more efficient way of teaching, helping, and leading, senior staff teach ordinary developers the ability to perform process decomposition under the current business and current architecture. When the novice's cognitive ability is improved, he can naturally solve larger problems instead of isolating the developer from the high-level work and alienating him into a screw that can be replaced at any time. Compared with the relationship between software white-collar and software blue-collar, senior developers and junior developers are more like the relationship between teachers and students or between coaches and athletes.