First of all, I admit I do not consider myself an expert in Agile Methods. Yes… I’m a Certified Scrum Master and I’ve been involved in several agile projects. But let’s say I don’t know enough and have enough experience to consider myself an expert. Even with this, I will dare say which are the issues that I don’t see addressed correctly in these methods, or at least in the typical “Scrum + XP” combination that used in most cases in Industry. The risk here is that someone will quickly reply with a link to explain how these issues can be solved. Oh well… I’ll take that risk.
I also want to say in advance that in general I have a positive view on Agile methods. I think they are an interesting packaging of useful practices and that they have made a huge contribution to development practice in general. I also value some new practices like TDD and Continuous Integration that have provided smart answers to increasing challenges of software development.
So… here goes my first critique. It’s to the idea that every sprint has to generate a “Potentially Shippable Increment”. To be honest, even after reading some posts by Ken Schwaber and other experts about this, I still don’t get why they are so rigid about this. There are many reasons why you would want to do something in a sprint that is not even close to shippable, no matter if it has the word “potentially” in front of it. One of them might be that what you have delivered is a proof of concept of a feature that needs more work, or you are working on a very complex functionality and are only showing to your product owner something that does not make “business sense” yet but is pointing to the right direction, or your sprint is so exploratory as you are very early in the development cycle that the presence of bugs is not a problem, or that you’ve decided to partition a complex functionality in two or more sprints. I would be more flexible here… saying something like “Test and make your product as shippable as you need to in each iteration, according to business needs”, combined with “Try to have your product make business sense as soon as possible in the development cycle”. This shouldn’t be an excuse for delivering poorly tested code. It’s just something more flexible and realistic. If a product owner needs shippable increments in each sprint, then go for them. For me, it’s just another business goal that has to be discussed in the corresponding sprint planning meeting. Another thing related to this that should hold true in sprints is something like “If you are developing a potentially shippable functionality in a sprint, it shouldn’t be accepted unless it’s really shippable (DONE) when the sprint is over”.
Bottom line is that I don’t like rigid positions to respond to common development mistakes, as they can induce to other dysfunctional practices.
Yes, I’ve chosen to interpret the word “potentially” in the way that fits with my own opinions
Just because something is “potentially” shippable doesn’t mean that it would be rational for the product owner to “ship” it. I think “potentially” means that the stories in the sprint have been completed and tested – the emphasis behind “potentially shippable”, I think, is that stories get “done-done-done” and that they were well-defined in the first place as bits of value-added functionality.
If you have an area of functionality that will require a bunch of stories and several sprints to complete, then it is “potentially” shippable each sprint if the stories in it are done and don’t throw errors and don’t leave the database in a funny state, etc. Even though it is “potentially” shippable, a rational product owner won’t *choose* to ship it, because the meaningful group of functions hasn’t been completed yet.
That’s how I choose to interpret it …but maybe someone should ask Ken Schwaber what he really means
I really tend to think this shippable requirement is very good to focus the developers on closer product releases, focusing on the sprint functionality and testing it.
Sometimes as you said, looks pretty complex to create a shippable product, but I will even consider working unit testing over some “non” visual functionality to be a modest shippable product just because it works as expected.
Leo!
One interpretation I make about producing a “potentially shippable product” on every sprint is that the product should reach a state at the end of every sprint that at least gives the product owner the chance to make the call. If you take that away from the product owner, some new dysfunctions may present themselves.
I agree that most often than not it will not make sense to ship the product, but there are many “potentially enjoyable benefits” as well. For example:
1. To lower the anxiety of the sponsors by showing them the progress and have them keep funding the project.
2. To give a periodic sense of fulfillment to the dev team.
3. To have a product always ready for a demo if you have to make a sale.
and last but not least: To actually ship it.
Hi Santiago!
As have being said, there are good reason to make a big effort to make it “potentially shippable”.
Let me change the angle: agility is based in common sense. There is no ‘Agility police’. You will not fail the next appraisal
Bottom line: if it seem reasonable to the team, just do it. (regardless of what authority say: book, authors, gurus)