I wanted to follow up with the third instalment discussing how we transform traditional operations teams into agile machines. I’ve already discussed how we approach the subject with the teams and start to put some of the ceremonies into their day to day schedules. In this post I wanted to follow up with the output of retrospectives, moving to more Kanban focused working and planning.

Posts in this series:

By now we are already a little into this piece of work and one of the most important aspects of agile is the introduction of retrospectives, most teams in fact regardless of their agile working status already do some kind of retrospective, usually a team meeting. A retrospective or retro just focuses the mind on the last sprint, we ask different questions depending on the type of retro the scrum master is running. You can get a number of different types of retros to run, such as; 4 L’s, Speedcar, Starfish and many others.

Retro

For out first retro, we ran one of the most basic ones out there, this was the Sailboat retro. In this we draw up a sailboat, added on an anchor and ask the team to contribute things which made the team go faster at the top towards the sail and things which dragged the team back at the bottom near the anchor, as you can see in the image below.

This exercise is really simple and the feedback from the team was that they enjoyed the daily stand ups, they also enjoyed finding out more about what others in the team were up to and also liked the Kanban style of working, for visually highlighting where work is.

Things which did not work for the team was the additional meeting time, a feeling that sometimes the stand ups went on for too long and that the value was maybe not as high as they expected.

Breaking down the first sprint

It’s really important when you are introducing this new way of working that as a facilitator implementing this process you also take a step back and look at what is working for the team and what isn’t. That is exactly what I did with my colleague working on this with me. Our feeling was that we’d not done a good enough job of explaining that benefits of this process can take months to manifest as the changes we are making are so incremental. We discussed this and how we could improve the situation. Our solution was to better explain this to the team, provide some examples of what benefits they can expect and when, as well as explain why they may not be feeling benefits. Reasons for this included the fact at present they are an isolated team working this way in a department that works traditionally.

As you would expect from your first sprint when it’s all new, results were mixed.

As you can see from the teams burndown chart, we had increase scope during the sprint, at this point though as we are teaching the team and getting them thinking and acting the right way, this isn’t so much of a problem, the pretty charts and attractive numbers will come in time. Key things I took from this though are the sprint ended up with 68 stories, 86% of them were completed and only nine remained.

So, think about that for a minute, for a team working traditionally and getting work left, right and centre, this is the first time they’ve really had insights into how much work they complete in a two week period. This is of course based on a simple count of work items, which has no reference to size of story or anything.

Story points

At this point, a member of the team asked about adding story points. We went though the idea of story points, made reference that it’s a team metric and not to get hung up about the metrics, but that introducing them is a smart move as it makes sure your stories have some capacity to them. You can change the burndown chart to be a sum of story points as well so this was a good move forward for us.

We explained some of the story pointing methods available to them and said really as a team it’s up to them. We went with t-shirt sizes, small, medium, large and extra large, starting in five point increments. The team started attributing points to their work and we would now start to get an idea of how many points the team can complete in a sprint. Our first sprint using story points looks at 290 story points over a two week sprint, combined of 38 stories.

We are mid sprint but here you can see we have a number of story points remaining, also indication of the items not estimated and total scope increase, we’ve only added 15 points this sprint, so that is already an improvement so far on before. Again, the agile purists here will already write this sprint off but again this is about at this stage teaching them the fundamentals and getting them acting and thinking in the right way.

Work item sizes

One last point in this post is about the introduction of theory around changing user stories to features and adding tasks to user stories. We talked about user stories which were actually bigger pieces of work and if that’s the case then it should be a feature with more smaller stories created under it. This was something brought on by the team without me or my colleague mentioning it. This is great to see and shows the team are starting to think in an agile way.

Summary

One of the things I want you to take from this is that while we are quite statistically heavy in agile, is that you can progress well and teach people the required skills and ways of working and see improvements without the need for heavy focus on statistics, these will come in time.