The Retrospective

 I always tell my children to go through the previous question and answer sheets (upon receipt of the latter), to understand and retrospect, what they did good and what not. It gives a good indication of their strong areas, find out improvement areas and hence work on course correction. That's an examination retrospective.

Now, how many times have we argued and discussed at length about the 20:20 cricket matches post completion? 

When it comes to Sprint, alas, the retrospective is not given its due importance. That 30 minutes in your sprint timebox is an investment. What should be done for an effective retrospective?

 1. Plan a retrospective: (ie) Send the invite and the online form, where team members can mention the good and the bad (as cards) and even encourage the team to vote those items. That way you know which are your top issues and top winning strategies.

 2. Conduct the retrospective: Encourage participation. Sometimes the leads or managers and senior team members may be more vocal than the junior members. Give opportunities for them to speak up. Ask their views. Key points to note in a retrospective are:

  a. Do not make it emotional. 

  b. Follow a blameless culture.

 3. Act on those Action Items: The key for the success of a retrospective is that the team members should know that their voices have been heard. Concerns should be noted and translated to action items. Action items should contain owner and ETA. Actions should be acted upon and the team members should see those actions implemented in the upcoming sprints. This gives team 'Hope'. It creates 'Trust'. They feel 'Important'. All necessary for employee satisfaction.

Time to check the calendar guys - block the time for the retrospective!

The Anti Patterns in Scrum

There are certain practices that we do in scrum that are counter productive. These practices are called 'Anti Patterns'. Here in this blog, I have discussed some of those perils in Scrum teams.

Team Size: Scrum manifesto clearly states that the Scrum team size should not be more than 9. It is even better if it is of lesser than 9, but definitely not more than 9. Rightly said as the scrum team members should all know what every other person is doing. They need to work hand in glove! This is only possible when the team size is less. A team of size 'n' has n*(n-1)/2 communication channels. In the figure below we see that a 5 member team has 10 communication channels. 

• 1 talks to 2, 3, 4,5 and vice versa = 4 channels
• 2 talks to 3, 4, 5 and vice versa = 3 channels 
• 3 talks to 4, 5 and vice versa = 2 channels
• 4 and 5 talks = 1 channel.

If it were a 10 member team, imagine the chaos. we would have 45 channels of communication and it would be a herculean task to know what each team member is doing.

So keep the size to 5 to 7 members.

Changes within a sprint: Sprint is a short burst of work period. It has a well defined goal. The main essence of the scrum model is to analyze priority, ship it to customers quickly and get early feedback. Changing the scope or changing team members will have a negative impact on meeting the sprint goal. A clear anti pattern that you may want to avoid.

Ignoring the retrospective and its actions: The most important scrum ceremony in my opinion is the retrospective. This is because, we talk on the actual data. What actually worked and what let us down. It helps us as teams and as individuals to understand where we went wrong and self improve. It's an immediate feedback. Where else do we get it? Half yearly or yearly manager feedback? Really, do you want to wait a year to know what worked and what not? Conducted correctly in its spirit and working on its actions will see the teams only performing better and better. Participate, be vocal.

Lack of cross functional team: The scrum team should have developers, QAs, the availability of product owner, architects etc to perform their work seamlessly and independently. It is also very important to have every developer and QA backing up each other, so that on emergency situations, the other Dev/QA can pick up the work. That is precisely the reason why each team member should know what the other is doing and forms the basis for the team size.

Delayed testing, bug fixing: Testing, raising and bugs and fixing should be done within 24 to 48 hours of the code being sent to the QA for testing. Why is that so? The code logic is still afresh in the developers mind. Remember that in all probabilities, its a very complicated logic, where changing a single boolean value could wreak havoc. Strike while the iron is hot - give the bugs to the developers when the logic is very fresh in their minds and therefore rework/fix can be done very fast. 

There are many more - like the unavailability of the Product Owner, having a poor definition of done, having hierarchies in a team (note that scrum team has only 3 roles, the scrum master, product owner and the team) etc. We need to be aware of these anti patterns, educate the scrum teams about it to build a highly productive and collaborative team.

The Burn Up Chart

 For a long time, I was satisfied and there by used only the Burndown charts to track progress of sprints. This is until I read more about the Burnup chart and the whole gamut of values that it brings.

What is a Burn Up Chart?

You want to track the progress of your sprint every day. (ie) you want to know how many story points you have finished on each day and how many are left out to complete the sprint. You have decided to track it in the form of a chart. A Burnup chart does this exactly. We plot the number of story points completed each day and there by see how good/bad we are in a position to complete the story points within the sprint timeline.

The advantages of this chart are:

1. It shows any scope changes immediately, unlike a burndown, where it can be easily missed. This is very useful in identifying scope creep, as the chart always shows the changed scope at the top of chart, which the team would then know that as either 'scope creep' or revised target for that sprint

2. It helps Product Owners to understand the velocity and help visualize the day of completion if a few story points are to be added.

Now if you see the graph below, the above points can be inferred easily and quite accurately.

3. The other way to see the burn up chart is that we can measure the value delivered along with the story points delivered. Remember that in scrum, the result is not based on # of stories or # of story points, it is rather the amount of value that we deliver.

Assuming that in the above scenario of 50 points we have 10 stories, 5 with high values (5 points each) and 5 with low values (2 points each). The net value to be delivered in this sprint is 35. Again using this chart the total value delivered at a given point of time can be found.