Image source: www.woshipm.com
I. Scrum Overview
Scrum comes from English rugby, a group of people pushing and shoving to grab and control the ball. It is indeed an image and appropriate metaphor to use the analogy of ball games. Although the players try to follow the established plan, the field changes rapidly, and it is impossible to follow the coach's or captain's instructions in real time. Instead, they can only act on the opportunity and achieve their goals by relying on the quality formed in regular training.
2. Core Ideas of Scrum
The core idea of Scrum is first to acknowledge that our customers (or users of our product services) are unaware of their requirements. Because human needs are constantly changing ("requirements churn": that is, the requirements are constantly churning), we default that requirements are changing requirements, and we need to develop a set of strategies to enable the entire group to develop quickly according to small functions and continue to iterate. The English meaning of Regression Scrum: make the development into a group of people working together to compete, and divide the functions into small pieces, that is, rapid development and iteration.
3. Practical Framework
Scrum defines only a high-level, very small set of practices for software development management that is easy to operate and follow. Scrum avoids the question of how software teams should develop software. It insists that when people encounter problems in their work, they should deal with them like mature adults, so it does not involve specific software development techniques and management skills such as people communication, expectation management, problem conflict, etc., which all require other related theories and skills to complement. In addition, as with other projects, the expertise of the software team in its business area is required to ensure the software project's success.
II. Scrum Values
- Commitment - Scrum is willing to commit to the goal
- Focus – put your mind and ability into the work you promised
- Open – Scrum opens everything in the project to everyone
- Respect – everyone has his unique background and experience
- Courage – Dare to make commitments, fulfill commitments, and accept respect from others
The above values and the Agile Manifesto are interconnected. Many people ignore these core values and ideas and pursue a set of development processes or frameworks for Scrum. But the process framework is just a specification, and not every team can directly apply it. We need to make certain adjustments when using it and even use it together with other development methods. There is no way to use Scrum flexibly without understanding agile development.
III. Scrum Roles
- Product Owner: They are primarily responsible for determining the product's functionality and meeting the required standards, specifying the release date and delivery of the software, and having the power to accept or reject the work of the development team.
- Scrum Master: They are mainly responsible for the smooth implementation and progress of the entire Scrum process in the project and removing communication barriers between customers and development so that customers can directly drive development.
- Development Team: They are mainly responsible for developing software products under the specified process of Scrum. The number of people is controlled at around 5-10. Each member may be responsible for different technical aspects, but each member must have strong self-management ability and certain expression ability; Members can work in any way as long as they can achieve Sprint's goals.
IV. Scrum Development Model
V. Scrum-Related Activities
1. Sort out the Product To-Do List
- Keep the product to-do list in order
- Remove or downgrade the seemingly unimportant items
- Add or promote emerging or more important items
- Break down the items into smaller items
- Combine the items into larger items
- Estimate the items (calculate person-hours according to the average level of the team)
2. Sprint Planning Meeting
In this meeting, the Scrum team works together to select and understand the work to be completed in the upcoming Sprint.
The number of product to-dos needed in Sprint is entirely up to the development team. To decide how much work to do, the development team needs to consider the current state of the product increment, the team's past work, the team's current productivity, and an ordered product to-do list. The decision on how much work to do can only be made by the development team. Neither the product owner nor anyone else can impose more workload on the development team.
Deciding how to get the job done is the development team's responsibility, and deciding what to do is the product owner's responsibility.
In summary: In a Sprint planning meeting, the development team and the product owner work together to consider and discuss product backlogs, make sure they understand them, select some of the things they predict can be accomplished, and create a plan that is detailed enough to ensure They can complete these items.
3. Daily Scrum Meeting
The Daily Scrum Meeting does not report to management, nor does it report to the Product Owner or ScrumMaster. It is a communication meeting within the development team to ensure they consistently understand the current situation.
Each meeting is controlled at about 15 minutes, everyone must speak, and you should report to all members what you completed yesterday, promise to all members what you will complete today, and also put forward problems that can not be solved. After everyone answers, they should go to the blackboard to update their Sprint burn down.
4. Sprint Review Meeting
All Scrum meetings are time-limited, and the recommended duration for Sprint Review Meetings is one hour of the Sprint Review Meeting if the Sprint contains one week (for example, if a Sprint contains 2 weeks, the Sprint Review Meeting is 2 hours).
The team finds its way to hold Sprint review meetings. They usually present product increments and the whole team often discusses what they have observed in Sprint and what new product ideas they have. They also discuss the completion status of the product to-do list, possible completion dates, and what can be accomplished by those dates.
5. Sprint Retrospective Meeting
At the end of each Sprint, the Scrum team gathers to hold a Sprint review meeting to review how the team has done in terms of process, interpersonal relationships, and tools. The team identifies what has been done well and what has not been done well, identifies potential improvements, and makes plans for future improvements. Scrum teams always improve their processes within the framework of Scrum. This sentence is very important.
VI. Requirements for Scrum Implementation
Scrum is very popular, but implementing it successfully and correctly and achieving certain results is not simply a command to do so. Especially for some traditional companies in China, or some companies with rigid organizational structures, internal transformation is not easy. Of course, it is not easy to realize Scrum in a flat management company, the quality of staff and the lack of experience of managers are the shortcomings of startups. Therefore, I have summarized several conditions that need to be met to achieve Scrum.
1. Understanding Notes
We should have a deep understanding of the core ideas and concepts of Scrum rather than focusing on the realization of its management process. We need to combine the theory of agile methods to understand why Scrum manages the development process in this way.
2. Adapter model
We should be familiar with the model proposed by Scrum and follow its standardized process, but the rules and regulations cannot limit us. We need relevant personnel to make appropriate adjustments according to the company or the team, as long as it conforms to the core idea. This requires people with certain wisdom, knowledge, and experience to understand the company's business and personnel quality and then think and summarize. Only in this way can we formulate a standardized development process and strictly implement this process. This process may even change the company's organizational structure.
3. Personnel Quality
The quality of team personnel is very important. It is the condition that determines whether Scrum can be effectively implemented. It includes self-management, technical ability, knowledge accumulation, principles of doing things, ideological wisdom, etc., and is a consideration of comprehensive quality. Regarding the requirements for the quality of personnel development, we can refer to some standards of extreme development XP to judge or cultivate high-quality developers.
4. Valid Agreement
We should agree on a unified communication method to improve communication efficiency. We agreed on unified version control and code management modes and introduced a unified assistance tool to help smooth process execution and improve processing efficiency. If necessary, other agile development methods can be introduced and used together.