iPassion

When agile methodologies are applied in full, a project it’s rarely a failure. But while transitioning from traditional development to agile, there are a few scenarios in which the “agile” label can be seen by the customer or the project manager as a magic formula.

The typical scenario in traditional development is that people expect the space shuttle for 1000$. An evolution of this scenario in agile is that people expect to get to the moon in one iteration. With all the buzz around agile, people think that you can get a fully custom web app in a matter of weeks, polished and ready to launch, in one “sprint“.

Well, that is usually not the case. You can get a usable product in one sprint, prioritize features, and get to the market in less time with a nice product. But you can’t expect that all aspects, features and requirements are met in the first version of the product, especially if it’s a feature reach web application or a hosted service.

Recent web apps history has taught us that “less is more”. That is very true so keep it in mind when you envision your product. You can have a ton of features in your backlog but you don’t need to wait until all your vision is implemented into the code before launching your product. Prioritizing features does not mean that “some will get there in sprint 1, some in the following” — it means some features won’t make it to the final product.

A nice quote about this is that 50% of the features that are implemented at 100% are a success, while 100% of the features at 50% are a failure. This won’t make your product less attractive, it’ll make it more focused and specialized, easier to use for early adopters and will leave space for growth with faster return of your investment while keeping all within your budget.

The worst scenario though, is when people don’t have clear goals. I’m not referring to requirements, we’re used to work with very little written requirements and even those are not carved in stone. I’m referring to what you want to achieve with your product. If you don’t have a clear target, a clear vision, or at the very least a clear need you want to satisfy — then that is a real issue for us.

Changing your requirements to meet your goals is manageable, because you, the project manager and usually most of the developers involved (the “pigs“) get the big picture and can help and foresee those changes, or even propose some themselves. Changing your goals when the product is on its way means changing the big picture, and the risk is it’ll disrupt the “symphony” between all team players, demotivate the developers and make it a really difficult project to manage.