Scrummin' (Part 1?)
Lately we've been semi-scrumming in the section. We tried to integrate some of the Scrum practices, while ignoring others (the hard ones, you know, like the ones that require management commitment and stuff like that). This isn't so healthy, I know, since the practices were designed to work together; but we're trying to use a sensible subset, in an effort to minimize the "rough edges" where Scrum and our existing methodology clash, and keeping the conflicts away from the team as possible. It's really a Scrum-Pilot; if it works, we might try to sell it to upper management.
So we transformed the end of our last iteration into a sprint, using daily meetings, post-it notes for sprint tasks, and a burndown chart. This didn't work out too well, mostly (IMO) because the sprint wasn't planned as a sprint, but rather converted into one. Consequently, we had vague, long tasks and unrealistic estimates. No, wait. The unrealistic estimates were because we are bad at estimating tasks. But still.
That sprint just ended. It didn't go too bad, but it wasn't exceptionally good either. The post-its didn't do much, since most of them became irrelevant halfway through or before that. But now comes the true test: we're trying to plan the next sprint in the true Scrum way, with planning poker and team estimation and whatever. It won't be true Scrum, of course, since there's a lot we still don't do (we don't have a product backlog, for example) but it'll be closer - and I believe it'll deliver at least some of the advantages I'm expecting Scrum to bring.
We did about half of the planning, which makes this a good time to list some of my impressions.
So. Any tips for a team starting up on Scrum (independently; we can't hire a trainer or anything like that at the moment)? Anybody out there using it? Any good resources on the web?
So we transformed the end of our last iteration into a sprint, using daily meetings, post-it notes for sprint tasks, and a burndown chart. This didn't work out too well, mostly (IMO) because the sprint wasn't planned as a sprint, but rather converted into one. Consequently, we had vague, long tasks and unrealistic estimates. No, wait. The unrealistic estimates were because we are bad at estimating tasks. But still.
That sprint just ended. It didn't go too bad, but it wasn't exceptionally good either. The post-its didn't do much, since most of them became irrelevant halfway through or before that. But now comes the true test: we're trying to plan the next sprint in the true Scrum way, with planning poker and team estimation and whatever. It won't be true Scrum, of course, since there's a lot we still don't do (we don't have a product backlog, for example) but it'll be closer - and I believe it'll deliver at least some of the advantages I'm expecting Scrum to bring.
We did about half of the planning, which makes this a good time to list some of my impressions.
- Estimation. I cannot believe we used to estimate tasks by throwing around numbers in a way that fills the schedule, without even agreeing on the task's scope. I don't know if the new estimates will be better, but I feel a lot more confident in them than in the ones from the last sprint. Scrum or no Scrum, I'm not going to estimate another development task in my life without discussing its scope and getting estimates from as many people on the team as possible, while making sure we all mean the same thing when talking about the task. This is simply a good practice, regardless of what methodology you use.
Possible disadvantages: over-estimation, since each task is unconsciously-buffered independently from the others, which creates an accumulating error. And, of course, it takes some time.
- Material Objects. As a collection of technologists, it's amazing how useful the material world is to the team. Practically everybody said that having tasks up on the whiteboard or on post-its is superior to TFS Work Items, Excel tables or even notepad. Someone even confessed that whiteboards are better because they can be scribbled and doodled on.
This isn't just about tasks; material objects were used during estimation (writing estimates on cards rather than just saying them out loud); design sessions (photographed whiteboards beat Visio and VS Class Diagrams almost any day; this isn't a Scrum lesson, but an Agile Modeling one); meeting organization (whoever holds the whiteboard marker has permission to speak); and more.
In summary, materializing concepts and activities is a Good Thing.
- Missing Pieces. There are a lot of missing pieces, for me and for the team. There's simply a lot of issues that I don't have an answer for. That is expected, since my knowledge of Scrum comes from a single lecture (and some common sense).
For example, we still don't know what to do with unexpected tasks that come up (I'm pretty sure Scrum has a way of handling those, but I don't know yet); How to manage dependencies between tasks; Should we or shouldn't we build a Gantt chart for the sprint (I'm guessing no; I feel that having deadlines makes Parkinson's Law much more probable, and that is a risk considering the over-estimation issue I mentioned. Even though it might be easier on the team leader, I think the team will do just fine without it - provided they actually use the burndown chart); What about tasks which cannot be estimated because their scope is dependent on earlier tasks (right now we're planning to shorten the sprint so that everything that goes in is immediately clear, and the dependent tasks go into the next one, for which we'll have a separate planning session. I firmly believe this is the true nature of a sprint, and thus it's ok to sacrifice the timeboxing for task clarity).
I really should read up more on Scrum.
So. Any tips for a team starting up on Scrum (independently; we can't hire a trainer or anything like that at the moment)? Anybody out there using it? Any good resources on the web?