How a yacht race turned me into a Scrum Master

This is a re-post from my blog, but one that is still relevant today.

Continuous Improvement, Autonomy, Validation – these terms are becoming so worn that they feel like business jargon. But if you have experienced the pain that Stagnation, Command & Control and Big Bang Deployment brings, you have ample reason not to look back.  The mild embarrassment that comes with joining the ‘Agile cult’ is greatly outweighed by the soul-numbing awfulness that is the alternative.

Although the above is my experience too, this is not that story.  I have also had experiences with Chaos – the inferno that regularly erupts in Startupland and in many Open Source projects.  It, not Agile, is the real antithesis to the frozen hell that is Waterfall/Taylorism/TheoryX.  This is not that story either.  I actually started appreciating what I now call the Agile mindset, on a sailing boat.

As an adolescent I was pretty interested in ‘Team Building’ and while training as an outdoor sports instructor, we learned about Tuckman’s Forming/Norming/Storming/Performing.  I had noticed that cohesive teams had better morale and more fun but that they also sometimes missed creative solutions to problems that messier, argumentative teams seemed to come up with.  This even led me to study social psychology, although that field had disappointingly few insights on offer.  And really, I didn’t want to just understand teams, I wanted to be a part of one.

As a student and later as a Yacht Master I did a lot of yacht racing.  Now in the nineties, mirroring the software development world, yachts were starting to organise themselves differently.  Being a relative pauper but a skilled sailor, I was used to being ordered around the boat by the owner, who would also steer the boat. If you wanted to win races, you had to find that rare combination of the rich and skilled sailor.

Imagine my surprise when one day I stepped aboard a boat, shook the hand of the young man at the helm and he diverted me to the owner!  Here was a man who had given up the driver position to some pipsqueak, fresh out of a dinghy!  I recounted the experience to my skipper later that evening and we laughed about this.  What chaos it must be on board!  They’ll never win a thing.

That year the boat, Yellow Rose, won every series it entered.  The next season it won all the major series in the Netherlands and thereby the national title.  The season after that, it won the national title and its own class – X-332 – internationally, as well as Cork week – one of the biggest fleet races in the world.  I had gotten to know them well by then, I knew that they were a relatively young crew and that they hardly ever changed members.  I was allowed to join them for a race, the nationals in Hamble, UK.

I had never seen anything like this.  The owner took the position of tactician, but not the helmsman ‘driver’ position.  He completely trusted the crew with his boat, concentrating instead on the wind, tide and competition.  There was almost no shouting on board and if emotions flared up because of an inevitable mistake, these were evaluated after each race.  But the evaluation was of what went wrong in the situation, no blame was assigned.

Even more astonishing was that: no one person gave a call when a manoeuvre was initiated – each time it was initiated by a different person.  The helmsman initiated a tack, the mainsail trimmer initiated a gybe, the bowman initiated a kite hoist.  I saw manoeuvres called and then initiated seconds later that would have taken minutes of complicated instruction by the tactician on my previous team. And they improved all the time, every race was meticulously discussed and adapted to.

I was addicted – I sailed with Yellow Rose as much as I could.  I progressed to training other sailing teams too and started to spread the goodness there.  I wanted to spread this goodness to my work in software development too, but it took me another five years of searching before I found a team where I was allowed to apply what I had learned on a boat.

I am not going back.

Scrum and Yacht Racing – Roles

This is a cross-post from my own blog, I hope you find value in it!

Watching the development of yacht sailing teams during a campaign, I have always been struck by the similarities between an effective team on a boat and an effective Scrum team.

If we take an X-35 team, it has 7 to 9 members.  Each member of the team has a very specific set of skills and a role. A team has a build-up to a race or a series of races in a campaign.  Usually there is a main goal – a certain race that stands out like a world cup – combined with a series of smaller events.


To get an idea of a typical modern sailing team, it is handy to understand what everyone does.  Beginning at the back of the boat:

The Tactician can be equated to Product Owner.  He or she does not actually do any of the physical work but rather decides where the boat should go.  A good tactician knows when to consult with his team and when to make a decision.  Depending on what the tactician decides, the necessary manoeuvres become evident.  The tactician is responsible for where the boat goes, but not how it gets there.

Next up is the Helmsman, or ‘Driver’.  In waterfall methods, just as in old-fashioned skipper-led sailing, this would be the project leader.  However, in modern sailing, the helmsman is simply a part of the crew.  Like a designer, he has a lot of influence on the progress of the team, but he is still a developer and part of the development team.

Then come the trimmers, they set the sails up to give maximum power.  Especially when heading upwind, they will often be doing their own thing without involving the rest of the team too much.  They are responsible for keeping the boat power optimal – in a car they would be the engine.

In the front of the boat there are the bowman or the bow crew.  They have very specific tasks, that affect the handling of the boat: hoisting and dropping sails, tripping shackles, holding and moving gear.  They have to work independently yet also together with the rest of the team – in a car they would be the gearbox.  In a Scrum team you could compare the trimmers and bow crew to front- and back-end developers.

One team member or otherwise an outsider often takes the role of the trainer – that is what a Scrum Master is supposed to be after all.  In fact, I like the fact that not all sailing teams feel the need to appoint a trainer – a really experienced Scrum team should be able to keep to the principles of Scrum without the need for a Scrum Master in the same way.

Self Organising Teams

When I join a boat for the first time as a trainer and I detect that the owner, driver or tactician have an hierarchical view of the roles on board, I often tell them about my experiences as a bowman.  As a student, I started yacht racing aboard a boat where the owner was the helmsman (the driver) as well as being the tactician and the brains, if not the hands, of all the trimmers and bow crew.  A standard race would consist of this gentleman shouting a series of commands at his crew, whilst he steered the boat and decided where to go.  This meant he was effectively deciding everything on board: steering, sail trim, boat handling, tactics and strategy – it was all up to him.  In times of stress, he would sometimes leave the helm to do someone else’s task if their performance was not to his liking.

When I first started to sail on board of the boat, the results were actually pretty good – the boat achieved good results in the local competition and did fairly well in national events too.  However, after a couple of years, I decided it was time to leave.  The team kept changing, people would leave, usually after having been shouted at for not following instructions correctly.  In the incident that had triggered my leaving, we had run aground because the spinnaker had not come down on time.  According to the skipper this was because of my actions as a bowman, according to me it was because he had been shouting at me so much, he had simply forgotten to steer the boat.  Whatever the reason in this case, our competition was clearly getting better – we were winning less and less races.

At this time, in the mid 90’s, the idea of a self-organising team was becoming a more popular style of leadership on many yachts.  The idea being that if each team-member knew his own role and it was up to him to act, the amount of knowledge being used was greater than if it all had to trickle down from the back of the boat.  Modern boats were also harder to drive, meaning that a helmsman would sacrifice the quality of their own work if they started involving themselves with what someone else was doing.  The trimmers and bow crew communicated with each other instead of via the skipper, losing less time and information in communication.

This method developed – in the team I had joined, we determined who would initiate action for all of the standard manoeuvres that the boat would do.  The team that I sail with nowadays has handling-sheets for 16 standard situations, only four of which are initiated by the driver.  This is not to say that there is no hierarchy on board – if a snap decision has to be made, the tactician makes the call, but in all other circumstances each position decides on their own actions.

These new methods resulted in the old-fashioned way of doing things, let’s call it the skipper-driven (waterfall?) method, being less effective than the new, self-organising method.  And that’s the nice thing about formal competition – it doesn’t get much more empirical than the results in a race.

Scrum Mastery in Corona Times

As precautions against the spread of the Corona virus take effect, many of our teams have started working from home.  This is hard.  Good Scrum is much easier with a team who all work in the same location.  The Spontaneous- and non-verbal communication that is lost usually makes understanding each other a lot easier.

Here are a number of practical tips that we thought up.  Please feel free to share ideas that we didn’t come up with.


• Over-communicate, call every team member every day to see how they are doing, also privately.  Are there worries about Corona virus in the family, extended family etc.
• These can be tense times, people will be more stressed than usual.  As a Scrum Master you can take the stance of a trusted confidant.
• Share information from the company about how we deal with Corona virus.
• Practice expectation management with your team and with your stakeholders.  Development velocity will probably drop, team morale may suffer.  Speak about this, practice openness.
• Online meetings are more difficult that face-to-face meetings, people are more easily distracted and the meetings can be more tiring.  Ask everyone to switch on their webcam so you can see people’s engagement as in a normal meeting.
• Keep meetings short – 1 hour max!
• Be extra strict in facilitation.  Allow only 1 person to speak.  Consider that there will be lag and latency in audio and video.
• Use a headset and not laptop audio to reduce background noise.
• Working from home can give a lot of flexibility – if the children need care in the afternoon, work in the evening.  However, this may make collaboration more difficult – speak about this in your team.  Do we keep to office hours?  Collaboration in the mornings?
• We have quite good experiences with Microsoft Teams – Microsoft are even offering it for free at the moment.  Experiment with it as a Scrum Master.  Make sure you are skilled at using it during meetings.
• Make a ‘random’ channel in Teams for informal chat – we’re still people who like to babble.
• If you use JIRA: the desktop app is often faster and gives more insight than the web-app.

Per Scrum Event

Sprint Planning

• Make sure, even more than usual, that the Product Backlog is organized.  Don’t waste time on a lot of small stuff.  Prepare by already making the next sprint and drag in items that you know the PO will want anyway.  That leaves more room for discussing whether this will fit in the sprint.
• Make sure you know the velocity of the previous sprints and that you know who will be away so you can forecast the sprint well.  It is quite conceivable that velocity will be 10-20% lower than when you are co-located.
• Do part 1 of Sprint Planning (when you pull items from the Product Backlog) with the entire team.
• Do part 2 of Sprint Planning (when you design and detail items) in small groups or individuals.  That can make the event shorter and more focussed.

Daily Scrum

• It may take longer than usual, be flexible with the 15 minute timebox in the beginning.
• Perhaps have more than one Daily Scrum if that helps.
• A check-in, where everyone says how they are doing, preceding the event, can be useful.
• Even more than usual, remember that this is a meeting to inspect and adapt the plan for the day, not a ‘round-robin’.  “Who worked on item 1 yesterday, who will work on it today, are there impediments preventing it from being “Done”?”.  This prevents a lot of scrolling up and down in JIRA (or other backlog tool).  Now you can start at the top and work your way down.  This stimulates swarming and picking up the most valuable items first.  Read more about this practice here.

The Sprint

• As a Scrum Master, make sure there is still informal communication between team members – check chat/slack channels – is there enough communication, is everyone participating?
• If backlog items are being swarmed, set up a seperate chat/channel for this so that they have their own place to be communicated about.
• Let the technology do its work – use Git commit messages so you can see pull requests and your test automation tool to see failing tests.

Backlog Refinement

• Keep meetings shorter.  Choose a clear, small scope and refine only that.  Prefer more, smaller meetings over fewer, larger meetings.
• Use online sketching tools, I like
• Planning poker is possible from within Microsoft Teams chat – just type in your estimate.


• Perhaps do this more often – every week instead of every sprint – again keeping it short.
• Start with a check-in “How are you?”
• Begin the retro with a retro on working from home
• Give team building more attention than you already do.
• Make sure of a good vibe, the compliment shower is a good format.  Instead of only improving a process, make the question “how can we make the best of this?”.
• Collect items beforehand, that saves data gathering during the meeting.
• As always: find 1 or 2 concrete improvements for the next sprint.

Microsoft Teams (or other collaboration tool)

• If used properly, this can be your single mode of communication replacing email, Outlook meetings, Whatsapp etc.
• Teams integrates well with external applications like Git or your test tool reporting in separate channels.
• You can invite people in a channel for a meeting, automatically adding it to the team calendar.  This saves you having to invite people separately one-by-one.

Good luck! Any more ideas?

How much benefit does ‘Agile’​ provide?

“How much is it providing me exactly?” This question was asked by a CEO to a group of Agile Coaches and Scrum Masters that I was part of not long ago. It struck a cord with me but fortunately I managed to stop myself from giving him a quick answer to a different question. An answer that many of us are quick to give. Not only do we believe it to be true but we have seen and made it happen time and again. ‘What’ is it able to give us? Well, who does not want frequent and continuous deliveries with high business value. Teams that are end to end capable, responsible, improving, focused on well crafted Sprint Goals and in close collaboration with stakeholders and customers. Fortunately it has become an increasingly big part of our worldwide product building DNA and I do not even care if we call it ‘Agile’. We can call it whatever you think these beneficial things mean. From ‘common sense’ to ‘being adaptive’ to plain ‘how would you approach it if it was your own stable?’.

No this question had nothing to do with ‘What’ it would deliver him. He knew quite well otherwise we would not have been given the chance to change things so rapidly. This question is I believe hard to answer properly in the way I afterwards understood he meant it. He meant having all those people creating that specific product twice but at the exact same time: one way done ‘Agile’ and the other ‘how it used to be done’. Having ‘the right measured data’ would then answer his question but I have yet to see something like this happen. Within the Quantum realm perhaps. There is however a next best thing: when you transition from the ‘the way it used to be done’ towards ‘let us try this now’, immediately start collecting data (as in ‘the right measured data’ mentioned above). I know not all of us will get these kind of questions but I think it is beneficial to at least have given it some thought.

Deployments per Sprint. Bug Slippage. Team, User and Stakeholder Happiness, etc. etc. I bet most of us are aware of quite some useful metrics relating to all those awesome teams we have come across, not to mention the more usual suspects like Velocity. If you are able to show the trend of any of these things from the very beginning you can convince someone way better than just providing the ‘What’. Facts and clear trends simply speak louder than anything else. “How much is it providing me exactly?” reminds me to ask myself if I thoroughly understand how much the actual benefits are since the very moment I have become involved. This has since not only helped me in conversations with management but also in looking for trends on even more levels than I did before. So what about you? How much benefit has ‘Agile’ provided you and your environment exactly?

intrinsic motivation Thomas de Graaf

Intrinsically motivating environments

Some time ago I said to someone that I want to create an environment in which people become intrinsically motivated. He replied to me “But intrinsically motivated people are already motivated themselves!”.

In the world of IT, with more ideas than successful implementations, we continue to seek for new buzzwords to help us out. Everything-as-a-service, full-stack t-shaped unicorns, high performing teams and intrinsically motivated people, who would dare to say ‘no’ to these? Although there is a truth in these buzzwords, misunderstanding them can have devastating results. Those buzzwords might distract us from what really makes the biggest impact on the productivity of teams, defining the environment in which people work.

We like to put people into ‘boxes’ to understand them better and within IT that would preferably be binary. Within complex environments such as human behaviour, that is however not applicable. Let me prove this to you. For those who see themselves as intrinsically motivated, who needs his salary to pay the monthly bills or maintain his/hers standard of living? Who is saving up for a nice new car, bathroom, kitchen or house? Or are you looking forward to buy that new gadget or piece of clothing from the next salary? For those who see themselves as extrinsically motivated, did you ever leave the office with the feeling that you accomplished something great that day even though your payment didn’t change because of it? Did you ever feel challenged on your work, because someone gave you a challenge and you resolved it? Did you ever feel appreciated at work because someone said thank you when you helped them out?

Hopefully I just proved there is a lot of grey area here and people are generally both intrinsically and extrinsically motivated. But that is not where it stops, it gets even better! Motivation is not static, we can influence it! Imagine you are a predominantly intrinsically motivated cartoon artist. You make awesome cartoons, appreciated by millions of viewers worldwide. One day a new chief editor is assigned who reviews your creations and every single time he says they are not good enough. Without elaborating why, he puts all of your work in the paper shredder right in front of you. Would you remain intrinsically motivated? What if he also decides to cut your salary or stop paying at all? And what if this cartoon artist would be a software developer instead, would this still apply?

Now the other way around, can we make a predominantly extrinsically motivated individual more intrinsically motivated? As a manager, try telling your team that you didn’t just hire them for their capabilities, but also want them to develop themselves in areas they are interested in, so they remain motivated and committed for a longer period of time. Give them the opportunity to explore new challenges, accept failure and let them learn by trying. Ask them if they are happy with their work and seek new opportunities together if the current work is not giving any satisfaction. In fact, anyone can help creating an intrinsically motivating environment. Try giving a colleague a compliment, let someone pick up a story for whom it is a challenge rather than a walk in the park. Give your colleague a compliment or thank them if they did something for you, it’s also the little things. Don’t forget to have some fun too, it might make you more intrinsically motivated as well.

Therefore, let’s stop talking about intrinsic motivated people and start talking about intrinsically motivating environments. Examples anyone?

A product backlog should contain just about 50 items

An thought-provoking idea has rested in my mind for some time and I’m writing it down right now to get some feedback. Maybe I’m completely wrong, but that ‘ll be clear from the reactions.

I often see very large product backlogs with hundreds of items in them. The sheer size makes it very hard to keep the overview. The symptoms are then solved with ever-expanding structures with epics, features, themes etc. But the root-cause is the size, and I contend that it’s not wise to make the backlog so large.

And I think it is really not necessary to have a large backlog. It’s rather a remainder of a waterfall mentality.

A product backlog with 50 items is enough! And this is why:

The top of the backlog, the work for the coming 2-3 sprints, should contain small and clear items. In my experience most teams deliver 6-10 items per sprint, so that yields some 25 items at the top.

Below that, the items should not be that small. There should be larger items that can be sliced into small pieces later.

Slicing already now is not wise. It could be that we will not deliver this item. New, and more important items can emerge, the PO may down-prioritise these items. Maybe the client asks us to take new directions, or the team invents smarter technical solutions. Slicing the items too early is a form of waste. Having too many small items in the backlog can make us less agile. We don’t want to change direction because we have put so much time in the existing items already.

So, after the top 25 small items, there should be larger items in the backlog. If the top-items are all 1-8 story points in size, the items lower in the backlog should be 13-40 points in size, and lower still the items should be even bigger. So having only 50 items in the product backlog is enough to keep the team busy for a year or so.

Well, this is my theory. Any thoughts?

Backlog refinement – theory and tips

The activity in Scrum that causes most confusion is the backlog refinement. The scrum guide does not treat refinement as an event, like sprint planning or the retrospective. So it does not have a clear timeslot in the sprint. The scrum guide treats it as an activity that needs to take place, but leaves it up to you how to perform this.

The literal text about backlog refinement in scrum is:

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

So, the goal of backlog refinement is that product owner and team work together towards a good product backlog.

In the picture below I give a sketch showing the timeline of a new idea to working software, which may help to clarify the refinement process.

Backlog refinement Andre Heijstek Agileminds Valueminds

A new idea starts with a stakeholder. This can be a customer with an idea or complaint, or someone from “the business” with a smart idea, or a developer with a technical suggestion. These ideas should be given to the product owner.

The meeting where this idea is discussed with the PO is the very first backlog refinement. Maybe it is just two persons talking with each other, but the idea gets refined a bit already. If the PO likes the idea, it is placed on the product backlog. You could call this part of the process the “business refinement”.

Next, the idea should be discussed with the development team. They should get a clear picture about the item that needs to be developed. They should also estimate how much work it is, so the PO can take an informed decision about whether or not to develop this. Do the expected benefits outweigh the expected costs?

You could do this refinement session with the whole development team, but you can also start with subset of the team. In this way you can develop this idea into something better without spending the time of a lot of people. You can also invite stakeholders to this meeting if that will lead to a better clarification. You could call this meeting a pre-refinement, or prefinement, if you want.

If the idea is clear enough, you can have a refinement session with the whole team, so everybody will share the same picture. This is the “real refinement” session, where you will also do the estimation. If necessary, multiple refinement sessions can to be conducted until the idea is really clear.

After refinement, items can be picked up by a team in a sprint planning session. If the refinement has been done properly, the first part of sprint planning is easy. Just pick up the right amount of backlog items where the sum of the estimates matches your planned velocity. After this, sprint planning II remains, where you do detailed design on the selected items and add technical tasks.

It could happen that there still is a need for additional clarification during sprint execution. If this is just about minor details, that is perfectly OK. You could call this the after-refinement.

Hopefully this clarifies the refinement activity a bit. Any questions or comments? Please let me know.