Over the years I've seen many types of team. Some teams believe that they have to cram as much in to a sprint as possible and work up to the 11th hour to get it all done. I used to think that way too. This can lead to, amongst other issues, the team working too all hours on the last day of the sprint. This is especially true if there have been unforeseen issues.
If you're able to do that successfully each sprint then more power to you, but I prefer a slightly different approach.
Though the term sprint suggests that we should hurry though as many stories as possible (while meeting the definition of done), I view the sprint as agreeing to a set of stories and creating them the best way you can. i.e. making them awesome (I know that sounds a little cheesy but couldn't think of a better word).
The approach I prefer is to build a little slack into the sprint. This means that the final day can be used slightly differently.
A little slack gives the team some time for innovation and learning, plus allows preparations for the sprint review. It also gives a little break from the constant slog.
Some people may consider this waste as it's time that could be used to potentially work on more valuable stories, but I look at it as making the product and the team more awesome.
What do you think?
Hi James,
ReplyDeleteMakes sense to me, although ultimately it's what you do with that spare time that matters. How do you clarify it's not waste to someone paying your wages? So defining what it can, and can't be used for I feel is important.
In my last job we had a thing called build camp. Everyone could work on an idea at the end of a release for 1-2 days. The idea could be anything, and didn't have to be completed, but it had to be useful for the product in some way or another.
I used my first build camp to write an automated CTI installer (covering five different CTI providers), which used to take about 1-2hrs to setup each time I needed to use a provider. That was really helpful for me, as I had to use these various providers at least once per week.
Some people simply investigated new 3rd party libraries, to see if they could be useful for us in the future. Sometimes this turned out a few gems that we might never have considered, in a deadline focused environment.
The thing I liked though, was that everyone had to demo at the end of the camp, what they had done. So obviously if management / stakeholders liked their projects, and they still required some work to reach completion, they'd likely make it into a future release.
Nice post, thanks for sharing.
Darren.
Hi Darren,
ReplyDeleteThanks for the feedback. I completely agree, this time has to have some value to the company. This isn't time for just goofing off :) As you said above, defining what this can/can't be used for is essential.
I like your idea for a build camp, especially having a review/demo at the end. It adds a level of transparency and gives people focus.
Cheers,
James
Slack is not a four letter word - http://itsunderstood.com/2011/04/contrary-to-popular-belief-slack-is-not-a-four-letter-word/
ReplyDeleteI find a little time for reflection is invaluable