Scrum

I’ve given a brief history of Agile and talked about the Agile Manifesto, those were both research driven. However I can talk about Scrum from personal experience. I’ve been involved with a couple of more tentative uses with a few Scrum ceremonies but also done it properly with the bells and whistles. Overall I enjoyed using it and think it has a lot of positive elements but that doesn’t mean it’s perfect.

Ceremonies and terminology

I’d say you need these call it Scrum:

Sprint: Progress through the project is broken up into regular phases.
Retrospectives: A meeting where you look back over the previous sprint for successes and failures.
Planning sessions: A meeting where you pick what tasks to focus on during the next sprint.
Stand-ups or daily scrums: A short daily meeting where you share your progress and any problems.
Product backlog: A prioritised list of known tasks and requirements for the product

For me almost everything else is optional but although you can throw something together there are definitely official approaches to Scrum. I’ve even done a course and got a certificate. You learn the ceremonies and the proper names for things. It was interesting to see the by the book approach. Knowing what’s in the book is good but I think blindly following it is bad.

You’ll probably also come across some named roles:

Product owner: Who represents the customers or business interests to the developers.
Scrum master: Who is responsible for guiding the Scrum process to make sure things stay on track.

Plus some named artefacts:

Sprint backlog: A prioritised list of tasks for just this sprint.
Burndown chart: The progress of tasks during this sprint.
Velocity: The amount of work a team can generally do in a sprint.

There may be different variations but this is what I used.

Regular meetings

A strong theme in Scrum is regular meetings. It has meetings every day and every sprint, say, every two weeks. Some might complain that these events are wasting time that could be better spent on productive tasks. I think the crucial thing to realise here is that meetings are meant to be short. A stand-up shouldn’t be more than 15 minutes and is probably less. Retrospectives and planning sessions take longer, maybe up to a couple of hours together. Assuming a 7.5 hour day that’s 6% on meetings. Last time my team tended to have 10 minute stand ups and just an hour at the end of the sprint, that’s only 3.5%.

I think it might be possible to waste time by picking too short sprint or having overly large teams. Using one week sprints you’re doubling your overhead. Spending 12% on meetings might be worth it… but maybe not. Doubling your team is even worse because of the team problem. I can imagine that quadrupling your overhead… that’s 24%.

I think 5% of the sprint on meetings sounds okay and 25% sounds like too much. That’s still a bit abstract. If the meetings aren’t valuable then this is just a waste. What do you get for your time?

Stand-ups

These should happen every day at a regular time. It doesn’t matter too much when they are, morning or afternoon, whenever is the best time to get everyone. All the developers get together and report on progress and problems. There should be enough detail so people can follow along but not so much that it gets bogged down in technicalities. It shouldn’t be “The same as yesterday” or “Networking stuff”. Nor should it be a list of ticket numbers ticked off. It should be a little summary of your day that can be understood, even if they’ve been away for a few days. That might take a minute or two. If it takes five minutes you’ve probably gone too far.

Beforehand each person only knew about there own progress and problems. Now everyone knows, at least a bit, about everyone else’s. An individual might be stuck but someone else in the group may have seen this before. Even if it’s not exactly the same it can spark a memory of something similar. As new components are added to the system everyone can hear about them. Maybe that’s just what they need to have as well.

Hearing about your colleagues progress gives more flexibility to the team. I’ve often been asked to provide information or expertise when someone is ill or on holiday. As I already know, roughly, what their situation is I can either provide this immediately or get up to speed much more easily.

Retrospectives

I talked about retrospectives as part of my first blog retrospective, read that for the full story. Typically the questions for everyone are something like “What did we do well?” and “What did we do badly?”. I thought it might be better to have:

What happened?
Was it good or bad?
What to do about it?

The first question is simple because it’s the same as the daily stand-up. That set us right up the second question: are the those things good, bad or somewhere in the middle. Finally what should we do about all of that. Generally speaking, try to encourage more of the good and less of the bad. That may or may not be possible. If someone has been ill for the entire sprint that’s bad but you can’t really control if someone is ill. However you could try:

Ensuring that more that one person is qualified to work on a task.
Improve document on the tasks and the project so someone else can get up to speed faster.
Allow more slack in the schedule to account for illness.

All of those would reduce the impact of future illness and give more flexibility but, unfortunately, slow things down in general. You have to decide which ends up costing more in the long run. A fairly typical two week sprint means all tasks are recent, details are less likely to be forgotten. There’s a chance to change things rather than continuing with a broken system.

I think the retrospective is mostly like to fail in actually turning ideas into actions. Deciding that you should improve documentation is one thing, actually improving it is another. It could be that ideas aren’t translated into tasks or it could be that there is no time or priority or inclination to carry out those tasks. Coming up with ideas can certainly be easier than carrying them out. I suggested part of the retrospective process should look back farther than the last sprint to monitor this.

Planning

After you reviewed the last sprint it’s time to plan the next sprint. The team keeps a product backlog which is a prioritised list of tasks. Generally speaking the highest priority tasks are transferred to the sprint backlog to be completed next.

In order to do this the product backlog has to be kept in order. This requires that new tasks are given an appropriate place within the backlog. Old tasks may also need to be re-prioritised sometimes as requirements are refined or circumstances change. Regular sessions between the product owner and developers should ensure this reflects the needs of both sides. Tasks may initially be created that are large or vague. However as they rise up the backlog they must be broken down into smaller tasks and fleshed out.

I would like to experiment with an outer and inner backlog, essentially one backlog for each side. This would remove unnecessary implementation details for the product owner view, showing the big picture. Meanwhile the developers can concentrate on that implementation detail and how to best achieve the overall goals.

Tasks are normally estimated using an arbitrary “points” system. At the start of the project their is no direct translation between points and time. Small tasks are given small point estimates and large tasks are given large point estimates. After a while, when more tasks have been completed, the average relationship between points and time for this team and project will appear. The average number points completed over the last few sprints may be calculated and known as the “velocity”. This can be a good way to control how many tasks should be scheduled for each sprint. Don’t expect velocity to be exactly the same from sprint to sprint and do remember to account for holidays and similar things.

Some people take the sprint backlog as a set of work that should be guaranteed to be completed in the sprint. I don’t think this makes sense. If you have to complete all of these tasks then the likely response is to pick fewer tasks, even if you can probably do more. I would take these tasks as a goal, ideally you’ll complete or make substantial progress on them. However if you’re normally left with a lot of unfinished tasks at the end of your sprint you are probably picking too many.

As much as possible tasks should be designed such that they can be completed within one or, perhaps, two sprints. If tasks are regularly overrunning then splitting them up is desirable. Sometimes they can be broken down into sensible parts. This could include things like investigations, prototypes, implementations, documentation phases. If not then breaking them into a number of arbitrary phases may help. The overall task may not be finished but at least everyone can see that phases have been finished.

In the end

I’ve certainly given Scrum a better write up than the Agile Manifesto. I think the structure of Scrum helps drive communication and gives concrete direction. In contrast the Agile Manifesto is exceedingly loose. It might work, it might not. It very much depends on the specifics that actually get used. I feel individuals are too liable to error to rely on it all just working. On the other hand a strict set of rules from an official Scrum manual might not be what your team needs. In the end these system provides tools and you need to pick the right tools for your job.