Interpreting agile response changes over compliance plans

Traditional software development is waterfall-style, it advocates to set up plans, follow the plan, step by step implementation, part of the important output is a large number of complete documents.

But the Agile manifesto is clear: working software is more than detailed documentation! This is not to say that agile Chinese files are not important, but what are the documents in agile? Records only the resulting document.

What is this again? This has to do with the other words in the Agile Manifesto: Response changes are higher than follow the plan, together with the look!

The Agile team understands the user story, which is the feature of the team commitment in the iteration plan and the story splitting and work evaluation of the user story. Also, Scrum iterations stipulate that the sprint sprint does not interrupt or change the story of the team sprint.

However, most teams in progress quickly become small waterfalls in small iterations! How many stories the team was asked to complete in the planning meeting, most of which lacked preliminary research and collation, and the task split was not split according to the process (research, design, development, testing), Vertical splitting (page development, Logic Layer development, interface development), etc. The basic feeling is to complete these stories, to understand a big basic, many of the details are to be combed and organized in the iteration.

At this point, if you are facing the first question, how do you ensure that the committed user story is completed within the iteration?

If this is what you do: To make sure you're done, start planning schedules and milestones, and in order to start sorting out requirements before the iterations, ask for PRD, and specify in iterations not to easily change the iteration content, then you really turn agility into a little waterfall. You might say that the story is split to define boundaries and let us know what stories to do in the iteration. And the Burndown chart, which is to be developed according to the planned speed.

In doing so, you really understand the meaning of agility! What you do is really not agile!

Planning meetings is important, and we spend a lot of time on story evaluation and task splitting. What is the purpose, fast iteration! This is no problem, but there is also an important one, agile is fast response change higher than following change. Back to the root, why fast iterations, is because the demand changes too fast. It's going to change. You just finished evaluating a user story, and the next moment it changed. At this point, do you still have to cling to the rules of what iterations don't get broken or changed?

Team commitment and responsiveness to change. Because of this, software that works in agile is more than exhaustive documentation, and there are few process documents in agile, and any product or story is result-oriented. in the face of change, agility is responding to change, not tracking it.

The agile team's wiki has only the final result document, and is often completed after development. At this point, you may wonder, what is the point of the story evaluation and task splitting, and Burndown chart statistics? If the task of splitting a story doesn't have any guidance, is it necessary to split it?

To answer this question, we must say the team. In agile, the motivation and autonomy of the team is particularly important, as well as mutual trust . The black sheep must be removed from the team T.

How did the story go into the iteration? The story is after the product fine-grained division, according to the priority, by the team assessment and initial split task after the iteration. This is the planning meeting, its purpose is only one, Unified Vision ! All the rest is in order to help achieve the goal of the practice!

You ask, team commitment, response to change, how do we make sure that the team can do what's in the iteration? Is it possible to become demand and design at any time, always in a changing plan, without any documentation before completion, and how to ensure that the team can do it? Just a team commitment? That 's right! Just believe! If you are the leader, the only thing you can do is to believe in the team, to do is to protect the team!

It can also be said that agile is such a motivating team! Trust the team, let the team play a role in solving the problem, they can handle it! You don't have to interfere with them! So, that's why, in agile, leaders only need to focus on the idle tasks on the Kanban board, not the idle ones.

However, how do you do this, how to motivate the team, which we will continue to discuss in the future!

So, here's the answer to the previous question: planning meetings, story evaluations, task splits, stand-up meetings, retrospective meetings, presentation sessions, all for the team to serve efficiently!

However, you will also ask! What if the team doesn't implement the commitment? First of all, you have to see if the team really has no effort. If so, you'll want to see what the iteration's mission is all about, whether it's too many stories, too much interference, or what the problem is. If not, you should look at what's wrong with the team and how to motivate the team. And you can talk to the team on the Retro of the team.

In short, if the team does not work overtime every day, it is really a team commitment too much. In the face of this problem, it is to say that agile advocates work efficiency, rather than relying on time to pile up the false busy and overworked!

Let's review the origins of Scrum: Before the rugby sprint, the coach directs the deployment of tactics and plans, but once it starts, it is up to the team to improvise, to do their best to achieve the goal, and to constantly summarize every success and failure.

Use the last word to summarize: Agile lets the team do only the most valuable!

PS. When you decide to let the team do one thing, first think about it, will it really bring value to the team? Will the team really execute? If you can't make up your mind, let the team decide!

—————————— This article is published synchronously in ZHANGSR my personal blog ——————————

Interpreting agile response changes over compliance plans