LinkedIn
Twitter
Agile methodologies advocate a constant improvement over time of the quality of software delivery. This improvement comes in many ways, improving the overall quality of the software being built with every iteration, the ways of working of the delivery teams, removing blockers, removing processes that are not adding value, proposing better processes while improving the ones in place.
This is particularly evident in Scrum where teams meet on a daily basis, where any hindrance or any blockers are quickly dealt with, and in peer-programming and peer-reviews where developers improve coding standards and software quality.
This feedback is constant, improvement at all levels is promoted, for every iteration and every software delivery to be built with better quality and pace.
Regular feedback and improvement is at the heart of Scrum, and is best represented in the Daily Standups and the Sprint Retrospective.
Often missed or not taken as seriously as Sprint Planning or Backlog management, the Sprint Retrospective is the most important team meeting held at the very end of a Sprint, for the team to:
- Think about and discuss what didn’t go well during the Sprint
- Think about and discuss what went well during the Sprint
The outcomes of this discussion are recorded by the Scrum Master, and new ways of working are introduced for the next Sprint.
This regular meeting allows the team to take immediate measures: it’s a feedback loop as important as the daily standup.
When this Retrospective is missed or not taken seriously, team members don’t get an occasion to speak up and share concerns or introduce new ideas, which is essential in any collaborative project setting. Opportunities to improve are lost and one of the fundamental principles of Agile methodologies is absent.
The Retrospective is meant to be an open discussion where all members have a chance to share their views, and there’s an obvious problem with that: the risk is to end up in endless conversations and not end with useful Actions/Decisions. In open discussions of that form, the meeting greatly depends on the personalities of team members, how the conversation unfolds, what importance the items discussed are really given.
These meetings can easily be fruitless, hours seem lost, and that may be exactly why many teams decide to skip this event altogether.
Enter the Starfish Method
The Starfish Method for Sprint Retrospectives is an easy way to: achieve focus, give a voice to every member, and provide clear outputs and decisions.
The team is encouraged to think about what it should:
- Stop doing
- Start doing
- Keep doing
- Do more of
- Do less of
Team members get to write their ideas on post-its, and stick them on a board that looks like a starfish.
Once members are done with this process, a discussion can start on each of the areas and outputs are decided by consensus.
"Stop doing" topics are typically activities and processes that are a hindrance to progress and provide no value to the team whatsoever nor do they improve quality of delivery.Example: Asking all team members to write a daily report by email with detailed activities - when those details are not useful especially when a 2-minute conversation is sufficient.
"Start doing": Introducing new processes or activities that will improve quality or speed of delivery.Examples: Having team-members pair-up for peer-programming activities. Introducing Continuous Integration.
“Keep doing”: Aspects that the team would not want to change as they are key to a successful Sprint.Examples: Daily stand-up taking place at a good time for every member. Continuous testing. Code reviews.
“Do more of”: Any aspect or process which is useful but not fully taken advantage of. By spending more effort in these activities, quality will be improved.Examples: Coding standards have been introduced but more are needed for upcoming features. More team events that foster collaboration and good spirit.
“Do less of”: Useful processes to the team and to the delivery, but taking more time or effort than really needed.Examples: Less email communication. Less involvement in technical forums outside the scope of the current delivery.
An interesting way to do this is to start with the negative aspects, and progressively cover the positives, as it fosters problem solving and positive thinking - in the following order:
Stop Doing, Do Less Of, Keep Doing, Do More Of, Start Doing.
Once team members are done placing their post-its on the starfish, a member of the team (usually the Scrum Master) reads them out loud, one “area” at a time, and a consensus is found, ideas are given more importance because of the frequency with which they are present on the board, new ideas are discussed and the team goes away with a list of decisions for the next Sprint. A list of Actions/Decisions is written for each area and shared with all team members.
New ways are working are introduced right away which will again be re-assessed at the end of the next Sprint by doing another Retrospective, using this method again. With this regular feedback loop, each iteration benefits from the experience of the previous one.
The Starfish Method can benefit Scrum teams in a very short time with a very focused conversation. It prevents ideas from being lost in conversations involving up to 10 people.
Outside of Sprint Retrospectives, this focused discussion method can also benefit other types of meetings when assessing or reviewing any form of process, product, activity. It informs teams on what works and what doesn’t in meaningful ways, enabling the introduction of new ideas by way of constructive feedback.
Constant improvement is a foundation of Agile deliveries, and Sprint Retrospectives are key to achieve it. The Starfish method is one of the best tools to go about this fundamental process.
