First of all, I admit I do not consider myself an expert in Agile Methods. Yes… I’m
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.Go Back