Agile Sailing: Retrospective

“Without reflection, we go blindly on our way, creating more unintended consequences, and failing to achieve anything useful.” – Margaret J. Wheatley


Part five of a series.

As with the Agile process and competitive #sailing, each sprint and each race comes to an end. In both cases, the participants could punch the clock, move on to the bar, and call it a day as the current work is done.

However, successful Agile teams and racers take the opportunity to reflect on the actions of the immediate past.

The Agile Retrospective

The “last” activity in the Agile process is to perform a ‘retrospective.’

“Last” is in quotes because one of the keys tenets of Agile is that the process be continuous. There is no end to the work. It is more of a milestone that has been achieved on a long journey and marks a pause, but the journey is not complete.

The retrospective period is an opportunity to reflect on the work that has been completed, the work that did not get done, and a chance to think about how to make everything better. In the Principles behind the Agile Manifesto, the final principle captures this concept:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Upon completion of the sprint, the team should ask questions about the entire process of developing the product:

  • How was our quality? What impacted the quality of the product?
    • Did we do sufficient testing?
    • Are the right skills in place?
    • Were the requirements understood at a granular level?
  • What was the team’s velocity (a measure of how much stuff got done)? Is that in line with historic velocity? Does the velocity need to increase?
    • Were there unplanned interruptions?
    • Is there sufficient or too much communication?
    • Do we need more people on the team to increase capacity?
    • Are there additional tools required to support the team or automate the process?
  • Have any priorities changed for the product or functionality?
    • Are there new market dynamics?
    • Are there new customer opportunities?
    • Has the product owner’s perspective changed based on current demos?

As the team answers these questions, adjustments can be made for the next sprint. Through this process of identifying challenges and issues, the team is able to experiment with approaches to improving the process. The ideas that work are kept. Those that do not are dropped.

Since the process is repeated for every sprint, results are available in a short window and the cost of trying something new is low. Teams are more willing to adopt the changes because they do not have to commit to a long-term change. If it doesn’t work, you’re only committed to the change for the duration of a sprint (typically 2-to-4 weeks).

The Racing Retrospective

In a typical regatta, there are three to 10 races. These may be completed in one day or over the course of several days. The racing ‘retrospective’ is completed at the conclusion of each race.

Just as the agile development team asks itself about the performance over the last sprint, the sailing team works through their performance:

  • How was our speed?
    • Were the sails tuned appropriately?
    • Are the sails performing as expected? (Side note: nearly every living sailor will tell you that the sails could be improved – sails are old, they are not cut perfectly, the hanks are falling off, etc. It’s the favorite excuse for why a boat is not faster.)
    • Did the crew perform well through maneuvers (tacks, gybes, sail changes, etc.)?
    • How was our speed relative to other boats?
  • How was our position on the course relative to the wind?
    • Were we on the favored tack?
    • Did the boat get to the wind shifts before the rest of the fleet?
    • Did we have weather forecast information prior to the start of the race?
  • What is our current standing in the regatta?
    • Is the boat in competition with a large number of boats or with one or two?
    • Do we need to sail defensively so as not to lose to several boats or do we need to take some big risks in future races to catch up?
    • Do we work to cover some competitors to ensure we’re in front of certain competitors or do we sail aggressively to be in front of the fleet?

A Series Retrospective

A big part of the retrospective period, regardless of whether you’re developing a product or racing a boat, is to learn. Through a review of our past actions, we seek to change the future. We deliver more relevant products, we deliver them faster, we expend less effort, and, at the end of the day, we enjoy ourselves more!

A short retrospective on this series. It’s been fun to talk through the comparisons between Agile development and racing sailboats. As I’ve written each article, the original idea that the two are very similar resonated even more deeply.

I can imagine that the writers of the Manifesto had a similar conclusion that articulating the Agile approach was a great release. Being able to articulate to others what they had been feeling for years as there is great frustration in being unable to communicate.

The articles also reinforce some of the key tenets of Agile methodology that I need to apply more rigorously to my own life:

  • The work of life is continuous – Determine what is important and focus on doing the important things. Review, adjust, and try again.
  • We’re all individuals and responsible for ourselves – However, with very rare exceptions, our lives are intertwined with teams. Family, co-workers, neighbors, and more. If you work well with your teammates (in whatever context), everything else in life will be better.
  • Simplicity creates better results – We often try to address so many things or try to do so many things that the results for each suffer. Prioritize, focus, and achieve greatness in whatever you choose.
  • Rome was not built in a day and no plan is perfect from the beginning – Plan, execute, evaluate, adjust, and repeat. As long as we are open to learning and adjusting our approach based on our experience, we have the opportunity to grow and see great results.

I hope you have enjoyed reading this series. Please share your perspective. Then, go and be successful!

Originally published on LinkedIn

Go Further

About the Author

Kevin Bracy is the Director of our Cleveland team. An experienced consulting executive, he has worked within a variety of service delivery companies to provide a wide range of solutions to clients. Kevin’s areas of expertise include ERP implementations, program management, system test delivery, technical infrastructure design/implementation, call center operations, and application development. 

Contact the Author to Learn More

  • This field is for validation purposes and should be left unchanged.

Leave a Reply

Your email address will not be published. Required fields are marked *