In my previous post, Thou shalt deliver software early and continuously, I replied to a blog post by Kishore Kumar about the agile principle: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Kishore subsequently left a comment on my blog post and posted a response on his blog.
In his comment and follow-up post, Kishore compares scrum sprint builds to alpha releases in a waterfall project. I agree with Kishore to a point: one purpose of both sprint builds and alpha releases is to solicit customer feedback before the end of the release.
But the similarities stop there. In my opinion, with alpha releases of waterfall projects, the developing company is demonstrating that it is set to deliver what it committed to months before. With sprint builds of agile projects, the developing company is showing the customer that it is delivering what the customer wants.
With an alpha release near the end of a months-long waterfall release, the customer is seeing completed functionality for the first time near the end of the release. The customer has a lot to digest in a short amount of time, and there is little time to incorporate customer feedback or changes before the final release. In my experience with alpha releases, the level of customer feedback that's actually acted upon before the final release is typically limited to fixing major bugs that the customer uncovers.
With sprint builds, however, the customer gets to try out the new functionality in small chunks throughout the release, and, especially with the earlier sprints in the release cycle, there is ample opportunity for the development team to incorporate customer feedback into the final product.
I promised Kishore that I would discuss some specific benefits that Borland derives from sharing sprint builds with customers, but since this post has already gotten pretty long, I think I'll save that for my next post.
Comments