When it comes to Internet product development, people immediately think of “fast iteration”, but the core point of this article is that “iteration” is not related to “fast” or even contradictory.
The classic iteration model might have released once every two weeks, but in our case, we released twice a week, and the iteration model didn’t work.
For a team in the middle of an iteration cycle, it would take nearly two weeks for new requirements to be planned for later iterations, and another two weeks for them to go live, which is too slow for an Internet team that needs a quick response.
What is often called “rapid iteration” is actually an artificial shortening of the iteration cycle. Many of the teams I’ve worked with have taken iteration as a reductionist, retaining only the meaning of periodic summaries, and even assuming that the team doesn’t need to iterate.
The so-called iteration
Iteration, broadly speaking, refers to the repetition of a particular process. Specific to the field of Internet product development, said is a project management model. Both Scrum and Little Waterfall, commonly used by Internet teams, are based on an iterative approach, in which the entire team repeats an artificial process over and over to achieve a goal in stages.
An iterative development cycle is typically set to two weeks, and the pattern looks something like this:
Why do we like to use iteration
Core advantages of iterative mode:
- Use fixed time Windows to coordinate resources
- Align development processes across the team to facilitate collaboration
If the testing, design and operation resources are shared by the whole business division or business group, the project manager must reserve the resources and “schedule” or even “PK”. At this time, a fixed development cycle is obviously more reliable.
The development process is aligned within iterations. The team first went into requirements review, then planned collectively, then launched development after planning, and released together at the end of the iteration. It is easier for team members at the same stage to communicate, easier for interrelated parts of modules to be taken care of, and for members to offset each other’s risks.
Disadvantages of the iterative model
Artificially limited time window does not meet the actual needs.Iterative patterns typically involve packaging and releasing a set of requirements within a fixed period:
(Schematic diagram of packaging and release of requirements on schedule – picture source)
The real development cycle of a requirement should only be related to objective needs and should not be limited by artificial time Windows. Too little time reduces quality; too much time reduces efficiency. Even leaving aside the risk of project change, the perfect packaging and window fit shown in the figure above is rare in reality. There is no need to bundle requirements together if they are not closely related.
The iterative model has high administrative costs. In order to get a on iteration planning, project members need to do a lot of forecast work, in the iteration to constantly Check the progress of the team, once have change to reorganize, not as expected delivery time will cut demand, will be postponed, if demand does not cut behind this is game between various meetings and unnecessary.
In iterative mode, a variety of measurement methods and change processes are usually used to ensure that the iteration can be delivered on time, but the cost can not be ignored, and the input-output ratio should be considered as a whole.
The iterative model does not cope well with change. As the iteration planning is at the beginning of a set, once change can produce all kinds of cost, so the whole team will tend to keep the original plan, the state of development both within the team or the external business environment is in a dynamic change, the iterative model of cost changes will affect the strain capacity of the team.
Overcommitment causes buffers to swell. The smooth progress of the entire iteration depends on too many assumptions. Due to the objective existence of project risks, many assumptions cannot be realized. It will be normal for the iteration to go poorly. If we focus too much on meeting expectations, then the participants who caused the delay will be blamed and everyone will have to leave enough Buffer for their work to deal with the risk.
My summary of the Buffer expansion law:
With the same level of requirements and risk, the higher the probability that the iteration will be delivered on time, the more buffers will be included in the cost assessment and the lower the overall team efficiency.
Go to the iterative
The publishing cost of Internet products is getting lower and lower, and the collaboration within the team is more flexible, and the organization structure tends to be net-like. The benefits of a fixed time frame and uniform development process have eroded and become a barrier to team responsiveness and development efficiency.
De-iterating includes, but is not limited to, the following transformations:
- Project management:
- No longer set artificial time cycle, everything is subject to actual needs
- Do not package unrelated requirements together
- Reduce unnecessary planning and measurement activities
- Focus on the actual development quality and flow efficiency of requirements, not on the degree of fulfillment of a given plan
- Team management:
- From pushing in groups to fighting separately
- From regular feedback to immediate feedback
- From periodic improvement to continuous improvement
- Product strategy:
Scenarios suitable for iterating:
- Business needs are relatively scattered and unstable
- Low distribution cost. For example, applications can be updated dynamically without requiring ground implementation.
- Low cost of resource coordination and adequate internal communication
- High quality personnel, able to independently promote the project
conclusion
If you’re in control, you’re not going fast.
The iterative model has its advantages, but it may not be the right fit for your team and business environment. A team should not assume that having a rigorous iterative process is a sign of good management. Management mode should evolve dynamically with objective conditions. Iterating is not about weakening management, but about upgrading management.
I believe that management ability is the basic resource of a team. Management upgrade promotes technology upgrade, technology upgrade promotes product upgrade, and product upgrade can adapt to the business competition under the background of consumption upgrade.
other
Not fast enough Sonic
Our team is in urgent need of senior front end engineers. Check out the position information here. You can send your resume online or directly to my email [email protected].