Sunday, October 29, 2017

The “Starfish Method” for Useful Retrospectives | Supreme Agile

The starfish diagram is an excellent information gathering activity used to help the team members to reflect the things that they want to bring up throughout this short session, it’s based on an evolution of the historical three basic questions asked in this session:
  • What Went Well?
  • What went wrong?
  • What can be improved?
Now, instead of answering these three basic questions that categorize the participants' response to a "Black" and "Whit" criterion, the starfish diagram contains five areas for the team to choose:

Keep Doing (What the team should keep doing?)
A very good idea is to start the retrospective meeting with positive insights of the team members, the "Keep Doing" area will allow the team members to share their good insights and what they liked in the last iteration.

Less OF (What the team should do less of?)
This area will allow the team members to share their negative insights and the practices that they think that should be changed in order to promote the team process. In most cases, we will want to understand which are the processes that the team invest a major amount of effort and bring little benefit to the team/Customer.

More OF (What the team should do more of?)
This area will allow the team members to focus on the things that they should focus more such as tools/practices that will improve the process.

Stop Doing (What the team should stop doing?)
This area will allow team members to raise all things that are not promoting the team or Add value to the team/customer and therefore the team should stop using them.

Start Doing (What the team should start doing?)
This area will help the team members to suggest new ways to improve the process (New practices, Tools, Etc.) to increase the value per iteration.

The Starfish diagram and the maturity of the team

A frequently asked question about this technique is "Can we use this exercise on a new team?", Well, the answer is certainly Yes! The starfish technique is suitable for mature and un-matured teams as well.

The main reason for that is that this exercise is relatively simple and does not require any special demands or experience from the participants. In addition, the starfish exercise Provide an easy platform and criteria that will allow the team members to share their insights in a relatively simple way.

The Starfish exercise

The starfish exercise is executed with a few simple phases, starting from the preparation and continues with the data gathering, the basic phases are:

Phase 1 - Preparation 

Prior to setting up the meeting, make sure that you prepare a board with the picture of the starfish diagram, the board should allow the team members to use sticky notes to add their insights per criteria.

Phase 2 - Agenda

Once all team members are located in the room, start with a short description bout the meeting goals, and what do we want to achieve at the end.  

Phase 3 - Running the exercise 

  1. Start the exercise with a short brainstorming session with the team, in this session the team members are asked to write their insights about a specific category, but as I told before, start with the good things first, so you can start with one of the positive criteria ("More" or "Keep").
  2. After 4-5 minutes, ask the team members to stop and ask each one of them to read out load his insights.
  3. Once all team members are finished, take 2-3 minutes to review the main ideas and make sure that the team members are aligned.
  4. The main ideas should be copies to the board (Just use Sticky notes), and prioritized based on the amount of value they will add once they revoked. 

Phase 4 – Repeat phase 3 for each of the other sections

Phase 5 – Set owners and Goals

Once the board Is filled and prioritized based on the team insights, it’s now the time to set the owners for each action item that need to be mitigated in order to improve the process. 

Thursday, October 26, 2017

The Agile Retrospective meeting, Everything you must know | Supreme Agile

Many teams can work hard to accomplish a common goal, But the problem begins once they cannot find a way to improve, so working hard is great, but the key to major improvement is improving the process of "How" the team works...?

In the Scrum framework, teams can answer that question by performing the "Retrospective" meeting at the end of each iteration, the main goal of this meeting is to help the team gain an opportunity to make a process improvement after each iteration, and not just working "Harder".

 What is the purpose of Agile Retrospective?

The retrospective meeting has been around since the beginning as one of the seven Core principles described in the agile manifesto "At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts its behavior accordingly." 

The retrospective meeting is the platform which allowing the team to discuss and understand how they can improve the current process and increase the effectiveness of their work. 

The missing concept of the retrospective meeting

The retrospective meeting is usually carried on the last day of the two weeks iteration, in a meeting that takes anywhere between 30-90 minutes, the main issue that occur in many organizations is that they see the time spent on this meeting as a waste of time, by their state of mind, the team should focus on the product and not reflecting how they work and what they do in the iteration to deliver the product (The team is just too busy to waste their time in such meeting). 

The responsibility to make sure that the organization will follow the agile manifesto to allow the team to perform a continues improvement in their work process, is on the product owner and scrum master that should validate that the retrospective meeting will get a high priority and that it’s enforced once the organization decide to implement the agile methodology.

Why doing retrospectives is not questionable?

There is one agenda in agile that make it so great, which is the drive to achieve a continuous improvement in both the agile process and the team ability to flourish within its boundaries and the retrospective meeting is one of the best ways that the scrum framework provides to support this agenda.

Therefore, what is the most important thing regarding retrospectives? Well, it is simple; all you need to do is to ensure they happen at the end of each sprint. Seems to be simple? Well, it is not!  Based on my experience there are many teams that do not always seem to understand the concept of the meeting and why it is so important for them to raise and fix all impediments that affecting their ability to improve sprint by sprint?

The most important thing in scrum retrospective meeting is to ensure that they happen at the end of each sprint, there should not be any debut about it. This is actually simple, without conducting retrospective you will find very fast that the same mistakes and impediments are continually happening repeatedly which will not allow the team to improve and flourish.  

Setting-up the retrospective meeting

To help the team members to be able to share their thoughts, we must make sure that we provide them a safe and comfortable space that will make it easier for them to discuss about their insights. 

How to choose the space for this meeting:
  • Make sure that the room is comfortable for the people attended.
  • Teams have the tendency to perform better in rooms that windows and natural sunlight (It can be in a meeting room, Coffee Shop Etc.).
  • The room should have a good space to allow the team members to walk around (do not choose a small place that people will feel like they're in a crowded situation).

The main phases of the retrospective meeting

There are a few good ways to perform the retrospective meeting, but the main key is to follow a few basic phrases to actually allow the team to share their thoughts and in the end to improve the work process in the next iteration, the main phases, and concepts that should be part from every retro meeting:

Phase 1 – Provide the confidence for the team

The main key for people to share their real thoughts is to provide them the confidence and safety that they can speak without any other people judging them, many retrospectives are doomed to be fail once the team resources do not have the confidence to speak and raise the real issues that they see through the iteration, so the first and most important thing of the retrospective meeting is to help people to gain a real confidence to allow them to express as they want.


Phase 2 – Data Gathering (Retrospective Agenda)

  1. The scrum master will ask the team to determine the positive aspects of the last iteration and write in on a board, this is very important to start with a positive start and celebrate the iteration achievements.
  2. The scrum master will ask the team to determine the problematic aspects of the last iteration and write in on a board (Prioritized by importance).
  3. The team will review the board artifacts and will suggest ways to improve the problematic artifacts.

Phase 3– Set the Goals

The scrum master and team will determine the Goals following five basic principles: 

Specific – The goal must be specific and set for addressing a single issue.

Measurable – Once the goal was set, it's time to set the metrics to measure it, otherwise how can we actually guarantee that the goal was accomplished?

Achievable – What is the benefit in setting a goal that you cannot achieve? To actually make an improvement, we must set goals that we can accomplish.

Realistic – I want to make a better world! Is it realistic? Any goal you set should be realistic to the environment and team, there is no point to set goals that are not realistic and therefore are not achievable.

Time-Boxed – After you set a goal, make sure you set a time limit to accomplish it, this is the only way to validate that you address the goal in a time frame that will make the difference in the next sprints.

Phase 4– Apply Action Items in the next iteration

Once the team set their goals, it’s time to translate them into real action items that the team will use to improve the process. Without setting an action items, the team will both be able to make the difference in the next iteration, setting the goals is just the beginning, the through challenge is to set an action plan to accomplish them. 

Now, translating goals into action items can be a challenging task even for the best teams, the three main challenges that you should pay attention to: 

More Discussion fewer action items

The team creates an endless discussion about each action items that cause a diversion from the original goal instead of extracting real action items, therefore the facilitator must validate that the team focuses on improvement by reducing any conversation that Is not contributed to that goal.

Too many action items less Discussion

The second problem is that the team will only focus on creating the action items instead of making a short discussion to agree about the real scope of the problem. To reduce this problem, it's the facilitator's responsibility to create a shared understanding of the common goal.


The Scrum Master as Superman

The third problem occurs when the team depends too much on the scrum master, and therefore trusts him to handle all problems and action items, to overcome this problem, we will share the ownership of the action items on the team members as we expected to see in Self-Organize teams.

Phase 5 – Ownership and Follow-Up

Each action item that is resolved will take the team one step further to continues improvement, and that’s the most important thing that we want to achieve from the retrospective meeting.  

Once the action items are determined, the next step is to assign the owners for each action item, to do so, the facilitator should ask for volunteers to handle the challenges (the facilitator should never assignee the owners!), the main idea is that each team member will volunteer to handle at least one action item. 

Another important point that the facilitator should handle, are the action items that do not have an owner, once he recognizes such scenario, he should start a discussion with the team to understand why no one was claimed to ownership.

My Presentations