[Guest Post: Sean McHugh is one of the ScrumMasters at Axosoft, a software company that make OnTime (industry leading Scrum software). He gets to work with customers who are brand new to Scrum and also with experienced customers who are beginning to implement a scrum project management software solution for their development teams. He loves working with teams from around the world, who each have their own unique challenges and solutions. He shares his thoughts and experiences with the Scrum community via his Scrum blog.]
Iterating is Core to Success
An iteration has long been the thumping heartbeat of most products that are made. This isn’t even unique to software products, almost all products iterate and improve over time, and it’s why we have cars with more efficient and powerful engines nowadays. It’s the reason why my television is thinner and lighter than the one I grew up with.
Iterations are also the core of what makes Scrum work and people sometimes miss the nuance of me saying this. I didn’t say that iterations are the core of what makes the product work; they are the core of Scrum.
Let me explain what I mean:
When you complete a sprint (the aforementioned iteration) you should typically demonstrate it to the Product Owner but also take some time to retrospect on the sprint itself. The retrospective on the sprint has little or nothing to do with the product and instead centers around the team.The retrospective essentially answers the question of “Why did we do so well/bad on this sprint and what can we do/do more of to improve on the next on?”. It’s an important question that I feel is sometimes answered too easily with canned answers such as organizing the product backlog into epics/themes/stories or to switch to some form of relative estimating or to implement some other type of canned solution that the Scrum/Agile community has judged as a universal good. I’m not saying these things are bad, I’m saying that there’s no such thing as a universal solution for any team impediment because each team is unique and will react to things in different ways.
This problem is further compounded by another thing. The vast majority of teams I work with, implement seemingly universal concepts in Scrum and Agile differently. If you get a chance, shadow another ScrumMaster at another company some day just to see exactly what I mean, when I talk User Stories with someone the first thing I do is stop them to find out what their definition of that word is. This is not to say that their definition is wrong or that they could be doing things better, what it means is that good Scrum teams will shape their development process to fit the team rather than molding the team around some preconceived notion of Scrum or Agile.
Let’s talk about an anonymous game studio I worked with a while ago. About midway through development they found that their sprint reviews were seemingly lackluster and unproductive. Instead of providing valuable insight into the product and it’s needs from the product owner it was instead being seen as “time we could be spending on the game.” Now the Scrum Guide clearly states that a sprint review needs to happen after every sprint. The problem was that the game was undergoing nightly builds and those nightly builds were being continuously play tested and the product owner was providing feedback directly to the team (sometimes too much feedback but that’s another story). The answer was seemingly obvious; stop doing sprint reviews on every change in the sprint since any product feedback was being gathered on a daily basis anyways.
Now some would label this as “Scrum But”, as in, “We’re doing Scrum but we’re not doing sprint reviews.” I would label this as good solid Scrum, the difference lies not in the fact that the sprint review isn’t important (it is) but in the fact that this team understood the reasoning behind it, was able to understand why it didn’t fit in with their team and then cut it out. Also important to note that they measured the effect of this on the team and the product over the next couple of sprints before deciding to permanently remove the review.
And this is where the iteration and the retrospective come back into play. We often talk about Scrum teams implementing Scrum “by the book” becomes the baseline and with each iteration of the product (and with each retrospective), the team should gradually change their process. The results of each change should be closely inspected for positive and/or negative effects on the team’s velocity and if positive that change may be adopted permanently (until it comes under the microscope again during some other retrospective).