Agile Scrum, Or Not-So-Agile Scrum?
by Kelly Waters
Scrum is the form of agile software development that has helped me the most.
It has helped me to transform the performance of the web development groups that I've led at both my current company and at my last one.
But, sometimes, I do wonder if Scrum is really agile enough?
There are quite a few regular meetings in Scrum. For short Sprints, this can be quite a big overhead. For me, that's where I can see why the Lean methodology appeals, especially to developers.
But there is also value in these meetings. So I thought I'd take a look at each Scrum meeting in turn, and assess whether or not their value really outweighs the effort?
First, there is Sprint Planning.
Sprint Planning happens before every Sprint. In our case, that's generally every two or three weeks. In Scrum, this meeting is split into two parts...
The first part is to discuss the requirements for all the User Stories intended for the Sprint as a team and give everyone on the team the chance to understand what is required. Questions are asked, and hopefully answered, that give people useful insight into how each User Story will be designed. Ambiguity is reduced and the team, hopefully, gains a common understanding of the User Stories and the requirements for the next Sprint. The collective experience of the team means that everyone gets the chance to input and the quality and appropriateness of the solution is potentially improved as a result. For a 2 week Sprint, this part of Sprint Planning generally takes about 2 hours, maybe less if the requirements for the relevant User Stories are well understood or well prepared beforehand.
Without this meeting, this discussion can still happen ad-hoc as and when someone picks up a User Story to develop. However, the chances are that the discussion will then occur with just the Product Owner, or perhaps one or two user representatives. It will be less onerous than having the whole team involved, that's for sure, but it won't benefit from the wisdom of crowds that you get from the group approach to Sprint Planning. The other thing about this ad-hoc approach is that it's more onerous for the Product Owner. They would need to be available most of every day and at the beck and call of the development team. If your Product Owner is not full-time and sitting with the development team, Sprint Planning is a useful way to ensure sufficient access to their time, and it's a useful way to pre-plan this regular event in everyone's diaries.
Weighing all of this up, I personally believe Sprint Planning is costly (in terms of time) but really worthwhile.
The second part of Sprint Planning can happen immediately after the first part, although some teams leave a day or so's gap between the two meetings, in order to clarify any outstanding questions before going to the next stage. The purpose of this second part of Sprint Planning is to plan the Sprint in detail.
The idea is that the team works together to break down all the User Stories into tasks, and estimate each task in hours. The team then plans their capacity for the next Sprint and decides collectively how much to commit to in the Sprint.
Personally I think it is useful to think about the tasks for larger User Stories, but unnecessary to do this for the smaller or simpler ones. Although Scrum suggests estimating all of the tasks in hours and going through this detailed planning process, personally I think this has some negative effects...
Obviously it can potentially take quite a long time, and with the whole team involved, that makes it an expensive meeting. But I also think - ironically - it can really hinder a team's ability to deliver on time. There are two reasons for this. Firstly, the team only estimates the tasks it can identify. They don't estimate the tasks they haven't identified. Inevitably there are some. Secondly, we all know by now that most developers are hopeless at estimating. Inevitably it their estimates will be wrong.
If you're on a large project, you may have already estimated all the User Stories on the Product Backlog in Points, in order to get an idea of how big the overall project is. If so, I personally think it's much more accurate for the team to commit to how many points they think they can deliver in the Sprint, and stick with that instead of estimating tasks in hours and trying to plan them in detail. In my experience, once a team's Velocity (the number of points delivered in a Sprint) has stabilised, this is a much more accurate way to gauge what a team can deliver in a Sprint, and it takes less time to do. For more information on this, see my post The Secret To Delivering On Time.
If the User Stories being discussed in the first part of Sprint Planning have not yet been estimated in points, I would suggest the team voting on the size of each User Story once its requirements have been discussed. Planning Poker is a great technique for doing this.
So, in summary, my personal view of Sprint Planning is this: It is worthwhile to discuss the requirements for the intended User Stories for the next Sprint as a team. It is worthwhile to estimate the User Stories in points, either when they go onto the backlog, or using Planning Poker to estimate them as a team in Sprint Planning. It is worthwhile for the team to make a collective decision about the amount of points they are able to commit to for the next Sprint, based on their experience of their past Velocity. Whereas breaking every single story into tasks, aiming to identify every task, estimating each task in hours, working out the precise capacity of the team for the next Sprint, and committing based on that, is not necessarily worthwhile. It takes a long time and can lead to less predictability about what can be delivered, meaning the team doesn't deliver on its commitments and people are disappointed.
During the Sprint, the only regular meeting in Scrum is the Daily Scrum itself.
This is where the whole team meets every day to answer three basic questions:
- What did you do yesterday?
- What are you going to do today?
- Is there anything blocking your progress?
This meeting should take between 5 and 15 minutes. No longer.
There is no doubt in my mind that the Daily Scrum is extremely worthwhile.
It keeps the whole team joined up and provides the Product Owner with clear visibility of progress and any issues affecting the team. This is one of the key ways that Scrum helps to ensure that development teams can keep stakeholder's expectations in line with their emerging reality. This is critically important. The definition of a successful project, at least in my mind, is one that meets or exceeds expectations. Therefore I would never personally suggest that a team does not have their Daily Scrum. It's a way to manage expectations on a very granular level, ensuring expectations and reality don't diverge along the way.
At the end of the Sprint, there are two more meetings: the Sprint Review and Sprint Retrospective. These are useful meetings, but because they're at the end of the Sprint, they coincide with the Sprint Planning meeting which is at the start of the next Sprint. Sometimes this can make it seem like meeting overload for about 1 day of the Sprint, which to be honest can be a bit wearing.
The purpose of the Sprint Review meeting is to invite all interested people to come and see what the team has achieved in the last Sprint. If this is kept brief and informal, I think it's really nice for the team to show what they've done. It's also really nice for people interested in the project that can't be involved all the time to see what's going on and have the chance to provide regular feedback. This is another important mechanism to manage expectations in small, bite-sized pieces, which I've already mentioned I think is critically important to the success of any project. It's also a useful motivator for the team to achieve good results in each Sprint, as there will be a Review meeting afterwards so it tends to keep the team more focused on delivery.
And last but not least, the Sprint Retrospective. The purpose of the Retrospective is to build continuous improvement into the regular Sprint cycles. Again, there are three key questions to be discussed by the team in the Sprint Retrospective after each and every Sprint:
- What went well?
- What didn't?
- What will the team do differently in the next Sprint?
Doing these Retrospectives so regularly throughout a project means that the learnings actually help to improve the team's Velocity throughout the project (and beyond). If it's kept simple, the things the team want to do differently in the next Sprint should be actionable and should actually make a difference to the efficiency and wellbeing of the team and the project. There's no question this is a meeting you can't afford to give up. There's just too much value in it.
However, because it coincides with so many other meetings at the start and end of each Sprint, it's important to keep it brief. For a 2 week Sprint, half an hour should be plenty of time to quickly brainstorm these three questions and action any changes in the next Sprint.
So, in summary - whilst on the face of it all these meetings don't seem very agile, I do believe the Scrum meetings do help the team to be agile throughout each Sprint. They help the team to gain a common understanding of what's required, improving the quality of the solution. They help the team to have a common understanding of progress and issues, improving the level of teamwork and visibility for the wider team. They help the team to see what's been achieved, improving the level of satisfaction and helping to manage expectations. And they help the team to learn from past issues and improve on them in the very near future.
My conclusion? Talking takes time. But it also adds value.
Kelly.
For more information on Scrum, see my series: How to implement Scrum in 10 easy steps!
Photo by incase
2 June 2010 15:14
For me,the retrospective meeting has always been the most valueable after the planning sessions.
It's the time when the group can have real input in how the process works best for them leading to a happy and productive team.
Some tips I found useful were to review the previous retrospective to make sure we had actioned points and were moving forward, have an area near the scrum board to put items we wanted to talk about in the retrospective ( I also included people we'd like to thank ) and arranged a darts comp at the end of each sprint which brough both the dev team and the business together.
Like any good manager, listen to your troops, action what you can and they will follow.
5 June 2010 02:34
We do week-long sprints on my team.
We used to run Review/Retro on Wed. morning, and Kick-Off on Wed. afternoon. It was exhausting.
Now we Review/Retro on Friday morning, with Kick-off on Monday morning.
Friday afternoon is dedicated to off-project professional development to keep us all up-to-date on trends.
The Mon-Fri approach has improved morale and productivity incredibly. Doing both sets of meetings in one day is torture.
15 June 2010 12:17
You could argue that the there is only one mandatory meeting that needs to take place in Scrum. It's hardline, but bear with me :)
I think the retrospective is the only essential part of the process as without that you miss the greatest gift - the ability to inspect and adapt. True, the others are important, but here's why I think less so.
Sprint Planning: With a well groomed backlog, I have seen great success in the Pull method, where the stories are pulled in order from a never ending list of must haves. This is particularly useful in large projects where the MVP is way off in the distance.
Demo / Review: With an overactive product owner :) and constant customer feedback on a CI environment you gain little from this meeting in my view other than using it as a tool to focus the team on a deliverable. However, that can be achieved in many other ways, including Cakes.
Daily stand-up - ok, so this is pretty important however I observe much waste in stand-ups. With a team of ten I see no reason why this meeting couldn't be turbo'd to a literal 5 minute experience. 30 seconds each on what (story) they have committed to delivering today, any blockers to that commitment and if they have spare seconds, what they did (of note) yesterday.
I find the amount of downtime produced by the Scrum meeting overheads one of the biggest problems in gaining the buy-in from the board when taking an organisation through the adoption of Agile. Cutting back the fat to bare mussel in this way I think helps to focus the stakeholders on what it is they have achieved with their adoption of Agile - the ability to see everything, and learn from their (organisations) mistakes
6 July 2010 19:59
This is a wonderful opinion. The things mentioned are unanimous and needs to be appreciated by everyone.
thanks
=======================
Technology Details