In the current IT Industry, the concept of Agile has become quite popular. Everyone is talking. Almost all IT companies have adopted some level of agile.
There are also many methods under the umbrella of agile development, including Extreme Programming (XP), Scrum, Crystal Methods, Adaptive Software Development (ASD), Feature Driven Development (FDD), Dynamic System Development (DSDM), and lightweight. RUP, Test Driven Development (TDD), and more. Among the many agile development methods, the implementation of Scrum is more popular.
Agile or Waterfall? See the Figures
The most recent report from the Standish Group covered projects they studied between 2013 to 2017. For this time period, the overall breakout of success, challenged and failure is shown below for agile and waterfall, with Agile projects being roughly 2X more likely to succeed, and 1/3 less likely to fail.
(Source: vitalitychicago.com — Comparing Waterfall and Agile Project Success Rates)
This article mainly shares the understanding of Scrum, the implementation process of Scrum and the changes brought by the implementation of Scrum, and explains what a running Scrum is.
What is Scrum?
Scrum is a framework for developing and maintaining complex products and is an incremental, iterative development process. In this framework, the entire development process consists of several short iteration cycles, a short iteration cycle called a Sprint, and each Sprint is 2 to 4 weeks long.
In Scrum, use the product Backlog to manage the product’s needs. The product backlog is sorted according to the priority of the implementation, with commercial value as the main principle of sorting. In the Sprint, the Scrum team selected the highest priority requirements from the product Backlog for development. The selected requirements are discussed, analyzed, and estimated at the Sprint Planning Meeting to get a list of tasks called Sprint backlog. When the Scrum team completes all the tasks in the Sprint backlog list, the Sprint ends and proceeds to the next Sprint iteration cycle.
Why Scrum Failed in Some Companies
Scrum has great value. However, it is difficult to implement Scrum in some companies. Some people say that Scrum has no substantive effect in their organization. Why is they have such a result? The main reasons could be:
- Agile is faster — The project team lacks a correct understanding of agile. It simply thinks that agility is fast, that is, catching up with progress, and it can be free from any system constraints.
- Agile is faster, or we need to work overtime — I have heard that some companies have to develop a new function. Because of the implementation of scrum, the project team is required to work overtime, and the development tasks of 2 weeks or more will be released within one week. Implementing Scrum means that the project team is working overtime, which leads to a “fear” in the project team’s agility;
- Product Backlog doesn’t well maintained — PO can’t be qualified for work, can’t split effective user stories, or the user’s story split is unreasonable, can’t realize incremental generation development;
- Team Formation problem — Scrum has a high demand for self-organizing teams, but many team members feel that they are not up to the standards of self-organization;
- Lack of Agile culture — Scrum advocates the transparency of the work, the real-time completion of the project and the task recognition of each person. The Sprint Board and the project burndown chart are unobstructed, and many people are not comfortable with it;
- Inspect and Adaptation not in place — In the process of iteration, the problem cannot be discovered in time, or the problem is found, and the problem cannot be solved effectively, which makes the project team feel frustrated. and many more.
If the knowledge of Scrum is only stuck in:
“I have an idea in the morning, it will be realized in the afternoon, and it will be online at night.”
It is inappropriate. In my opinion, Scrum is definitely valuable. The main functions of Scrum include:
- Scrum can ensure to prioritize development of product backlog that has high value to customers and better meet users’needs.
- Compared with the development method under the waterfall process, by implementing Scrum, the team can double the development efficiency and maximize the role of the team;
- Scrum can shorten development cycles and increase project delivery efficiency.
However, implementing Scrum does not mean that it is not subject to rules and project constraints. So what is the correct posture to implement Scrum?
Steps for Implementing Scrum
1. Assign a PO
PO is the Product owner, which is a role, and PO is the sole owner of the management product to-do list. Of course, in some companies the PO has already exist as an organization — for example, our company has implemented PO as an organization in the implementation of Scrum.
As an owner, it must have a big picture; deeply understand the industry information and direction; be able to grasp the direction of the product, take charge of the short-term and medium and long-term planning and management of the product; be able to conduct user research and product function planning according to the company’s strategic requirements, tracking the ever-changing needs, and continue to innovate products.
In addition, if you use PO as an organization, in a software development project, the PO team may other stakeholders include members such as product managers, end users.
2. Form a Development Team
The team is the implementer of the product and is responsible for delivering potential Shippable Increment and “completed” product increments at the end of each Sprint.
The team mainly includes development and test personnel, and the team must be able to implement the PO’s vision of the product.
The size of the team should around 5 to 9 people.
Scrum team should also be cross functional and members with the “full stack” capability is more preferable, even through it may be difficult to implement in most companies.
3. Select Scrum Master
The Scrum Master is responsible for the Scrum process and serves the PO and development team. The Scrum Master must have a sense of ritual, and can effectively and efficiently organize the iterative plan meeting, daily standing meeting, function demonstration meeting, and the retrospective review meeting; the Scrum Master must have a high degree of execution and maintain credibility to help the team. Focus on delivery goals and quality objectives to ensure teams deliver high quality products efficiently; drive teams to build efficient processes, guide teams on agile values, principles and agile practices; be responsible for training other members of the team to ensure that Scrum is used correctly; Communication, problem management, conflict resolution, help the team eliminate all obstacles.
4. Maintain product Backlog
The Product Backlog is a collection of all backlog items, and is based on the company’s strategy and product vision. PO sorts all items in the product backlog according to the priority order according to business values, and forms a prioritized item list. The product backlog can be served as to the “road map” of product development. To understand the product context, the product backlog items are the best reference.
Every day we face new demands from new competitors, which means that PO must continually optimize its product design and adjust the priorities of the product backlog to cope with the new changes.
In this process, the PO should consult with all stakeholders and teams to ensure that product backlogs reflect the user’s true claims.
5. Agile Estimation using Story Point
Relatively agile estimation is typically performed at the sprint planning or touch up during a sprint and the product backlog is evaluated by the team together with the responsible for the actual development and testing work.
In order to conduct the sprint planing more efficient in practice, the PO and Scrum Master will make a rough estimation before the sprint planning meeting. They need to ask these sort of questions such as:
- See if the sprint plan is feasible?
- Is there enough information to complete these matters?
- Is the product backlog item split reasonable?
When the development team conducts an estimation, it is recommended to abandon the traditional method (i.e. how many hour to be assigned to the task) and use agile estimation approach by using the story point – the Fibonacci number (1, 2, 3, 5, 8, 13, 21…) Form to evaluate the effort required for the implementation of an item.
At the time of the estimation, the team needs to first identify an backlog item which might be in user story form as a reference for the estimation. In addition, it is important to note that when the single story point of the assessment is greater than 21, the user story needs to be split again, and the single user story point is no more than 8 is the ideal state.
6. Sprint planning meeting
This is the first real Scrum meeting. Team, Scrum Master, and PO sit together to plan the content of the sprint. As a software development project, entering the user story of the planning sprint, the user story should have been split and the visual design completed.
The sprint cycle is generally fixed, mostly for 2 to 4 weeks. The team starts with the user story with the highest priority in the product to-do list to see how much can be done in a sprint.
If the team has already carried out multiple sprints, by reference to:
- The “story points” completed in the previous iterations,
- The team may estimate the approximate story points for this iteration.
- “Story points” is equivalent to the speed of the team.
Scrum Master and Team should strive to increase this number in every sprint iteration.
All team members should form a consensus on the goal of a sprint, that is, what needs to be accomplished in a sprint iteration. At the sprint planning meeting, PO needs to tell Team the priority order of user story implementation. Team promises how many stories they will be able to complete in the next sprint iteration. In the process of sprint, no one can unilaterally change the sprint content without authorization.
7. Daily Stand-up Meeting
Daily Stand-up is the source of vitality for Scrum. The participants generally include PO, Scrum Master, and team. The team communicates internally at a fixed location and at a fixed time each day. The time is usually morning, the duration is no more than 15 minutes, and standing. The Scrum Master asks the team members the following questions:
- What did you do yesterday?
- What work do you plan to do today?
- What are impediments and obstacles?
The significance of this is to let the entire team know clearly the progress of each task during this sprint cycle, and whether all tasks can be completed on time.
Team’s tasks are not assigned from the top down, but are decided on their own initiative and voluntarily. If the previous task is not completed, you cannot apply for the next task, and you cannot claim two tasks that cannot be completed on the same day.
The Scrum Master is responsible for eliminating the obstacles faced by the team members.
8. Track Project Progress with Scrum Task Board
In Scrum, work must be transparent, and the most common practice is to implement a Scrum Task board.
Some teams are good at using third-party tools to use electronic Scrum board, such as Visual Paradigm or Jira; some teams are happy to use large offline physical White boards.
Regardless of whether you use an electronic Scrum board or a physical whiteboard, the Kanban’s columns typically include three parts: the to-do list, the ongoing items, and the completed items. As the progress of the iteration progresses, the team will promptly update the matter to the corresponding Scrum Kanban column every day.
9. Tracking progress with burn-out charts
Another tool for making work transparent is the burn-out chart. In the figure below, one axis represents workload, and the other represents time. Every day Scrum Master records the remaining points to be completed and then draws them on the burnout chart. Ideally, the graph is a downward curve, burning out to zero as the rest of the work is completed.
10. Product Demonstration
The demonstration section of the Scrum Guide is called the Sprint Review Meeting, which states that the it should include demonstrate the work done by the development team to and answer questions about the product increment. The meeting is usually held before the release of this iteration. The most important work of this meeting is to verify the implementation scenarios of user stories with accepting evaluations with each of the completed item to fulfill the definition of done.
This meeting is where anyone can be a participant, not only PO, Scrum Master and team, but also stakeholders, business and managers, and even customers.
This is an open meeting where anyone can be a participant, not only PO, Scrum Master and team, but also stakeholders, business and managers, and even customers.
Teams should show only those items that meet the definition of done, that is, the results that can be delivered without having to do any more work. This result may not be a complete product, but at least it is a complete and usable feature to the end user.
11. Sprint Retrospective
The sprint retrospective meeting is usually held on the second day after the end of this Sprint.
The sprint retrospective meeting should carefully review the following questions:
- What has happened to be improved;
- Why did it happen?
- Why did we ignore it at the time;
- How can we speed up the work.
As a team, to make this sprint retrospective process effective, the team needs to trust each other. We must remember the discussion and arguments based on project and technical issues:
- There is no absolute right, wrong and worry,
- Encourage technical collisions;
- Can not involve discussions on personal attacks;
- Resist people with wearing colored glasses to see people,
- Guide everyone to rational discuss;
- Courageously accept the challenges of others,
- Accept their own imperfections.
- Responsible for their own processes and results,
- brainstorm and seek solutions to problems. This is crucial.
Finally, the team identifies one of the most worthwhile improvements and sets it as the top priority for the next sprint. You need to define what is “successful” in a concrete and actionable way so that you can quickly determine if the improvements have been made in the next sprint review meeting.
After the last sprint is over, begin to enter the new sprint iteration.
Summary
Scrum is a combination of 3355. The core concepts of scrum framework can be simply memorized it as 3.3.5.5 as follows:
3 roles
- Product Owner
- Development Team
- Scrum Master
3 Artifacts
- Product Backlog
- Sprint Backlog — Sprint To-Do List
- Product Increment — Potential Shippable Product Increment
5 events
- Sprint
- Sprint Planning Meeting
- Daily Scrum Meeting
- Sprint Review Meeting
- Sprint Retrospective Meeting
5 values
- Open
- Respect
- Courage
- Focus
- Commitment
The goals of 3355 is behind the three Scrum Pillars
- Transparent
- Inspection
- Adaptation
The Definition of “Done” (DoD) is achieved by fulfilling the 3 pillars through the means of 5 events of the Scrum team.
English
简体中文
繁體中文
Deutsch
Español
Français
Italiano
Português
日本語
Nederlands
فارسی
Русский