We are just into the second week of our first Sprint. I’d been waiting for this for a while, and so it’s been fantastic to no longer just read about Scrum and Agile, but actually start doing it.
In terms of completing what we said we were going to, I’m pretty sure we are going to “fail” our first Sprint. In terms of what we’ve learned about Scrum and about ourselves, I think it’s been an outstanding success. There’s been two big things I’ve really noticed over the last week and a half:
Everything really has become very visible – the little problems you didn’t realise you had come up even more quickly than you imagined they would.
The development team are working together more than I’ve seen happen … well, ever. Not because anybody told them to. They just did it.
I’ve talked to other people using Scrum and I think that overall we were pretty lucky. I had a lot of time to immerse myself in learning about Scrum before we started, we have a fantastic team that have really bought into the methodology, great support from management, and a whole new project to try out the new techniques. The biggest impediment we’ve got right now is that the team is not yet complete: two new members will start over the next two weeks and the last one will move from Paris in August.
I fell into a lot of traps this Sprint Here are some of the things that have already come up. Many of them are completely obvious … Duh.
- To start with, I forgot that we should update task “hours remaining” estimates in Daily Scrum. So, our initial burndown was pretty rubbish. This was easily fixed though.
- I also forgot that Daily Scrum isn’t just about reporting what Sprint tasks the team have worked on. Saying “I haven’t done anything on the Sprint tasks in the last 24 hours” isn’t enough. What were you doing then? I was wondering why I wasn’t identifying many impediments. This is particularly difficult since two of our four team members are not 100% dedicated, sometimes it’s difficult to determine what is an impediment and what isn’t.
- I don’t feel like we scheduled for time OOF (holidays and training), conflicts with other meetings, and other big events very well. For example, there was a major release of the website across all of our points of sale in the middle of our Sprint. We didn’t think enough about what preparation work we’d need to do for that, and it bit us on the a** pretty hard. Ouch.
- An interesting thing that came up today was that our testers wanted to extend the scope of one of the test stories (building part of an automation framework) even though there was a lot of outstanding work on other stories. Being a new team, we aren’t very cross functional – not at all really – so the question is what else are the testers going to do? I jumped at the chance to wear my mean ScrumMaster hat and asked them to figure out how to work on one of the other stories, which had some test work to do on it. As a result, we figured out that there was an impediment there because they didn’t have a server available to test on (urgh – another major impediment right now is that we have some major hardware availability issues. We have been promised some this week, so we’ll see). I think we have to work on this understanding that we commit to the stories and then try to finish them.
- I feel as if I’ve tried to lead the team too much in this Sprint – in Daily Scrums, I feel as though I’m the one asking what have you done on X? How much is left on Y? Why can’t you do Z now? Perhaps that’s OK since it was the first one and I’m aware that over time they need to ask each other that. I’m hoping that over time the team will self manage more. On a positive note, they have been waiting at the whiteboard for Daily Scrums, which was great. We only had one instance of people being late and that was due to a conflict.
Although our story estimates were owned by the group, task estimates were done individually. And some of them were pretty atrocious. I want to try and encourage more of a group effort next time.
- I think to some degree we’re still doing “design-dev-test” – or mini waterfall in Sprints. There’s a big division of work, and as a result we’ve still got five stories in progress and none complete. Over time, I want to try and change this so that we work on stories together. In the first Sprint though, I don’t see this as a big problem.
- Some of our technical stories were pretty vague. Like “fix bugs” (we had some old bugs) or “I want to automate testing using a framework”. This means we had lots of wiggle room but we don’t really know for sure when to stop and say the story was complete. We’re learning though and we’ve added new stories and set up ways to manage and triage bugs.
- We need to be more prepared before Sprint planning meeting. We spent quite a bit of time defining new technical stories and estimating stories with missing estimates in Sprint planning. That said, our planning meeting didn’t run over time, so it didn’t cause a huge problem.
As well as the teamwork, there have been some real positives and things we’ve done that have worked really well:
- Having a taskboard with post-its and holding Daily Scrums around it worked great. The meetings are short and snappy and having a daily update is fantastic for visibility – I learn more in those fifteen minutes than I could from an hour reading a spec.
- Creating a product development roadmap has really helped to prioritize stories and create an end goal.
- Estimating in Story Points has been working pretty well. Planning poker is actually fun, and the team adapted really quickly to questioning each other’s estimates. I think with the benefit of one Sprint, triangulation will get even easier.
- Just talking about what we are developing instead of completing set documentation is really beneficial – everybody has a far better understanding of how things work. We don’t have prescribed spec reviews, we talk face to face on an ad-hoc basis.
I could go on for hours that covers the main things so far!