Heather McLean

Sometimes I wonder if some people just like to follow agile processes for the sake of the process itself. Such is how a heated discussion started earlier this week with some colleages over the topic of Scrum and iterative releases.

There were two sides to the debate. One the one hand, following the Scrum pinciple of “release early, release often” has a lot of benefit and fits will into iterative development. On the other hand, following what the Product Owner says sometimes comes into conflict: “What you did this sprint looks really great, but we want you to add these few things before you release…”

I personally think that the Product Owner should always be able to trump the process in this regard. Just because you produce potentially shippable code doesn’t mean that you should or have to release, especially if the Product Owner doesn’t feel that the current feature set is what he or she wants to release.

A vocal colleague of mine (who also happens to be a Scrum Master) was of the opinion that the team needs to see visible success. His opinion was the Product Owner shouldn’t be able to hold the team back from releasing indefinitely. The longer the “one more thing” attitude continues to proliferate, the closer you get to going back towards waterfall and killing your team’s morale.

I can see his argument, but at the same time enforcing the frequent release schedule like a hard rule just feels wrong. Agile is about adapting and responding to change, and if you can’t change the process to accommodate business needs, it seems somewhat hypocritical.

Of course, I also agree that the business shouldn’t be able to resort to old tactics to delay releases that would be perfectly viable. There has to be some sort of middle ground when negotiating with the Product Owner about what should and should not be released, and that part is where the Agile Manifesto comes into play.

“Individuals and interactions over processes and tools.” This is the part where individuals and interactions come into play. Regardless of whether you believe that releases should or should not be held to a regular iteration, in the end it should be the team’s decision. That decision should include the Product Owner, the Scrum Master, and the rest of the team. This way, you can achieve the result that is best for the business and best for the team.