Some problems I see in Agile Methods – Part 1

Some problems I see in Agile Methods – Part 1

First of all, I admit I do not consider myself an expert in Agile Methods. Yes… I’m

Some problems I see in Agile Methods – Part 1First 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 is used in most cases in the 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 of Agile methods. I think they are an interesting packaging of useful practices and that they have made a considerable 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 that you are working on a very complex functionality and you are only showing to your Product Owner something that does not make “business sense” yet but is pointing to the right direction, or that 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 a 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.”

The bottom line is that I don’t like rigid positions to respond to common development mistakes, as they can induce other dysfunctional practices.


Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.