Agile development | The birth of troubles and how to solve them

Scrum agile development brings not only agile, but also unclear troubles.

Recently, the company carried out Scrum Agile Development, several Sprints down, encountered a lot of troubles.


For example, when encountering the situation of changing the interactive prototype, changing the visual design draft, and changing the code, because the Sprint Planning Meeting (cycle planning meeting), it is not considered that the interactive prototype diagram and the visual design need to be changed several times, and the bug needs to be repaired several times, so in this case, it is generally necessary to work overtime or put it to the next sprint to make a plan.

Another example: the work that could have been completed in 1 day needs to be planned for 2-3 days, because within a certain sprint, in a certain part of the project, there is really nothing to arrange. You can't always write on the plan: "1 day of work, 2 days of free activity." In addition, at the Daily Scrum Meeting (daily stand-up meeting), each team member is required to verbally say about their work progress yesterday and their work plan for today. At this time, some colleagues can only make up some irrelevant things, or divide the things that can be completed in 1 day into 2-3 days to report, because he has nothing to do in these days.


Another example: there is a temporary urgent matter, when you need to place an order, colleagues use Sprint Backlog (cycle work list) to refuse work. "There's no such task in this sprint plan." Therefore, the task that needed to be expedited was rejected. At this time, you have to put it on the next sprint to get it, or work overtime to do it yourself. In fact, originally only need to squeeze time in 1 day of working time, this urgent order, you can complete.


Let's first introduce the scrum agile development process, and then propose my personal improvement plan for these troubles.


What is Sprint?


Sprint means sprint, which refers to an iteration, and the cycle of an iteration is 1 month (that is, 4 weeks), that is, we have to complete the development content of an iteration at the fastest speed, this process we call Sprint.

How do I develop Scrum?

• We first need to identify a Product Backlog (a list of product requirements in order of preference), which is the responsibility of the Product Owner;
• Scrum Team estimates and arranges workloads based on the Product Backlog list;
• With the Product Backlog list, we need to select a Story as the goal of this iteration through the Sprint Planning Meeting, the time period of this goal is 1 to 4 weeks, and then refine the Story to form a Sprint Backlog;
• Sprint Backlog is done by scrum team, and each member is refined into smaller tasks according to sprint backlog (down to the amount of work for each task can be completed in 2 days);
• In the Scrum Team to complete the Sprint Backlog selected at the planning meeting, there is a daily Scrum Meeting (Daily Stand-up Meeting), each meeting is controlled at about 15 minutes, everyone must speak, and to report to all members in person what you did yesterday, and promise all members what you want to complete today, and at the same time encounter problems that cannot be solved, each person can go to the blackboard to update themselves after answering Sprint burn down (Sprint Burndown Chart);

do daily integration, that is, every day to have a version that can be successfully compiled and can be demonstrated; many people may not have used the automated daily integration, in fact, tfs has this function, it can support every time a member checks in, automatically get the latest version on the server, and then compile in the server, if it passes, then immediately execute the unit test code, if it is also all passed, then release the version, then a formal check-in operation is saved to tfs, if there is any failure in the middle, the project management will be notified by email;

• When a Story is completed, that is, the Sprint Backlog is completed, it means that a Sprint is completed, at this time, we have to conduct a Srpint Review Meeting (also known as a review meeting), which must be attended by the product owner and the customer (preferably the company boss), and each member of the Scrum Team must demonstrate to them the software product they have completed (this meeting is very important and must not be canceled);
• Finally, there's the Sprint Retrospective Meeting, also known as wrap-up sessions, which take turns speaking, where everyone speaks, summarizes and discusses improvements, and puts them into the next round of Sprint's product requirements.

in response to the troubles mentioned at the beginning of this article, i have summarized 3 targeted solutions here.

1. When planning the meeting, you need to reserve time for the interaction designer to change the prototype, the Ui designer to change the visual script, and the development engineer to fix the bug. For example, Ui designers, the average number of revisions, is about 3 times. The situation that can be finalized in one go is almost non-existent.

According to a "Survey on the Work Status of Shanghai Ui Designers" published by UIweek6 magazine released by [Ui China], the proportion of revisions required from the initial stage of the product to the launch of the product is generally 41%, 40% of the case of 1-3 revisions, 7-9 revisions, and 12% of the 10 revisions. In order to avoid the later requirements of Ui designers to change the design draft, Ui designers because of fear of overtime and do not change, or casually modify the situation of coping with things, I suggest that you need to plan the meeting, the time of modification, set aside the time for modification into the plan. In this way, Ui designers can be generous with changes.

2. When there is an emergency and needs to arrange an urgent task, it is generally dragged to the next Sprint. To avoid this, I recommend setting aside 2/10 of the time when planning sprint meetings as reserved time for temporary tasks. In this way, if there is a task that needs to be urgent, you can generously give time.

3. Regarding the selection of Sprint Star, in general, the priority of being selected is who works more overtime, who I have more contact with in this sprint, and who has a greater chance of being selected. This standard, I suggest changing to: who can complete this Sprint task, do more than the Sprint plan, try to choose who.

these are some of the annoyances and recommended solutions i have encountered recently during the implementation of agile development. in the specific implementation process, it is necessary to synthesize the advantages and disadvantages of these four development methods (waterfall development, iterative development, spiral development, and agile development) to apply them to specific projects. in this way, agile development can achieve the effect of learning from each other's strengths.