© 2012 William Patrick Swisher
Mike Cohn of Mountain Goat Software recently posted a blog article titled “The Rules vs Generally Accepted Practices of Scrum” where he asks his readers to comment on various techniques used in their practice of Scrum.
The title itself was intriguing because it reminded me about a coworker from a previous job who was very rigid in his thinking about implementing Scrum in a software development organization. Don’t get me wrong, he was very experienced and talented, but had a certain inflexibility in his approach that made it challenging to try new techniques.
I believe, and this is especially true when an organization is undergoing the transformation from Waterfall to Scrum, that so long as you adhere to the basic ideals, not just The Rules, any number of techniques can, and should be tried in order to find that works best for each team and the organization as a whole.
For example, the inflexible individual in question would have disagreed with doing any sort of Product Owner review and acceptance of work before the end of the sprint. That just wasn’t done.. it was blasphemy.. it was against The Rules as he understood them.. but at a more recent job, the team adopted this technique for backlog items that were very time consuming to evaluate.
Complex business reports or client facing materials needed detailed scrutiny that couldn’t be done during a time-boxed Sprint Review meeting. To accommodate the need of the Product Owner to be absolutely sure the results were accurate, we provided the completed work as soon as it was ready, even mid-sprint. Sometimes, for work that could not be delivered early, we even demonstrated the completed work during the Sprint Review but formal acceptance was done after the meeting once the Product Owner had the time to evaluate it. As the Scrum Master, I would allow the team to count the completed backlog items as Done and earn the associated Story Points as long as the acceptance came by the end of the day.
We adopted this technique because of the nature of our business where we’re dealing with vast amounts of data and the accuracy of that data counts. If all we built were webpages or easily demonstrated functionality, there would be no need. Being flexible and open to new techniques that ultimately aid in the delivery of business value is what will enable an organization making the switch to Scrum successful.