Agile development ecosystem Series 4: plan tracking II (self-organizing team-Development Team Self-estimation-po challenge estimation-peer pressure)

This is the fourth article in the agile ecosystem series (One, Two, Three, Four, Five ). Half of the content belongs to the demand management ecology, and half of the content belongs to the Planning and Tracking ecology.

In the actual development environment, product owners often have potential conflicts with development teams. The former often wants to develop more features in a shorter period of time, while the latter's performance mostly comes from data that will decrease due to "shorter-more" planned punctuality rate/defect rate, the gap between the two began.

The plan tracking ecosystem II in Agile development is roughly like this (in bold, the elements in the picture ):

What is the correct interaction between the product owner (PO) and the team?Self-organizing teamOne of the core mechanisms for normal operation.

The right of the product owner isUnified management and explanation of requirementsAndDemand priority sortingAnd the obligation is to accept the estimation from the development team, andPromise not to change during Iteration.

The team's right lies inEstimate by yourselfThe obligation is to accept the requirements set by the product owner, implement standards, and sort priorities, and make their own estimates.Team commitmentThis commitment will motivate the entire team.

The product owner cannot intervene in the Team's estimation, but canChallenge Estimation. The estimation of challenges can be done by comparing the two teams to handle similar tasks, compared with the previous similar tasks and the current task. The team's sense of honor will generate a sense of inter-TeamPeer pressure(Compared with other teams and their past ),Motivated individual.

AsSelf-organizing teamProduct owners and teams do not have a leader relationship, but the product owners and teams manage each other through separation of power and commitment.Higher Work Efficiency.

Self-organizing team-Development Team estimation-po challenge estimation-peer pressureIs one of the main lines of this ecosystem.

Let's take a look at the examples of conflicts between product owners and teams.

The simple and crude solution is similar to the following:

1. The product owner is not allowed to intervene in the estimation.

2. The team has the final right to determine the estimation result no matter whether the team accepts any challenge (question ).

These seem to be good systems that comply with the scrum idea, but they become a problem sooner or later. Assume that in the project development environment, the product owner is a sales/pre-sales * (or someone with similar performance mechanisms), and his performance comes from contract amount + customer satisfaction, X % is extracted from the contract amount as a bonus, and the development team's performance comes from the on-time completion rate + defect rate compared with the plan. This structure has already determined that the two ideas will go against each other, and no R & D methodology can unify their thinking. Soon, the former will sacrifice customers to break the company's system, andThe determination of senior management to defend scrum is far less than the determination to defend salesThe system will soon be saved.

What should I do? Start with the "self-organizing team.

The author is preparing a "self-organizing team series", the first of which is in draft status (as ). The name of this article is "management team with TCM theory ". Due to medical technology limitations, traditional Chinese medicine never knows the existence of external factors such as "bacteria" and "viruses", but only knows that the human body has problems, for example, "the rise of liver fire leads to evil infiltration". Therefore, it is very effective to treat acupuncture as without any drugs. For an agile team,To streamline the relationship between product owners and teams, the first thing to do is to adjust the interests of the team..

In agile outsourcing project 2: three companies were mentioned in the personnel structure. One company awarded 10% of the project amount to the Team as a bonus, and the other one included the R & D cost to the product department, the implementation cost is included in the sales cost of the sales staff, which greatly unifies the product owner and team awareness. The three teams and other similar teams have two practices:

1. Calculate the R & D cost into the sales cost.

This will ensure that the product owner (sometimes a team) will be very concerned about whether the customer really needs a function, rather than following the principle that the more the better, the more blindly pleasing the customer.

2. Place the project revenue to the R & D team

This will ensure that the R & D team is"ProfitabilityThis developer seldom cares about but is an element of the company's foothold.

After completing these two steps, the prototype of a self-organizing team emerged. Now the company's senior executives do not have to conduct arbitration every day. The two sides will sit down calmly to think about the problem and find the key solution.

I have been to many game development companies, most of which have several or even dozens of game R & D teams, each team has a product owner (Planning Team) and a development team. They are all highly self-governed. In addition to the major milestone reviews that affect investment and earnings, the leaders have almost no details, such as what development methods they are using and what they are doing recently. Because their core internal mechanism is one: making money. The features that do not make money will not be proposed, and those that make money will not be lazy.

This may be a bit difficult in project development, but it can be seen from the agile outsourcing series that there is still a lot of practical work to do.

 

After completing the initial construction of the self-organizing team,Estimate by yourselfAndPo challenge EstimationIs completely changed to another, andPeer pressureIt is also quite different from the previous one. People will:

1. The team should try to shorten the estimation as much as possible and try the fastest way to achieve it. -------- because no one has assessed the "completion rate on time", there will be more bonuses from customers as early as the completion.

2. "a lazy person" will no longer exist, because he not only blocks his financial path, but also blocks his team's Financial Path ---------- so the leader does not need to install cameras and screen monitoring software.

3. the Po will no longer exist during the construction period. I have seen a po and I am worried about whether the team can be completed, because once the delay is delayed, the customer will be disappointed and everyone will suffer.

4 .......

This article involves a lot of non-R & D department system issues. For example, setting a bonus mechanism for sales is difficult to implement and requires the cooperation of the company. from another perspective, the benefits are also obvious.

In addition to R & D management, I have also served as the department manager and deputy general manager of foreign companies in China, as well as non-R & D departments such as marketing, sales, and support. Although the cases in this Article refer to other companies, they have tried to use them while straighten out their own departments, and achieved remarkable results. In this process, we gradually realized that agile development is almost impossible if we cannot straighten out the relationship at the company level.

Readers may notice that the background color of the box in the image used in this article is different. In fact, they are divided into teams/customers (brown)-Planning Practice (blue)-tracking practice (purple) -Benefits (green)-There are several levels of goals (Golden), but there is no position for the creatures outside of the R & D environment such as "continuous integration" and "Moscow.

In the future, this series (or other series) will contain one or more"Agile Maturity ModelWill include them. This maturity model is not intended to be used for evaluation, but to find out what activities are not done by your team, what their purpose and value are, and whether they are difficult due to lack of them, in this way, you can determine what improvements can be made to your agile development.

 

Click to download the free agile development textbook: Martian agile development manual