"Starfish" Retrospectives Technique
Retrospective introduction
Retrospectives are held at the end of each Sprint or iteration and are a vital part of a development’s team ways of working. The retrospective creates an environment where the team feels safe to openly voice opinion and discuss how to continuously improve. By making 10’s and eventually 100’s of tweaks to ways of working which ensures continuous evolving high efficiency. In our experience, the best teams communicate with other team members when a retrospective task has been completed e.g at the daily scrum. Highlighting these successes will motivate and inspire others to complete their own retrospective tasks, creating an environment where continuous improvement is at the very heart of the team’s DNA.
Creating an environment where people are supported is vital.
Example Starfish Retrospective Board
Why Starfish over other techniques?
The output of a Starfish retrospective is more than a prioritised list of project improvements. Starfish accepts that not all improvements are quick wins and allows the team to categorise short, medium, and long-term project objectives. Assigning them to a team member(s) who takes ownership and drives that output forward. Starfish is also a fun and fully engaging process.
How does Starfish work?
As with all other retrospectives, the first part is to reflect on the previous sprint and discuss the following sections in this order:
What the team should KEEP doing
What the team should do MORE of
What the team should do LESS of
What the team should START doing
What the team should STOP doing
The team REFLECTS and groups sticky notes thoughts into categories e.g. Business Analysis, Releases, Sprint Reviews etc. Following DISCUSSION, these are categories are prioritised by VOTING. For example, the 3 categories with the highest votes will be further discussed and broken down into TASKS.
Tasks are then categorised into areas that the development team, (including Product Owner) can control, usually short-term goals. Tasks involving consultation with other teams are medium-term goals. Tasks involving external factors to the project are long-term goals.
STEP 1: REFLECT AND WRITE THOUGHTS ON STICKY NOTES
Starting with the “KEEP” section silently reflect on the previous sprint and write thoughts on sticky notes. Time-box each section to 2 minutes - it’s important to allow attendees work in silence (using the Delphi technique) so as not to be influenced by others. Repeat the process until each attendee has reflected on “KEEP” through to “STOP”. Notes are then attached to a board, segmented into a starfish shape.
STICKY NOTE STARFISH
While the team is adding their notes, the facilitator should start grouping similar words together into categories.
STEP 2: TEAM DISCUSSION
The team discuss the outputs and identify those requiring immediate attention. The facilitator should document any tasks that the team think will improve the project.
STEP 3: PRIORITISATION VOTING
At retros, there are often more areas that need improvement vs the available time to put everything right. As with requirements, it's important to work in a priority way to ensure improvement in areas causing the most pain and areas bringing the most value to the project. One example of a PRIORITISATION TECHNIQUE is to give everyone 5 votes and attendees can choose how they vote, for example:
All 5 votes on a single category
3 votes on one category, 2 votes on another
1 vote on 5 separate categories etc
As the votes are processed, you’ll like to see some fun and games where tactical voting might occur. This is OK! A starfish retro should be fun and this is all part and parcel of ensuring team consensus.
STEP 4: TASK BREAKDOWN
Once the categories have been prioritised, the team reviews feedback listed under each category and breaks this down into a series of tasks - following the SMART framework.
Specific, Measurable, Achievable, Relevant, and Time-bound.
The “Impediments Circle Model” is great for this.
IMPEDIMENTS CIRCLE MODEL
Three circles from inside to out: control, influence and concern. With control housing the majority of sticky notes.
The definition of the 3 circles included in this model includes:
Circle of control: The development team (including Product Owner) are in control of the output's destiny and can implement them without any external involvement.
Circle of influence: Where influence may be required e.g. upgrading GitHub to Enterprise addition (where a budget may need to signed off by the client). The Product Owner and team may need to influence the decision maker.
Circle of concern: Outside of the project team and client’s control e.g. if a new feature is requested on a cloud-based application. A case can be presented to the provider but ultimately, is out of the control of the client & development team.
The final step in prioritisation is to document who in the team will be responsible for managing and implementing each output.
STEP 5: CELEBRATE COMPLETED RETROSPECTIVE OUTPUTS & KEEP THEM VISIBLE:
CELEBRATE retro outputs that the team has completed and keep them visible! It keeps everyone inspired to improve further and is also a reminder of how far a team has come!
Celebrating ‘Done’ Retrospective Outputs
