Running Effective Retrospective Meetings

In the last article we talked about why it's a good idea to do a retrospective regularly – right? I had mentioned in that article that we will be having a separate article to talk about how to conduct effective Retrospective meetings that are productive and add value to the scrum team/project.

The Basics:

Before we get into conducting or running a retrospective, there are a couple of prerequisites or like I tell my team, there are two important ground rules that we need to follow.

Rule 1: No Management Team in Retrospective

Even though Scrum advocates that the scrum team shouldn't have any roles like a lead or manager, it is very difficult in real life to run an organization without people managers. The Retrospective is supposed to be an open discussion where people can share their opinion and ideas freely. The presence of someone from the management team is a very big detriment to an open discussion.

As Scrum Master it is our responsibility to ensure the meeting is productive and does not get impacted due to the presence of the management team.

Real life trivia: The senior management team may suggest to you that, their presence will give them an insight into the mindset of the team or get to hear first-hand their suggestions. But, trust me – their presence will only result in the team being more cautious and reserved about what they are going to say and end up missing vital improvement points. One of your scrum team members may feel that senior management isn’t supportive enough on the project initiative and keep pulling out members to work on adhoc assignments which is impacting team velocity. But, if someone from senior management is present in the meeting, do you think he/she will be willing to say that point out loud? Even if management team members promise to keep an open mind and not be judgmental of the team, the fear factor will always linger in the teams mind and will result in pointless retrospective discussions.

So, what if your Management Team insists on attending the meeting?

As Scrum Master, there are a couple of things you can do:

1.     Educate the members of Management that their presence results in people being more reserved and isn’t resulting in effective discussion

2.     Explain to the members of the Management that, you will eventually collate all the improvement/feedback points and as representative of the scrum team, you will bring all those points to their attention/review

Every member of the management team would be interested in understanding how they can help the scrum team/project and if you help them understand that their presence is causing a problem, most likely they will listen. More importantly, if you are committing to share the suggestions with them, they don't have the need to actually attend the meeting personally – isn’t it?

Rule 2: No Finger Pointing or Blaming during Retrospective

This again is a very important ground rule that I try to enforce during my retrospectives. When we are blamed for some mishap, it is natural human tendency to become defensive and try to refute the allegation and defend ourselves. When one member of the team points a finger at another and blames them for some mistake, the discussion deviates into the more of a personal attack territory which is firstly unwarranted and secondly uncomfortable for all parties in the meeting.

I always try to keep the discussion from getting into that territory and all team members are encouraged to share their points without pointing fingers at other members of the project team.

Bonus Rule: Full Attendance

This one is a no brainer. In order to collect feedback from all members of the team, I try to schedule the retrospective on a day that the entire team is present. Of course, unplanned sick leaves are unavoidable but usually I schedule the meeting and request all participants (including product owner) to attend the session.

Running a Good Retrospective

Ok, coming back to the topic at hand of running a good retrospective, I try to follow the simple/tried & tested – Start/Stop/Continue Approach.

I like to run the retrospective by asking team members what would they like to Start, Stop and Continue doing. Each team member takes turns and suggests points that they think the team should start or stop or continue doing – plain and simple.

Some examples could be :

•      We should start doing code reviews to improve code quality
•       We should continue to have a quick demo with the product owner after we finish story development and before the full-fledged testing of the story starts
•        We should all start showing up on time for stand-ups
•        We shouldn't start work on a story or task until the current assigned task/story is completed
•        And so on…

You may be wondering – what will go under the Continue option?

Usually, new ideas that go under the start category must be checked for their effectiveness in the subsequent retrospectives and if the team feels the idea was good, they can reiterate the same by including the point under the Continue category. After a couple of sprints if the team is habitually following the suggestion, we no longer need to include that point in the continue section as well.

Spice Things up

Sometimes, this start/stop/continue may become too monotonous if we do the same thing again and again. Team may feel the meetings are becoming boring. You may think of ideas to spice things up.

We could do things like – pass a stick pad bundle to all participants and ask them to write their suggestions, fold up their point and put it in a basket. After 30 mins, we start taking out one item at a time and the team can discuss on the point. Or you could ask a different member of the team to run the meeting every week so they too understand the tricks of the trade.

Or, we could document all the key takeaways from the retrospective and start off the next sprint retrospective by looking at these points and evaluating if we have really worked on the improvement items. in my projects, I document the sprint wise retrospective findings in a wiki and we review the previous weeks improvement points and assess where we are before we add more entries to the list. This way the team understands that you as the scrum master are serious and aren’t doing this to just tick off one of the recommended meetings list.

Some last words:

I personally find that this start/stop/continue method is fast, easy and effective way to run a retrospective. By not associating any names and focusing only on actions, we don't waste our time on feelings. We don't need to worry about whether team members are happy or sad – we just focus on work.

Each item we document will directly result in change in the way we work. The team will start doing newer or better things, they will stop low value activities and continue to strive towards being a better team as a whole. That's the point behind the whole retrospective meeting isn’t it?

What do you think? Do sound off in the comments section…

Scrum Meetings

In the last few articles, we have covered many different aspects of Scrum. In this article we are going to check out the different meetings we could have in a team executing a Scrum Project.

To Refresh – What is Scrum?

Scrum is a management framework for incremental product development using one or more cross-functional, self-organizing teams of about 6-8 people each. It provides a structure of roles, meetings, rules and artefacts. Teams are responsible for creating & adapting their own processes within this framework. Scrum uses fixed duration development cycles frequently called Sprints or Iterations which are typically 2-4 weeks in length. Scrum teams attempt to build a potentially shippable (a.k.a Property Tested) product increment at the end of each Sprint/Iteration.

What are the Different Scrum Meetings?

Scrum is a collaborative methodology where the different teams have very close interaction with one another. In each iteration or sprint, we could potentially have 4 different meetings starting with the Planning meeting and ending with the Retrospective. We will take a look at each of them in detail next.

Note: All these meetings are facilitated by the Scrum Master who by the way does not have any decision making authority in any of these meetings.

The Sprint Planning Meeting

Also called as an Iteration Planning Meeting, at the beginning of each sprint, the Product Owner and the Team hold a Sprint Planning meeting to negotiate which items from the Product Backlog they will attempt to convert into working product during the iteration. The product owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel, they can implement without accruing technical debt. The team “pulls” work from the product backlog onto the spring backlog and begins work.

Real Life Trivia:  Gauging the teams available capacity in a sprint is one area where almost all scrum teams face stiff challenges especially when the product is in its initial stages or the product itself is quite complex in nature. This is the reason we used the sentence without accruing “Technical Debt” because if the team commits to build X amount of work in an iteration but actually delivers only Y amount of finished product, the difference (X-Y) becomes the teams technical debt that gets carried forward. The Scrum Master facilitates the gathering of estimates from the start of the sprint and the actuals at the end of the sprint so that the team can work towards improving their estimation. This makes the teams work output more predictable and stable.

If the product backlog hasn’t been refined to a satisfactory level, bulk of the planning meeting actually goes into doing this (Ideally a Backlog Refinement Meeting should be scheduled before we go into the Sprint Planning session). Towards the end of the planning meeting, the team will breakdown the select items into tasks and makes a final commitment to do the work.

The maximum allotted time (a.k.a Timebox) for Sprint Planning meeting is usually 2 hours per week’s duration in the Sprint. That means, for a 2 week sprint the max duration would be 4 hours.

The Daily Scrum

The Daily Scrum is like the bread & butter of this methodology. Every day preferably at the same location & time, the Scrum Team members will spend about 15 minutes reporting to one another. Each team member will quickly summarize what they did the previous day, what they plan on doing today as well as any potential impediments he/she faces.

As everybody is standing up, there will be a sense of urgency for everyone to finish their updates and return back to their desks. Most teams also maintain a sprint Task List (typically on a Scrum Board) which are tracked on a daily basis during the sprint execution.

Real Life Trivia: As the sprint development is underway, newer tasks could potentially be discovered which may be vital towards achieving the sprints delivery goals.

It is always a good idea for the product owner to attend the Daily Scrum. This can help the team get their queries clarified almost instantaneously and keep up the momentum going.

Real Life Trivia: In some organizations the Scrum Master or the Product Owner also happens to be the guy who wears the tag of “Boss” or “Manager” which often times leads to the Invisible Gun effect where everyone in the team is wary of what could be the potential implications. This actually hampers the foundation of scrum teams which are supposed to be self-managing and self-organizing. So, it would be a good idea to leave out folks with authority over the team from daily stand-ups to foster a more open & collaborative environment.

The daily scrum is intended to move away from the traditional waterfall concepts like the Status Meeting where everyone is sharing a progress update to the project manager. So, the scrum master should facilitate the team to share updates with one another rather than to him/her.

The Sprint Review Meeting

After the Sprint’s execution timebox completes, the team holds a Sprint Review Meeting to demonstrate the working product increment to the Product Owner as well as other stakeholders. This meeting is usually a live demonstration of the finished product and in some organizations also called the “Sprint Demo” or the “Show & Tell” meeting.

After the demo, the Product Owner reviews the commitments made at the Sprint Planning Meeting and declares which items he/she considers as “Done”. As unfinished work items don’t qualify as potentially shippable, there could be items that may not be considered as “Done” for ex: a new screen which is only code complete but isn’t tested thoroughly.

Real Life Trivia: The term “Done” is of crucial importance because this is one area where the product owner and team may have misunderstandings. During the iteration planning meeting, one of the focus points should be the “Definition of Done” and the Product Owner must document what he/she expects from the product to ensure that the development team clearly understands the same.

Incomplete items are returned back to the product backlog and ranked according to the product owners current/revised priorities and become potential candidates for future sprints. The Scrum Master helps the product owners and stakeholders to convert their feedback into new backlog items for prioritization.

Real Life Trivia: New scope discovery often outpaces the rate at which the team is able to deliver features in each iteration. Hence, the role of the product owner becomes very crucial towards the success of the project. The product owner is expected to evaluate the current/new scope and keep the product backlog up to date so that, whenever the next sprint starts the team will work on the top most priority items that add the most business value to the product.

The Sprint Retrospective Meeting

Each Sprint or Iteration should end with a retrospective. During this meeting the team reflects on its own processes. They inspect on their behaviour and what was done and think about actions to improvise the same for future sprints.

A good Scrum Master will try to find means to keep the meeting objective and not let it become the dreaded name calling blame game type exercise. In a mature organizations the team has psychological safety and can openly share points about mistakes made in the last sprint.

A common impediment to the outcome of a productive retro session would be the presence of people who will be doing the performance appraisal of the team. In such situations the team will move towards diverting the blame to someone else in the team instead of identifying a fruitful solution to the problem at hand.

Retrospective sessions can also expose organizational impediments. Once the team has actually listed down the impediments within their immediate influence and act on the same, the Scrum Master should expand that list and start chipping away at organizational impediments too.

Real Life Trivia: Sometimes it is easy to blame organizational impediments which the team have very little to no control and forget about areas of improvement within the teams confines. A good scrum team will list down these organizational impediments as well as things in their control to make sure the outcome is the best possible given the situations.

Backlog Refinement Meeting

As we know by now, the Product Backlog is a continuously changing list of work items that are arranged by priority. One of the key tasks of the Product Owner is to make sure this priority is up to date with respect to the company’s vision for the product so that, when an iteration/sprint starts, the team can focus on the top most priority item.

However, most product backlog items may need refinement because they could be too large or poorly understood. Teams have found it beneficial to actually spend some time each sprint to prepare the product backlog for the next sprint planning meeting. This is an optional activity that can add a lot of value (and make things better) for the scrum team but is not one of the mandatory activities. Hence this isn’t part of the initial picture chart outlining the scrum process meetings.  

During this Backlog Refinement Meeting, the team will estimate the amount of effort they may need to complete the items in the backlog as well as provide other technical information to the product owner so that he/she can decide on the priority for the items. Large or vague items are usually split, clarified and may be individually prioritized based on both business as well as technical concerns.

Real Life Trivia: Sometimes, only a small subset of the team will spend time in refining the backlog instead of the entire team to save everyone’s time.

It is a common practice to write the product backlog items in a User Story format. In this approach large/vague items are called Epic Stories and the team will work together to breakdown this epic story into smaller more manageable child stories that can be individually worked upon.

Real Life Trivia: The saying old habits die hard is very true for software development also. Most people will tend to fall back on old habits like trying to do things in waterfall way by breaking down epic stories into activities like design, development, testing etc instead of actual smaller stories that can be designed built & tested in a single sprint.

Hope you were able to understand the different scrum meetings in detail. In the next article we will review the different Scrum Artifacts like Product Backlog, Product Backlog Item etc.

Prev: Things you need to know about Scrum