Agile practice of cross-iteration of mobile teams

Hurry up! Do a little more!

In this era of mobile internet, as a mobile development team, the word "fast" is particularly important to see. Not only the mobile development team, but each development team is focused on team efficiency, specifically, is concerned about the development efficiency and output. Managers often ask questions like: Is it faster to go online? Can you increase the output of each iteration?

There are many factors that affect team efficiency, often the result of a synthesis, and we try to improve the agile iterative process that the team is performing, using a cross-iterative model for software development, only for faster product launches and increased output for each iteration.

Chain of interlocking

Let's start by outlining our basic situation in traditional iterations.

Our team is an Android client development team with product managers, interaction designers, visual designers, development engineers, and test engineers. Responsibilities of each role are no longer mentioned. From the start of the iteration, until the deliverable version is delivered, it is defined as an iteration, usually with a period of 3 weeks. In this 3-week iteration cycle, the first half is developed primarily with new features, the second half with optimization and bug fixes, and through frequent development, testing, and production on-line versions.

With the rapid development of products, we need to further improve the speed of release, the ideal situation is shortened to every 2 weeks to have a live version. Of course, it is not possible to reduce the number of outputs due to short time, or to keep enough new features available to the user for each on-line version. This means that we have to reduce the line spacing, but also to maintain the previous capacity.

With the challenge of "wanting a horse to run and want a horse to eat grass", we need to identify the issues that affect these two factors in previous iterations before trying to make a targeted adjustment.

In a team of more than 10 people, we note that the cost of communication is very high, and that rapid changes in client products require information to be shared and communicated among the roles, and to create a consistent understanding. The station will be more synchronized with yesterday's completion of the situation and the work to be done today, but the details of today's work still occupy a lot of communication time. Even within the development engineer, it can take a lot of time due to interface changes, intermodulation, code checking, and so on. How to effectively reduce communication, has actually taken a number of measures, such as the message group, Mail group, promote face-to-head communication. However, it is often possible to hear the characters complaining of "talking in the daytime and working overtime at night", which not only consumes the iteration time, but also negatively affects the output.

One way to reduce the cost of communication is to split the team, make the big team smaller, reduce the number of communication participants, so that it can improve the development efficiency, can spend the same time to produce more code.

On the other hand, if the iteration cycle is shortened to 2 weeks in order to launch a version every 2 weeks, fewer people and shorter time, there will be a reduction in output. In order to ensure the output, when the number of people are less and if the iteration cycle is extended to 4 weeks, you can do more development work. If we let two teams cross for 2 weeks, we can guarantee a delivery version every 2 weeks.

Through the previous analysis, we have formed the cross-double iterative model shown in 1.

Figure 1 Cross-double iteration model

We divided a development team into two groups A and B, and group A first started a 4-week iteration, a sprint in the diagram. In the middle of the iteration, the Group B then starts a 4-week iteration, each of which develops iterative content, creating a cross-iterative rhythm. From a macro perspective, the product is released alternately by each group, with a period of 2 weeks, and each group's iteration period is extended from 3 weeks to 4 weeks. Over time, repeat this iterative process.

method is always more than the problem

Through this iterative adjustment, the model looks to meet the needs of the version to be faster and more functional, but in the actual implementation process, we also encountered a lot of problems.

The first is the issue of code management. Since two teams are developing, the biggest risk comes from code merging. In this regard, we analyze the characteristics of the previous iterations, found that a large number of code is often in the first half of the iteration time, to the second half is often more small changes. Therefore, we use the backbone Development Branch on-line way to manage. That is, the team that started the iteration uses backbone development, and when the development is halfway through, another team merges the finished code into the backbone, and the current team is branching out from the trunk pull-out branch to the team that is about to start the next iteration. 2, the Group B starts in the backbone development, when group A completes the line to merge the code into the trunk, at this time the Group B takes the merged code out of the branch for the development and online work of the second half of the iteration, a group initiates a new iteration and occupies the trunk to continue to develop. So alternately using trunk development, branch on-line.

Figure 2 Code management schematic

We used this approach to code management when using SVN, and with git, we changed some ways of managing it because of the lower cost of branching, which can be adjusted according to the actual situation.

Another problem is the effect of using this model to what effect. Has the code quality improved? Has the capacity increased? As shown in 3, we measure the development quality with the number of bugs per 1000 lines of change code, which is the number of thousand-line bugs, which is the blue column in Figure 3. By comparing the iterations of the front and back, you can see that the number of thousand-line bugs has dropped, and we attribute this to the development engineer having more time to focus on the quality of the code. Looking at the change in the number of stories in red, we represent capacity with the number of stories completed per iteration, and we can see from the front and back that the number of stories has improved, and we have attributed this to the extension of the iteration cycle to develop more features. Of course, the number of stories is influenced by the split granularity of demand and the change in people by the product manager, but the output from multiple iterations after implementation has at least reduced capacity.

Fig. 3 effect before and after the implementation of the double iteration in AC-standing

There is also an understanding of the need for consistency issues. In reality, a lot of bugs and non-effort stems from inconsistent understanding of demand, and there are still cross-team requirements across iterations after using two teams. Therefore, the requirement review will be for all members to participate, certain procedures can ensure that the long-term needs of a consistent understanding, everyone should be responsible for the demand. We also use this approach to solve the problem of design consistency. Of course, this alone is not a complete guarantee, and we are constantly exploring it.

There is also a problem with the organization of the standing meeting. We have tried two teams each to open a meeting, also tried to close together to open a meeting, and finally we use a separate station will be but the role of the person in charge at the same time to participate in the two-stop program. On the one hand to ensure that the station will be in the role and effectiveness of communication, on the other hand to cross-group work by the responsible judge and unified coordination.

There are many other problems, such as what to do with a bug left over from an iteration? How are the teams divided? Are team members allowed to adjust dynamically? All these need to be dealt with according to the specific situation, this article does not answer.

It's not a silver bullet .

Of course, any model has the applicable conditions, there are not applicable cases, the model also has some shortcomings. For example, iterative cycle extension is not conducive to rapid response to change, the quality of personnel and ability requirements, everyone's workload is more full, code merging will produce new bug,bug to cross-team maintenance, delivery time interaction and so on. Therefore, whether the use of the need to carefully consider, this article is also a point, not to say that this model is good, everything from the team's specific circumstances, tailoring the process model for the team is our ultimate goal to pursue.

build an efficient team

Summing up the agile practice of this cross-double iteration, the successful implementation requires the concerted efforts of all the roles, a sense of global awareness and a high sense of responsibility, and agile coaches and role managers can effectively manage the development process and coordination of resources between iterations, more importantly, the individual capacity has higher requirements. Without these guarantees, there are a variety of complex relationships in the process of a single iteration, which may be subject to considerable resistance.

Through the process model to create efficient team, not only need to choose the right model, but also the need for long-term continuous process improvement, to promote the formation of team rhythm, long way to repair.

--This article is published in "Programmer" Magazine 2014 07, if you need to reprint, please contact the press-

Agile practice of cross-iteration of mobile teams