Last week I attended a coaching seminar where Marc Lammers, the coach of the Dutch women's national field hockey team, gave the keynote speech. This team is the most successful in World Cup history, having won the title six times. While listening to his speech I started to realize why this team has achieved such outstanding results. Their success is owed, to a great extent, to his way of coaching. Marc Lammers has discovered critical ingredients that can unleash the power of a team, as a whole, and each individual that is part of the team, in unforseen ways. I was truly inspired. This article summarises the principles he discovered and describes how they can be applied in software development.
Being a ScrumMaster myself, I realized that the principles he discovered can be applied in my own Scrum team too. The reason is that they are, in essence, applicable to all kinds of teams, no matter whether they assemble cars, play hockey or develop software. In this article I'd like to share some of Marc Lammers' coaching secrets and experiences revealed during that seminar and how they can be translated into the daily Scrum/project practice. With this knowledge you probably won't be able to win the World Cup, but if you don't watch out you might make your development team perform beyond your own and your customer's wildest expectations.
Principle 1:
Use the power of effective communication
Marc Lammers:
In the early days of my coaching carrier I spent considerable amounts of energy to make myself understood. So, I explained my brilliant coaching strategies to my team in lengthy speeches. In order to make sure that they got my message I used to ask: 'Did everybody understand?' To my satisfaction they all nodded. However, the way they played proved that they apparently did NOT understand.
Seemingly they did not listen to me. Consequently, I started to talk louder, more aggressive and confronting. Unfortunately, it did not help. When I told my own coach that with this bunch of untalented deafos nothing serious could be achieved, he told me that it was all my fault. He showed me the results of communication research, which discovered the following: 'One can remember:
This opened my eyes. I started to use open questions, made them rephrase my strategies and created room for dialog and interaction. Not only did they better understand my concepts I also started to grasp their concerns, from which I could learn a great deal. From then on I had a seamless match between what was spoken before the game and what was finally played."
- 10% of what we hear
- 35% of what we see
- 55% of what we hear and see
- 70% of what we rephrase
- 90% of what we rephrase and do.
Related to Scrum, I can use this lesson in all areas where knowledge or information is exchanged. Think of design sessions, communication of requirements to developers or business people, explaining the development process to a business person or new team member, you name it. In all these areas mutual understanding can be dramatically improved when using open questions, dialog style communication, rephrasing etc., because it forces all participants to reveal what they really understand or think. This in return is the basis for a trustful and respectful relationship, which is, in my eyes, the most important productivity accelerator there is.
I already had discovered some of these laws in my daily Scrum practice. Nevertheless, it is a precious reminder of how much benefit effective communication can bring.
Principle 2:
Only a different way of doing produces different results
The communication story above contains another important principle. When Marc Lammers was experiencing that his initial way of communicating did not work, he first tried harder, instead of reflecting about what he was doing. I think that's human. Whenever we do not get the expected result we are biased to think that we just didn't try hard enough. As a result, we work more hours, talk harder, use more energy, work on the weekend and so on. In most cases we won't get far with it, as Marc's own experience proves. Only when he took a totally different stance towards the problem did he accomplish the desired result.
There are many cases where this principle applies. Think of how Scrum facilitates estimates. Instead of working with function points that are not related to the capacity a particular team can deliver, Scrum relies on empirical team velocity and complexity points, which proved to be surprisingly accurate in practice. So, instead of refining function point analysis and bring it to perfection, Scrum takes a total different approach, which excels in simplicity and accuracy.
Another example where this principle often is mistreated is the tendency to ask people to work overtime when a deadline is approaching, which apparently cannot be met with the current effort. Though it might be necessary incidentally, structurally it is proven that this approach is a mere treatment of symptoms, and in the long run it is useless. It does not only have severe consequences for team spirit and the health of team members, it also harms the quality of the software. The bug rate increases, and with it the workload to fix the introduced bugs. As a result, there is significant risk that things get worse by tackling this problem with overtime.
Scrum offers a more promising way to deal with this problem in the form of an emergency procedure, which in essence is a concrete application of the described principle. When it becomes evident that a deadline cannot be met, Scrum's emergency procedure suggests to consider the following actions: first, hold a retrospective to see which major impediments can be removed to boost productivity. Second, if no significant productivity improvements are discovered by applying Procedure One, think of which concrete tasks can be outsourced to an expert. This expert will not be part of the team, but only solve isolated tasks for which the team does not have the expertise. Third, if there are no such tasks, try to re-scope. Finally, if the client does not agree with re-scoping, the sprint has to be aborted.
As a summary, having the courage to radically reconsider and change the current way of doing is the only structural solution in the long run. Even though it is a challenging choice to take in practice, the chance of achieving the expected goal is much higher than if the team is sent on a death march.
Principle 3:
Innovation is a powerful means to produce better results, not a goal by itself.
Moreover, be aware of the side effects.
Marc Lammers:
"I'm constantly looking for innovation. During the Olympic Games I felt that I could not see critical parts of the game well enough from outside the field in order to give advice about how to play corners. We used to analyse video fragments after the game but for me this was too late. I wanted it realtime.
After some unsuccessful trials with a laptop that was connected to the tv-camera with a long cable I came up with the idea of video classes. These are a set of glasses with little screens in it on which I see all the tv-cameras capture. I got in touch with some engineers and some months later I could test the first prototype. From then on I could give much more detailed advice to my players.
There are three important things to mention when working with innovations I'd like to share with you:
- Innovation must always serve a purpose. I've been tempted many times to innovate for the sake of innovation, which does not lead to an improvement. There must be a clear challenge innovation has to solve.
- Each innovation has growing pains. Don't expect it to work the first time. It needs tweaking and tuning until it gives you the competitive advantage you want.
- Innovation causes resistance. Everything that's new frightens people. This fact has two implications: First, when you encounter resistance you probably found a real innovation, so be proud of yourself. Second, find a way to deal with resistance. Don't expect others to embrace your novelty. Give the others time to adapt and get used to it."
I'm convinced that if software development took these simple wisdoms seriously, many more projects would succeed. It teaches me the following:
- Regarding purpose: From my experience, lack of purpose is most evident when looking at the way tools are used. I've seen many projects that are tool-centred instead of result-oriented. The main concern is not about delivering good software, but how to use the tools as efficiently as possible. That's why the "start-out-without-any-sophisticated-tools" probably works so well in practice. Using a whiteboard and some stickies is often much more effective than a sophisticated chain of tools, because it forces the team to interact and focus on the challenges at hand.
- Regarding growing pains: Most changes in a project environment cause growing pains. No matter whether a new member joins the team, a new technology is chosen, a new process is used etc. expectations tend to be too optimistic. Knowing that growing pain is a natural consequence of change enables us to get a realistic rather than optimistic view through which we can anticipate accordingly.
- Regarding resistance: For example, when introducing agile development practices such as Scrum in organisations, resistance is a common response. Marc's story taught me to expect such a reaction and find ways to deal with it, rather than to judge and fight against it. When introducing something new, patience and attention to the resistor's concerns are much more effectual than relentless persuasion and pushing for change.
Principle 4:
Continuously challenge your way of working
Marc Lammers:
"Our training program included many 30 meter sprints. The team excessively had to train this, because for ages it is common practice to train 30 meter sprints. Then I had this idea to analyse the running pattern during a game. In order to achieve that, we equipped each player with a GPS for some training sessions. Analysis of the data showed that, on averag,e a player performs 15 meter sprints rather than 30 meter ones. Due to that we were able to make our training plan better match our real needs. Another small improvement was born."
This story teaches me two things:
- Keep asking yourself WHY you do the things you do. Is a particular activity done because 'we always' did it, or does it really add value to the whole? What concrete value does it add? Is it in proportion to the work that needs to be performed?
- If you can't come up with a satisfying answer for the questions above, start measuring. Measuring is knowing. Measuring allows us to evaluate the effectiveness of the countermeasures or adjustments and to see whether an improvement has been achieved. Measuring can be something simple as 'just stop performing a particular activity and see what happens'.
From my experience much time is wasted daily because the way of work is simply taken for granted and not questioned. The mere repetition of a task over a time makes it seem justified, even if it does not add value at all. When looking for productivity improvements, questioning the established way followed by measuring change is very effective.
Principle 5:
Focus on people's strengths not weaknesses
Marc Lammers:
We had this player that wouldn't score, because her backhand was miserable. I did everything to train her backhand but without success. She hardly improved despite our huge effort. Since the focus was on her backhand it was no wonder that the other players passed the ball to her backhand she couldn't really handle.
When I was close to desperation I asked her how she would like the ball to be played? She answered: 'actually here, on my forehand'. Convinced that she was no good at all we started training her forehand. What I saw I could hardly believe: nearly all the passes she got she handled smoothly and swiftly. After some intensive training with her forehand she tripled her scoring as well as her self-consciousness.
My initial approach shows how dull uniformity is created. I wanted to improve her backhand skill from a 4 to a 6 assuming a scale of 10, whereas her forehand was naturally an 8 but because it was not trained it became a 6 too. After training her forehand she increased from an 8 to a 9 making her outstanding. What a terrible waste it was to focus and try to improve on her weakness instead of her strengths."
Whenever a team member doesn't function the way he/she should (e.g. undisciplined, inexperienced, chaotic, unfriendly etc.), the focus naturally lies on these negative aspects of that person. This story teaches me that, by consciously scanning a person for skills rather than shortcomings, a much better result can be achieved for both the person AND the team. It's a matter of finding a way to live with the negative aspect of that person and foster the good ones.
Principle 6:
Give the team controllable challenges
Marc Lammers:
"Before the start of a game I thought it was a good idea to motivate the team with phrases like: 'we really need to win, otherwise we're out'. The effect was rather the contrary, it did not help them to perform better. Initially I was wondering why. Now I know. The problem is that the individual player has no chance to influence the outcome of the game by himself. Even though she does his very best there are too many other factors she cannot control and which can be decisive for the outcome. This lack of control made them tensed and nervous hindering them to function optimally.
I realized that winning or losing is merely the result of the way we play. The good news is that each individual player CAN influence the way she plays. So instead of talking about winning or losing before a game we carefully repeat our strategy before a game as well as the personal things each player has to pay attention to. That's concrete and much better controllable. Through this approach they are much more relaxed and in a condition to bring the very best out of them. Our results proved that."
For me as a ScrumMaster this shows me how little value there is in telling a team that we must deliver a certain amount of functionality in a year from now. It's beyond their control and therefore not motivating. Even in a single sprint, it makes little sense to remind the team of its commitment to deliver the agreed functionality since it only increases pressure. If a lack of pressure is the problem it might be effective but in most cases that's not the real issue.
Marc's lesson teaches me to focus on the next little productivity improvement the team or a team member can achieve. Is there an impediment that keeps them from not delivering? Can we hire an expert for a technology the team is not acquainted with? Is pair programming an option for those who get stuck but don't call for help? Is time spent on valueless documents? Such concrete problems can be controlled and their resolution automatically leads to more productivity and therefore increases the chance to meet the project schedule.
Principle 7:
Look around in your 'own world' and you only see limitations. Look at other ones and you see possibilities.
Marc Lammers:
"In hockey, there are 38 ways how corner can be played. During a match I instruct my team how it has to play it. In order to do that I developed a sophisticated body sign language all players had to learn by heart. The problem was that the competition recorded and analysed this language and finally decoded it. Consequently, they knew, what I was up to and my competitive advantage was under pressure.
Coincidentally, I was invited to join the Dutch cycle team during the Tour de France. By chance I discovered that they used radio sets to stay in touch with the cyclists. I thought: 'wow, if we had this, I could regain my competitive advantage at once.' When I returned home, I secretly studied the rules, where nothing about radio communication was mentioned. Therefore, I correctly assumed that it must be allowed. I got in touch with a company that produces radio sets in the size of an earplug, since the ones cyclists use are too bulky. After some adjustments the first prototype was operational.
The beautiful thing was that we kept our innovation top secret and continued using the body sign language in order to confuse the competition. For 1,5 years we were able to stay undetected and fool the competition before they found out."
Agile and Scrum, partly is the result of another discipline's best practices, namely Toyota's lean principles, that were adapted to the software industry. Apparently someone else had this idea before…
Porting the story above to Scrum, I realize that when Scrum is combined with practices from related methodologies it can become considerably more powerful and suitable. To mention some examples, I personally had good experiences with the Unified Process's architectural-centric, risk- und usecase-driven approach, XP's sustainable pace philosophy as well as test-driven development and (customized forms of) pair programming. Combining and playing with the ingredients of other methodologies creates the process that suites your needs.
This story has taught me to look differently at other areas that are not related to software development and see what it can contribute. There is a bunch of good stuff out there, discovering and integrating it into our own world is the art.
Principle 8:
If a goal is perceived as important then motivation is high
Marc Lammers:
"From a financial perspective it is madness to become a hockey player. They are paid a scholarship, which is hardly enough to survive. In spite of the dire financial reality applicants wait in queues to join. The notion that they can win and be part of that winning team, which gets media coverage all over the world, is much more powerful than money or whatsoever."
From a rational point of view it should not make a difference for which purposes a developer writes a class. In practice it does. It is a huge difference whether the very same class is written for a technical library of an internal utility project or for the new NASA website from which the next expedition to Mars can be followed in real time.
Marc's lesson reminds me that the best way to motivate a team is to make them feel that what they are doing is important and makes a difference. Certain projects have this perception by nature. Upon delivery they get media coverage, are part of an advertising campaign or it has impact on society. In these cases not much needs to be done.
However, the majority of projects have much less visibility, even though they can be very challenging. With relatively little effort motivation and work, pleasure can be boosted by improving the project's visibility and importance. For example:
- Celebrate a successful release. Invite 'important' people and let them give a speech to express appreciation and the importance of the project to them;
- Tell the organisation what you're doing, by communicating a new release or project progress to users (don't forget to add a picture of the team), write about it in the company newsletter etc.
- Invite the head of department or CEO to visit your project and introduce him to the team.
Realizing the importance of motivation can be the critical factor to make productivity soar.
Conclusion
Most of the principles described in this article sound like common sense. However, keep in mind that the application of these has made the Dutch hockey women the best in the world. As with all theories and principles the art is to use and apply them in practice. When I heard Marc Lammers talking I became aware of how he does that: with joyful enthusiasm, lots of self-reflection and an eager spirit for discovering and experimenting with new ways of doing.
This brings me to my last principle:
Combine a competitive spirit with fun and a healthy portion of self-reflection and all of the principles above come naturally.
It's as simple as that.
Endnote
Marc Lammers has written a book (in Dutch) about his coaching achievements www.marclammers.nl
About the author
Urs Peter is a Senior Consultant with Xebia, specialized in Agile software development. He has developed several large products applying different Agile methodologies, such as Scrum or Agile-RUP. Currently he's working in a distributed high performing Scrum team, which delivers the next generation information software for the Dutch Railways. See: Case study: Distributed Scrum Project for Dutch Railways for more information about his current project.
