Generally speaking, Agile refers to Agile software development or Agile development. It is a kind of new software development method that has gradually attracted wide attention since the 1990s, and it is a kind of software development ability to cope with the rapidly changing needs.
When it comes to agile, we have to mention the Agile Manifesto. So what is the Agile Manifesto?
One of the basic skills of project managers is to keep minutes of meetings. In fact, the Agile Manifesto was the minutes of a very important meeting held by 17 “heavyweight” experts and scholars who supported lightweight development methods in Snowbird, Utah in 2001.
Agile Manifesto is simple and straightforward, and it is very easy to understand. I especially remind everyone that the Agile Manifesto is 5 sentences instead of 4 sentences. The last sentence is very important: While there is value in the items on the right, we value the items on the left more.
Why emphasize it? Because we often encounter misunderstandings about Agile. The classic is that they implement Agile, but they don’t create documents. How can this work? Agile does not mean not to create documents. We think documents are very important, but available software is more important. So we focus more on available software in our work, rather than requiring all content to be archived.
We only create valuable documents or try our best to combine your documents with actual code (through comments or similar to Java Doc) to make the documents effective and helpful for understanding the working principles of the software. Try to avoid detailed design documents with more than 40 pages of double-sided printing. Even if the actual code implementation does not match the document, the detailed design document will never be updated. The meaning of the document that took a lot of time to write is greatly reduced.
The last thing I want to say about agile is that although there has been an Agile upsurge in China since 2010, it seems that you are embarrassed to say hello to others if you don’t implement Agile. In fact, Agile is not a particularly new concept. XP [extreme programming] and Scrum are products of the beginning of this century, and DSDM (dynamic system development method) is the working method used by NASA in the mid-1970s.
First of all, let’s explore what the word “Scrum” means?
This is actually a proper term from sports. As shown in the picture below, the scene of football “side-by-side faceoff” is called Scrum.
Later, this word was borrowed by the inventor of Scrum and became the name of a well-known Agile development framework. Scrum is also one of the Agile methods widely recognized and used. You can see that in Scrum, everyone stands shoulder to shoulder, hand in hand, and advances and retreats together, which also reflects the spiritual connotation of Scrum “One Team”.
As mentioned above, Scrum is very simple. How simple is it? It’s so simple that it can be covered with one page of PPT. At the same time, it can be summarized with the three numbers of 143. Even if you don’t know anything about scrum, after reading today’s article, you can introduce Scrum to others.
A flow chart
All the Scrum activities are in this flow chart. Let’s explain briefly.
From the far left, when we start a Scrum Sprint (sprint, which can be simply understood as the smallest grain project in Scrum), we need to add the Sprint Backlog (requirements, the left side of the figure is like a brick, which means to start to “move brick”) is divided into technical tasks that can be performed (Task, something like a wooden floor), and the scope of the Sprint is defined.
The 30 days written in the middle of the big circle in the chart means that the recommended time for each scrum Sprint is 2-4 weeks.
Deliver incremental releasable software after the Sprint is over (the brick-like thing on the right, which means “the bricks are moved”)
What’s the big circle and the small circle for? In the process of the sprint, the project team will carry out daily meeting to synchronize and communicate the project status.
A minimal scrum sprint and all the processes are like this. Simple, right?
1. Planning Game: That is the part of the “how brick change into the wood floor” on the left in the picture above.
Note: There are other different names too, I personally like this name better. Why is it called Game? I will give you a detailed explanation later because there are some very interesting working methods in this link.
2. Standup Meeting: It is the position of the small circle in the flow chart, which is held every day at intervals of 24 hours.
3. Demo Meeting: Before we release the software, we need to demonstrate what functions the sprint team outputs, and then we can launch it online. That is the part of the flow chart where the bricks are removed.
4. Retrospective Meeting: Usually we also call it Retro for short. Generally, review and summary are conducted after a Sprint.
There are only three roles in the scrum, which constitute a scrum team.
PO：Product Owner. As the name suggests, the owner of a product can be understood as a product manager
Team: R & D team, including R & D, testing, UI, and other roles related to software delivery
Scrum Master: Agile coach, a role invented by scrum, can be understood as a project manager
Note: The PO and Scrum Master in Scrum are strictly different from product managers and project managers. In order to help people who don’t know Scrum at all, here is a brief analogy.
That is what does “134” means. Scrum is about this.
Next, I will start with the following four activities to explain how they should be carried out step by step. Finally, I will talk about how the responsibilities of the three roles in Scrum should be divided and cooperated.
Some people may ask, is there something wrong with your arrangement? Why don’t you introduce the division of roles first, so that we can have a better understanding of what each role should do in different activities?
This is what I intend to do. As mentioned above, Scrum is a work mode that emphasizes the spirit of “one team” so any role has the responsibility to implement scrum activities well.
That may be a little puzzling. For example, someone often asks me, “whose responsibility is it that we can’t plan meetings well?” Usually, I would say, “it’s the responsibility of the whole team.” Then I would say: “because the output of the PO in this activity is more important, the team should help Po improve the quality of output and hold the planning meeting well.”
Therefore, regardless of the specific role in the real work, please stand in the perspective of the entire scrum team to understand how each activity should be carried out. Let’s learn Scrum in more detail!