Hi all! I know it’s late but happy 2015! Thanks for sticking with me as I know that (once more) it’s been a little while between drinks. I could blame Christmas / New Year and a super hectic beginning to the year and so I will ☺
Anyway, when I left you last we started to bust up some of the more common Scrum myths starting off with some terminology myths. In this second post we’re going to stick with ‘terminology abuse’ by exploring the next most well-known and misrepresented Scrum term, that being ‘Sprint’ which of course is the Scrum equivalent of the more agile-generic term, iteration.
Sprint for distance not speed!
Now please tell me, what does the term Sprint conjure up in your minds when you hear it? That’s right, the idea of working at breakneck speed and at an unsustainable pace. The problem with that word is that it has given birth to the dangerous myth that Scrum teams should work considerably faster (straight off the bat) compared to more (so-called) ‘traditional’ teams. Now this perception may well unfortunately contribute to the high agile adoption figures that we checked out in the last post because show me a stakeholder who doesn’t want a team that works considerably faster? The fact of the matter is that Scrum actually promotes sustainable development practices as described in the 8th principle of the Agile Manifesto.
The term Sprint should be associated with distance and focus rather than speed, drawing the comparison between the shorter sprint race and the significantly longer marathon (that seems to go on and on with no end in sight). The Sprint allows teams to regularly pause, take a breath, check the road ahead and inspect and adapt to ensure they haven’t strayed onto the wrong running track.
Faster business value is more like it…
That being said, while Scrum teams may or may not go faster than ‘traditional’ teams, (in absolute terms), what a Scrum team should be faster at is reducing the lead time in the delivery of the highest value end to end features. This is due to the focus on building prioritized, vertical increments or slices of functionality, with quality being constantly and consistently factored in (rather than it being treated as a hopeful afterthought that occurs too late at the end of a long marathon effort).
On to the next one!
Once again, I thank you my fellow mythbusters for joining me on the second leg of our truth-revealing journey. See you next time when we tackle the next Scrum myth!