8 scrum principles

In the history of the World Cup, this team was the most successful and won six victories. In a speech by Marc Lammers, head coach of the Dutch women's volleyball team, I realized why this team achieved such remarkable achievements. Their success is largely attributed to coach Marc's teaching method. Marc Lammers discovered the secret to releasing all the energy from the team. Everyone not only works together as a whole, but also as a part of the team; all of these were born in unexpected ways. I did get a lot of inspiration. This article summarizes the principles he discovered and describes how these principles are applied to software development.

As a scrum master, I find that the principles I reveal can be found in my ownScrum team. The reason is that these principles apply in essence to any team, whether they are assembling cars, playing hockey, or developing software. In this article, I would like to share some tips and experiences from Marc Lammers in the workshop and explain how to use this knowledge in daily scrum and project practices. Maybe you won't be able to win the World Cup even if you have them, but if you don't pay attention to them, what the team does may surprise you and your customers.

Principle 1:
Leverage the power of effective communication

Marc Lammers mentioned:

In the early days of my coaching career, I spent a lot of time and energy letting everyone understand what I did. Therefore, I will explain my brilliant coaching philosophy to my team in a long speech. To ensure that everyone can receive the transmitted information, I will ask, 'Do you understand? 'I am satisfied with everyone's nod. However, the performance during the competition proved that they did not understand it at all.

They didn't seem to have heard of me. So I began to use a more intense approach-to reprimand. Unfortunately, this does not work at all. I told my own coach that together with these incompetent deaf people, there will be no achievements. He said it was all my fault. He showed me the results of the Communication Research and found that what a person can remember:

• Remember 10% of what you hear.
• Remember 35% for what you see
• Remember 55% for what you hear and see at the same time
• Remember what you re-Express: 70%
• Remember 90% of what you re-Express and do it manually.

This makes me suddenly realize. I started to use open questions so that they could repeat my strategy and create a space for interaction and interaction. In this way, they can not only gain a deeper understanding of my thoughts, but also begin to understand and benefit from their consideration. Since then, I have finally been able to fully implement the competition in the competition.

As for scrum, I can use this principle in various fields of exchange or information. It is applicable to design discussions, communicating requirements with developers or business personnel, explaining development processes to business personnel or new team members, or other scenarios you think. In these cases, the use of open questions, conversational style communication, re-description and other communication methods can greatly improve mutual consensus; these methods force all participants to discover what they really understand or think. As a result, the relationship between mutual trust and mutual respect is, in my opinion, the most important factor for productivity improvement.

In fact, I have already discovered these rules in my daily scrum practice. However, it is very precious to know the many benefits of efficient communication.

Principle 2:
Different results can be produced only when the ways of doing things are different.

The above communication story also contains another important principle. Marc Lammers knew that his communication method was ineffective at the beginning. He first adopted a more rigorous method, but did not reflect on what he was doing. I think this is due to human nature. If we don't get the expected results, we will think it is because of insufficient strength. Therefore, we will work for a longer period of time, talk in a more rigorous manner, invest more energy, work hard on weekends, and so on. In most cases, we cannot make progress, just as Marc has been verified. When he looked at the problem in a completely different way, he achieved the expected result.

This principle applies to many occasions. Think about how scrum advances estimation. Previously, we used Function Points estimation, which is irrelevant to the delivery capability of a specific team. SCRUM will estimate the number of points based on the development speed of experienced teams and the degree of development of stories, the accuracy is remarkable. Therefore, scrum does not modify function points to make them perfect, but adopts a completely different approach, with remarkable results in simplicity and accuracy.

This principle is often misused. There is a typical example where people are often asked to work overtime when the deadline is approaching, even though the current manpower is obviously unable to complete before the deadline. By the way, it may be necessary to do so. In fact, it has been confirmed that it is only for the treatment of symptoms. In the long term, it is meaningless. It will not only cause serious harm to the team spirit and the health of team members, but also affect the quality of software. The bug rate will increase, and more effort will be spent on fixing the introduced bugs. Working overtime can only make things worse.

To solve this problem, scrum provides a better way to use the emergency handling process. In essence, it is a specific application method that utilizes the aforementioned principles. If the deadline cannot be met, and the situation is obvious, scrum's emergency handling process recommends that you consider the following actions: first, hold a review meeting to stimulate productivity and see which major obstacles can be removed. Second, if Step 1 is implemented without significant productivity improvement, consider which specific tasks can be outsourced to experts. This expert will not become a member of the team. The problems he solves should be relatively isolated, and the team does not have the professional skills to solve these problems. Third, if there is no such task, try to redefine the scope. Finally, if the customer does not agree to re-define the scope, the current sprint must be terminated.

In general, having the courage to fundamentally consider changing the current way of doing things is the only structured solution in the long-term operation of the Organization. To do this, even if the road is full of difficulties and obstacles, the chance to achieve the expected goal will be greatly improved, because the team will no longer be sent to the death journey.

Principle 3:
Innovation is an excellent way to get better results, but it is not an aim;
Also, be careful with side effects.

Marc Lammers said:

I am always looking for innovative methods. During the Olympic Games, I really wanted to instruct them how to play a small game, but I found it hard to see the key points of the game outside the venue. We used to analyze video clips after the game, but it was too late for me. I want to do this in real time.

I was inspired by the video course. I had to connect a TV camera to a long line and connect it to my notebook several times. You can see several small windows on the laptop screen, from which you can see the camera captured in real time. Later, I tried to contact some engineers to test the first prototype system in a few months. Since then, I have been able to provide more detailed guidance to the team members.

To innovate, I have three key points to tell you:

1. Innovation must serve the purpose. For many times, I want to innovate for innovation without any improvement. Innovation must be able to solve a practical problem.
2. Every innovation is accompanied by the troubles of growth. Don't expect it to win in the first battle. Continue debugging and optimization until it brings you the competitive advantage you want.
3. Innovation will lead to resistance. Some people are always afraid of new things. This fact has two meanings: first, when you encounter conflict, you may have found a true innovation method, so be proud of yourself. Second, find a way to cope with the conflict. Do not expect others to like your novel ideas, and give them time to accept and get used to your ideas.

I firmly believe that many projects will succeed if we carefully consider these simple wisdom when developing software. It taught me:

• Target: In my experience, there is an obvious situation in the use of tools: Many usage do not consider the intention. Many projects I have seen are tool-centric, not result-oriented. People are always thinking about how to use tools effectively, rather than how to deliver better software. This is why "no complex tools are available at the beginning" is so successful in practice. The use of whiteboards and instant stickers is often more effective than the use of a series of complex tools, because it forces the team to interact, and focus on the problem.
• Follow pains: Changes to the project environment can easily cause pain points. New members, the use of new technologies, and the start of new processes are all so optimistic at the beginning. Knowing that "pain points" are the inevitable outcome of changes can make us look forward to the future more practically, rather than being too optimistic.
• Conflict of concern: For example, introducing agile development practices such as scrum to an organization usually results in resistance. Marc's story reminds me of the existence of such a reaction and helps me find a way to deal with it, instead of having to rush to conclusions and fight with it. When introducing new things, it is more effective to give patience and attention to those who are in conflict.

Principle 4:
Constantly challenging work methods

Marc Lammers said:

Our training includes many 30-meter sprints. The team always has to repeat this exercise because the 30-meter sprint exercise has been well known for many years. Later, I want to analyze the running mode in the competition. To do this, we provide GPS for each player in some training courses. Analyze the data. On average, the number of sprints of a player in the 15-Meter Model exceeds the number of Sprints in the 30-meter model. In view of this, we can make the training program more practical. Another small improvement was born.

This story tells me two things:

1. Constantly ask yourself why you are doing what you are doing. Is it because "always" is used to complete an activity? Or does this activity really add value to the whole? What value does it bring? What does it have to do with the work that must be done?
2. If you cannot give a satisfactory answer to the above question, start to collect data and measure the effect. You can only know what is going on. Measurement allows us to evaluate the effectiveness of countermeasures and adjustments to see if they have any effect. The measurement can be very simple, for example, "stop an activity and see what will happen ".

In my experience, a lot of time is wasted every day, because we take the current way of work for granted and do not doubt its quality. Repeating a task repeatedly makes it look reasonable, even if it does not add any value. From the perspective of improving efficiency, it is very effective to question the existing working methods by measuring changes.

Principle 5:
Focus on people's strengths rather than weaknesses

Marc Lammers said:

We once had a player who was always hard to score because of her opponent's poor skills. I tried my best to train her backhand, but there was no progress. Despite our painstaking efforts, she cannot make progress. Since everyone pays attention to her backhand, it is no wonder that other players are always passing on to her backhand.

When I was on the verge of despair, I asked her how she wanted to play? She replied, 'actually, I like to use the forehand '. After knowing her preferences, we started to train her forehand. But I can hardly believe my eyes: She can handle almost all the balls perfectly, fast and good. After some targeted training, she scored three times as much as before.

In the first step, I showed how stupid a uniform training method was. In the range of 10 points, I want to raise her backhand technology from 4 points to 6 points, but her forehand is born to score 8 points, because there is no training, also changed to 6 points. After the main hand training, her main hand rose from 8 points to 9 points, which left her zhuer group. In the past, it was a waste of effort to focus on her weaknesses rather than strengths.

If a team member cannot behave in his/her own way (for example, not disciplined, inexperienced, confused, unfriendly ), usually the focus is on the negative performance of this person. This story tells me that by consciously discovering a person's skills rather than weaknesses, both the individual and the team can get better results. How to find a way to tolerate the shortcomings of this person and give full play to his long position is the key.

Principle 6:
Clear effort direction for the team

Marc Lammers said:

I used to think that to motivate the team before the competition, we can use something like this: 'We must win, or else we will be eliminated. 'And the effect is counterproductive, which cannot make them better. At first, I always had no idea why. Now I know. The problem is that a player cannot influence the results of a game by only one person. Even if she has done her best, there are still many factors that she cannot control in deciding the outcome. This kind of powerlessness makes the team members feel nervous and anxious, and thus cannot exert their abilities to the extreme.

I realized that winning or losing is only the result of our competition. The good news is that everyone can influence the game in their own way. So we won't discuss the outcome before the competition, but carefully repeat our strategy, and each player must pay attention to his/her own affairs. This is more specific and easy to control. In this way, the team members are more relaxed than before, and can play to the highest level. Evidence of the competition results.

As a scrummaster, from the above fact, I found it meaningless to tell the team one year in advance that "we must deliver certain features. Everyone is powerless, and morale is low. Even in a sprint, it is of no value to remind the team to deliver the features they promised to complete in advance, which can only put pressure on the team. If there is a lack of pressure, this may be effective, but in most cases, pressure is not the root cause of the problem.

Marc's gains tell us to focus on small improvements that can improve the productivity of teams or members. Is there any obstacle for the team to make progress? Can we hire experts in related fields for technologies unfamiliar to the team? If someone is in trouble but unwilling to help people, can it adopt Pair programming? Have time been consumed on worthless documents? Similar physical problems can be controlled. Solving these problems will naturally increase productivity and increase the chance of project delivery on time.

Principle 7:
The eyes are inner, and the eyes are limited. The eyes are outward and may be infinite.

Marc Lammers said:

In hockey, there are 38 tips and tricks. During the competition, I will give a command to tell the team how to make a small corner ball. To this end, I have developed a complex set of body language, and all the players should study hard. However, the opponent recorded these records and analyzed them, and finally found our secret. Later, they knew my tactical intent and our advantage would disappear.

By chance, I was invited to join the Dutch cycling team in France. I accidentally found that they had been using radio to keep in touch with drivers. I thought, "My God, if we can do this, then the advantage will not be back ?" When I came back, I secretly studied the rules and found that I didn't mention anything about radio. Therefore, I assume this is acceptable. Later I got in touch with a radio company and asked them to make ear plug-sized equipment because the bicycle was too big. After some adjustments, the first prototype can work.

The most interesting thing is that we have always considered this innovation a top secret and continue to confuse our opponents with physical language. In a year and a half, no one found our secrets, and played our opponent in the palm of the hand.

In agile and scrum, some practices belong to another way of working, that is, Toyota's lean principle, which we apply to the software industry. Apparently, someone has had a similar idea ......

From the perspective of scrum, I found that if scrum draws some practices from other related methodologies, it can become more powerful and more widely applied. For example, the architecture-centric process, risk-and case-driven approach, XP's idea of sustainable development speed, and test-driven development can be used as an example, and the Pair programming that suits our own situations. I have used it and gained a lot of valuable experience. Use other methodologies to create processes that suit individual needs.

Teach me how to look at other areas that are not related to software development from different perspectives, and take the essence of it. There are many valuable things in the world. How to discover and integrate these things into our daily work is an art.

Principle 8:
The more important the goal is, the more motivated it is.

Marc Lammers said:

From the financial point of view, whoever wants to be a hockey player is crazy. They can only receive a small bonus, which is hard to maintain. Despite the lack of income, there are still many applicants. If you win and become part of the winning team, it will be reported by media around the world. This feeling is more intense than money or anything else.

Theoretically, writing a class by a developer is irrelevant to any intention. In fact, there is a difference. This category is written for a technical library, internal tool projects, or for new NASA sites for real-time tracking of exploration activities on Mars, the results are completely different.

Marc reminds me that the best way to motivate a team is to make them feel that their current job is very important and can change the world. Some projects can feel this way. After delivery, the media will report on these projects as part of the Advertising War or have an impact on society. These cases do not require too much effort to motivate the team's morale.

However, most projects do not know much about them, even if they are very difficult to implement. As long as the project's external visibility and importance are improved, there is no need to spend too much incentive measures to stimulate everyone's enthusiasm. For example:

• Celebrate a successful release. We invite "important" people to attend and ask them to express their gratitude and describe the importance of the project to them.
• Let users know the release of the new version or the progress of the project, or publish it to the company news. Through these measures, let the company know what you are doing.
• Invite the team leader or CEO to visit the project and introduce him to the team.

Recognizing the importance of incentives may be a key factor in improving project productivity.

Conclusion

The above principles sound like common sense. However, you must know that the application of these common sense makes the Dutch women's volleyball team the best team in the world. Although with these theories and principles, it is art to make rational use of them in practice. When I heard Marc Lammers speak, I realized how he did it: Happy passion, constant self-reflection, and desire to discover and experiment with new ways of working.

This gives me the last principle:

The above principles will naturally be realized by combining the spirit of competition, pleasure, and beneficial self-reflection.

That's simple.

Tail note

Marc Lammers has completed a book on his coaching achievements. Please goWww. marclammers. nlView.

About the author

Urs Peter isXebiaSenior consultant who specializes in agile software development. He has participated in the development of many large products, using agile methodologies such as scrum and agile-RUP. At present, he works in an efficient distributed scrum team to deliver the next generation of information systems for Holland Tru. For more information about his current project, seeCase study: distributed scrum project of Dutch Railway CorporationArticle. TranslatorZheng Ke