Writing about Agile feels a bit like shoveling water from a strainer to the ocean … with a spoon. But as this blog post says “Sailing” in its headline it fits quite nicely with the ocean metaphor.
I like sailing! And I like Agile Software Development (well, most of the time)! So what could suggest itself more than comparing what both have in common. This way this hopefully is a – different kind of – refresher on some of the key concepts of Agile Software Development. At the same time you might also learn something about sailing. Or at least you can watch some of the cool embedded sailing clips.
When talking about sailing here it is about sailing competitive in a regatta. So it looks something like this which might also come close to some projects when looking at the weather conditions ;-).
By loading the video, you agree to YouTube's privacy policy.
Learn more
Always unblock YouTube
Inspect and Adapt
Sailing fast is the embodiment of inspect and adapt. You are constantly checking the position of the sails and your current course in comparison to the wind and the competition. This is especially important when you are on the beat towards the windward mark.
In Agile this part is covered by the retrospectives that are held after each sprint. Even though most (agile) teams will – at some point of time – start to improve also outside the retrospectives (implicitly by doing small inspect and adapt cycles at the coffee kitchen). Of course these things must be in balance with the sprint goals. Some improvements can simply not be done at any time, but require some planning.
The goal is to constantly improve technically and methodically to become faster and/or deliver better quality or to improve in other areas that are important to the project at that time. As the focus of projects might change the focus in retrospectives might need to change as well.
In sailing it is quite obvious that you cannot change the wind, but you can adjust a lot of other factors by steering and trimming the boat. Keep this in mind for retrospectives as well and try to focus on the things you can change as a team and not at those that are out of your reach.
For retrospectives it is especially important to keep focus. Keep focus on the past sprint because that is what we are normally looking at. Keep focus on things the team can improve and not something in cloud-cuckoo-land the team can anyway not influence. Do not try to derive as many actions as possible, but just a few concrete ones. Then really work on those in the next sprint and do some kind of follow-up.
Another real-life problem is that retrospectives – and this is also true for other “standard”-meetings – tend to get boring after some point of time. Here is an important difference to most sailing regattas. Software projects often last quite long. One thing that can help here is to have really great variations in the retrospectives. A good source to get new ideas for retrospectives is for example the Retromat . Other possibilities are rotating the facilitator. A team member or a scrum master from another team can for example facilitate retrospectives every now and then. Reflect on the way the team is doing retrospectives. Invite stakeholders or members from other teams you are collaborating with. Change the location and as a last resort: Bring some cake :-).
Team and Communication
Sailing is a team effort and so is (agile) software development. First of all it is for sure important to understand (and accept) strength and also potential weaknesses of the team members. And as with a sailing crew the mutual understanding will naturally grow the longer a team stays together. For sure this is not only true for software teams. But here is also a major difference between a regatta crew and a software development team. In sailing there is one person – the skipper – who has full responsibility what is happening and into which direction the boat is heading. In an agile team the responsibility is shared. But this means really everyone has responsibility and not that noone has ;-).
Image from https://3d-car-shows.com/volvo-ocean-race-2014-sets-sail-in-october
On the communication side there is sometimes a slight tendency in agile development processes to overextend. Some readers might object here, but from my experience more communication does not necessarily mean better nor clearer communication. On a sailing boat there are clear commands and those are communicated so that everyone understands what happens next, e.g. preparing to tack. Of course the bigger complexity makes clear communication a lot harder in software projects. And on a sailing boat there is also no room for discussions. Something that is for sure important in software projects as long as they do not run out of the rudder.
Try to utilize the existing meetings to its full extend before inventing new ones. For example the daily standup in Scrum . This is for sure a good opportunity to transport a good amount of important information. But too often these standup meetings are getting painfully boring and inefficient. Stay focused and potentially make this a topic in the next retrospective. Small teams sitting together in one office anyway might not need those meetings on a daily basis. Do not stick to the book if it does not fit your needs!
Skills and Equipment
On a sailing boat you have different positions like the helmsman (typically the skipper), the main trimmer, the jib trimmers (port and starboard), a bowman, a tactician and potentially more depending on the size of the boat.
Now in agile teams we also have different “positions” like frontend expert, backend hacker, database guru, the masterchief tester and potentially a scrum master (sorry, I ran out of cool terms). And likewise a sailing crew, members of an agile team can switch positions to some extend. But there simply is a certain degree of expert knowledge that can hardly be avoided.
The challenge of mapping stories to be done during a sprint to the skills available in that sprint could probably fill a blog post of its own. The basic assumption should always be that the team has all skills required in the project. But still vacations and focus on certain types of stories might lead to a mismatch here. Just keep that in mind and try to plan early on for this.
Of course in longer running projects it is essential to spread the knowledge required for the different areas … even if that might mean writing some documentation or slowing down development in some sprints. This will help a lot in later sprints where more team members have the required skills to work on different kind of tasks. At least on a basic level. If for example the helmsman/skipper of a regatta yacht is going over board for sure the rest of the crew is still able to pick him up again. Even though maybe not that fast and elegant as the skipper could do it himself. But hopefully the point gets clear.
Anyway communicating these kind of things to the stakeholders is really a key factor. For example planning a lot of pairing on a certain topic in one sprint to spread certain knowledge. This way it gets clearer why there might be a short drop in the velocity and the decision can be taken together on what might be good sprints to do this.
By loading the video, you agree to YouTube's privacy policy.
Learn more
Always unblock YouTube
If you look at nothing else in the above video than 2:30 to 2:40. That is some skill in a quite stressful situation getting the shackle attached in time before the sail goes up. If that fails for sure it would mean disaster strikes.
The above clip shows some nice skills and team work, thus it could have been added also to the previous section. Working on ones skills for sure is equally important in sailing and (agile) software development. For sure this happens a lot already while working on the project (sailing), but sometimes you need to train some special maneuvers. And it is important to have the time for that outside of the daily project work.
On the equipment side things are easy: You just want to get the best equipment possible :-). For sponsored regatta teams money might be less of a problem here than in some software projects. But just keep in mind that working around for example missing hardware or missing permissions is probably more expensive in the end.
Summary
Sure this is a blog post with a wink :-). And a lot of things sound very obvious while writing and proof reading it, but in the daily project routine one is easily moved away from these things. Maybe you just want to do a comparison – just for you – with your favorite sports or hobby. It might help getting a fresh view on some aspects in agile software development.
For the end just one of my favourite sailing clips. It is just too funny when the sailing guys are talking about the Kite guy asking “Is the Kite guy any good, does he know the rules of sailing?” … “He’s gonna smoke all of us!”.
Seems they just get a fresh point of view from sailing together with different boat classes … and a Kite guy :-).
By loading the video, you agree to YouTube's privacy policy.
Learn more
Always unblock YouTube
Was this post helpful?
More articles
fromThomas Jaspers
22.2.2019 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Thomas Jaspers
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.