SCRUM framework and self-organizing team

SCRUM framework

The 3 roles, 3 artifacts, 5 events, and 5 values ​​of the Scrum framework:

3 characters

• Product Owner:
• Scrum Master
• development team

3 artifacts

• Product Backlog (Product Backlog)
• SprintBacklog
• Product increment (Increment)

5 events

• Sprint (Sprint itself is an event, including the following 4 events)
• Sprint Planning Meeting (Sprint Planning Meeting)
• Daily Scrum Meeting
• Sprint Review Meeting (Sprint Review Meeting)
• Sprint Retrospective Meeting

5 values

• Commitment-willing to make a commitment to the goal
• Concentration-use your mind and ability to the work you promised
• Open-Scrum makes everything in the project open to everyone
• Respect-everyone has his unique background and experience
• Courage-have the courage to make promises, fulfill promises, and accept respect from others

SCRUM theoretical basis

Scrum is a process based on empirical process control theory (empiricalism). Empiricism claims that knowledge is derived from experience and that decisions are made based on what is known. Scrum uses an iterative and incremental approach to optimize predictability and control risks.

The three pillars of Scrum

The three pillars of Scrum support the realization of each empirical process control: transparency, inspection and adaptation. The three pillars are as follows:

First: Transparency

Transparency refers to maintaining a high degree of visibility in all aspects of the software development process, and all aspects that affect the delivery results are transparent to everyone involved in the delivery and those who manage the results. People who manage production results must not only be able to see these aspects of the process, but they must also understand what they see. In other words, when someone is testing a process and is sure that a certain task has been completed, the completion must be equivalent to their definition of completion.

Second: Inspection

All aspects of the development process must be checked frequently enough to ensure that major deviations in the process can be detected in time. When determining the frequency of inspection, it is necessary to consider that the inspection will cause changes in all processes. When the specified inspection frequency exceeds the tolerance level of the process inspection, then problems will arise. Fortunately, this is not the case for software development. Another factor is the skill level and enthusiasm of the personnel checking the work results.

Third: Adaptation

If the inspector finds that one or more aspects of the process do not meet the acceptance criteria during the inspection, and the final product is unqualified, then the process or materials need to be adjusted. Adjustments must be implemented as soon as possible to reduce further deviations.

In Scrum, inspection and adaptation are carried out through three activities: daily regular meetings check the progress of the Sprint goal and make adjustments to optimize the value of the next day's work; Sprint review and planning meetings examine the progress of the release goal and make adjustments to optimize the next day. The value of a Sprint's work; Sprint retrospective meetings are used to review the completed Sprint and determine what improvements can be made to make the next Sprint more efficient, more satisfying, and happier.

Self-organizing team

• The team led by the manager only authorizes the team members to perform tasks, while the manager monitors and manages the work flow, plans the environment and sets the direction. In our view, many expert groups and traditional project management "teams" in functional silos are examples of such organizations.
• A self-managing team allows members not only to be responsible for the execution of tasks, but also to manage their own processes. In the IT industry, we have seen many Kanban teams apply this method to focus on team tasks or communicate value streams;
• Self-planning teams , empower members to plan the team and (or) the organizational environment related to their operations. Most real management teams and some Scrum teams (especially when Lean or Agile are scalable) are at this level.
• Self-governing teams , company boards, partners, or start-ups are responsible for all four core functions as shown in the figure.

Self-organizing teams work differently from command and control teams because they have different values. To understand self-organization, you must first understand how these values ​​fit into the actual things in your project:

• Everyone is committed to the goals of the project.
  This level of commitment can be achieved when the team has the authority to make decisions to achieve these goals, and everyone has a say in how the project is planned and executed. For example, sometimes the requirements document is not perfect. In order for the project to succeed, the team may have to ignore the recorded requirements in order to provide a more valuable product. This is only possible after they have the right to make a decision.
  Team members respect each other. When team members respect each other, they can trust each other to complete the work they do. But for programmers and other technical personnel, this kind of respect is not always easy. Many programmers, especially highly skilled programmers, are often based purely on technical capabilities. This may be an obstacle to effective Scrum adoption. If the programmer does not respect the product owner, he will not listen to the product owner when he talks about the project goals.
• Everyone is focused on work.
  When a Scrum team member is doing sprint work, this is his only job during the sprint. He is free to complete any work required for the iteration backlog and deal with any changes made to the backlog during the sprint. When each team member is focused on sprint goals and is free to complete any work required to achieve those goals, the entire team can organize itself and easily redirect when changes are needed.
• Openness.
  When you work on a Scrum team, others on the team should always understand what you are doing and how to push the project toward its current goals. Many Scrum practices are designed to encourage openness among team members. For example, the task board allows everyone to see all the work that each team member is doing and how much work is left to do. Burning charts allows everyone to measure how quickly the sprint reaches the iteration goal. Daily Scrum, if done effectively, is almost a pure exercise in terms of openness, because everyone demonstrates their tasks, challenges and the progress of the entire team. All of these can help the team create an atmosphere of mutual support and encouragement.
• Team members have the courage to stand up and participate in the project.
  When you choose to be open rather than opaque, you will make the team stronger instead of strengthening yourself at the expense of the team. It takes courage to do this, but when you do this, you will get a better product and a better working environment. The Scrum team has the courage to live by values ​​and principles that benefit the project. It takes courage to avoid a company's values ​​from conflicting with Scrum and Agile values. This requires every team member, especially the Scrum Master, to be vigilant. But it also requires everyone to be willing to believe that providing valuable software will help them overcome resistance to these values. It also requires courage, especially when sitting down with the boss to conduct a review. To myself, it takes courage,

Define a custom team

A group of motivated people who work together to achieve goals, have the ability and power to make decisions and adapt to changing needs at any time. Let's look at some important factors of self-organizing teams:

• They pull work for themselves and don't wait for their leader to assign work. This ensures a greater sense of ownership and commitment.
• They manage their work as a whole (allocation, reallocation, estimation, reassessment, delivery and rework).
• They still need coaching and guidance, but they don't need "command and control."
• They communicate more with each other, and their commitment is more the project team than the ScrumMaster.
• They understand the requirements and are not afraid to ask questions to clarify their concerns.
• They continue to improve their skills and recommend innovative ideas and improvements.

Five elements of a self-organizing team

• Ability: The individual needs to be competent for the job at hand. This will give them confidence in their work without the need for guidance from above.
• Collaboration: They should work as a team, not as a group of people. Encourage teamwork.
• Motivation: Team motivation is the key to success. Team members should be focused and interested in their work.
• Trust and respect: team members trust and respect each other. They believe in collective code ownership and are ready to redouble their efforts to help each other solve their problems.
• Continuity: The team should be together for a reasonable duration; changing its composition occasionally does not help. Continuity is essential to the team.

Create a self-organizing team

Who is responsible for forming the self-organizing team? Is it the ScrumMaster who also focuses on timetables and delivery; or is it a senior manager who serves as a financial officer; or is it the organization itself that has a greater challenge to thinking?

In fact, the joint efforts of all three entities are needed to help the team become self-organized. The ScrumMaster should act as a coach and ensure that the team receives training and guidance for a specific job. He or she is mainly responsible for ensuring a cohesive and soothing working environment, which is a necessary condition for the prosperous development of self-organizing teams. It is very important to coach individual team members so that they can understand the principles of self-organizing teams and trust each other. ScrumMaster should also consider various methods to improve collaboration within distributed teams (using application lifecycle management tools, video conferencing, etc.).

Senior management should ensure that it does not interfere with the work of the team; they need to act as support rather than distraction. Team goals should be set and individual heroism should not be encouraged-it is only a hindrance to self-organizing teams. It is vital that team members fail before the expected delivery.

The entire organization should ensure that it provides the necessary infrastructure, training and incentive systems to keep employees motivated. Before you expect your team members to organize themselves, these are hygiene factors and constitute the first cross-cutting obstacle.

A three-step process: training, coaching, coaching

Creating a self-organizing team can be considered a three-step process.

• The first step: We need to train employees to acquire the required skills. At the end of this phase, you can assume that the team has the ability to demonstrate self-organizing behavior. Provide any required classroom and on-the-job training to enable each employee to be competent in a specific field/technology. Behavior training is also very helpful.

• Step 2: Once the team starts to work together, use coaching to see if the members face any difficulties. They may need more support and guidance from the beginning. As mentioned earlier, some indicators of self-organizing teams are: Scrum rituals are fruitful, the team likes to work, members help each other, new ideas are coming, and the team is pulling work for itself. By the end of this phase, you know that the team is self-organizing. However, please keep your eyes open to observe the team’s behavior and provide needs-based guidance. This stage will bring the team's innovative ideas and improvement results.

• Step 3: Once the team is in self-organizing mode, the key is to maintain this for a long time. Assign a mentor who can help the team move to the next level. Job rotation can be an important aspect of involving employees and encouraging continuous learning. As mentioned earlier, self-organizing teams do not need "command and control", but they do need coaching and guidance.

Teams are not static; they will change over time. Building a self-organizing team is an ongoing process that we really have never completed. Whenever the composition of the team changes, we need to repeat the entire process.

refers:
https://www.scrumcn.com/agile/scrum_guide.html
https://cloud.tencent.com/developer/article/1370521