Interesting article, our projects continue to suffer a lot from context switching and from developers who are interrupted throughout the day.
I’ve just seen this post on Chip’s blog. He questions whether 30 days for a Sprint (which is what the Scrum process recommends) is perhaps too long, I’ve always thought so myself and in fact, if I remember rightly, Mike Cohn suggested 2 week Sprints on the Scrum Master Certification course that I attended.
When I ran the project before Christmas I used 1 week sprints, I deemed them to be appropriate as it was for 8 weeks and so I wanted to establish a rhythm within the team very quickly as well as provide feedback to the client as soon as possible. This placed the team under an immense amount of pressure and as Chip rightly says almost promotes a feeling of chaos.
What is also interesting is that we have a couple of teams that are permanently involved in a programme of project work relating on two of our biggest applications. Whilst those teams are primarily focussed on the development of new features they also have to handle the support calls that we receive that pertain to those systems.
The two teams in question have recently decided to implement Scrum, however, rather than the 30 day Sprints that the traditionalists suggest they are using 10 days. As I understand it, they have approached the problem differently with one team opting to roll the support calls in to their Product Backlog and the other having established a separate team that handles the issues.
I’ve also given consideration previously to how an Agile approach might work in one of our SAP development teams. About 6 months ago a live issues team was created to work through the backlog of bugs raised by the business. I think the Scrum model could be extended to manage the release of fixes and ]the business priorities within those. This is of course, always a little more difficult when there are multiple business owners, one method that I have been made aware of for dealing with this though is to allow a different member of the business to adopt the Product Owner role on a rotational basis for each of the Sprints.
For me though, I think 2 weeks feels about right for the length of an iteration. It doesn’t put the team under an undue amount of pressure nor does it extend the feedback loop by too much.
We’re now in Tofino, Vancouver Island, having driven over from Whistler on Sunday typically, just as we left it started but we had decided that the season was over and packed our boards away already so there was no turning back.
Before leaving though, we did get a chance to experience the lifestyle in Whistler. We had moved to new accommodation when James left, the plush Summit Lodge and Spa and as it was the weekend we decided to take a day off to carry out the necessary admin tasks etc.
We walked over to the Nesters area, ably guided by Tom Tom, of course (we couldn’t have gone a day without tech now could we), dropped our stuff off at the laundrette and then grabbed a latte and sat in the morning sun. I then took myself off to the salon for a hair cut before we decided it would be sushi for lunch. Having sorted the washing out it was back to the coffee shop for another latte and some carrot cake. We then wandered in to Whistler Village for a bit of retail therapy followed up with some beers later that evening.
The drive to Vancouver Island took us through some amazing scenery, not least of all when Tom Tom guided us down about 12kms of forest service road. We spent the day on some hire bikes yesterday checking out the various beaches and some of the town which was cool. Tofino is apparently a renowned surfing spot and from what I have seen of the breaks I couldn’t argue, they’ve been quite impressive.
An interesting article that discusses the various types of stand up meetings and summarises some of the papers that have been written on them previously.