Fast development vs Agile development

In the past few years i have encounter the same issue in so many different companies and so many different projects, regarding the area or scope of the project, regarding if it was an stable and profitable software solution or an start-up, regarding the experience of the project manager; the battle between fast development and agile development its the biggest issue in today development teams.

Fast development

The concept of fast development is so false as its name, but let start asking why is this requirement even born.

The quick answer is a false attempt of apply Agile development. When you are required to deliver software solutions ASAP you are basically required to “fast-develop”, but its that right?

On projects on the category of start-ups, the budget its limited and in so many cases are really small, so the client always want to deliver more with less money and faster as light.

Most of the time in this “fast-develop” attempts, we, as developers; are force to code without testing, without design patterns, without research on the state of the art on what we are doing and even without common sense.

As professionals we should not accept this and deliver software solutions with great code quality, software solutions that can be easily extensible and flexible to changes.

On my personal experience, at so many cases i was put under this circumstances and force to deliver code with so low quality that 90% of the time requires refactoring and a lot of debugging. Shame on me.

That was not fast development at all, the main propose of the “fast-development” its try to deliver software solutions that works, and hopefully wont break. But how can you accomplish this with so poor design and cero good programming practices or principles applied?

The answer its clear, you can’t.

Agile Development

Agile does not mean fast, agile is about moving quickly and easily.

At software industry agile means to build the software solution step by step, delivering value at each step but taking all the measures to deliver it right.

That means, take the time to research, the time to design, the time to apply good programming practices and principles, the time to take choices with care, to think on value, to build good software solutions.

Its actually accountable that projects build upon Agile are in fact faster that those who use “fast-development”.

I took this little experiment on one project some time ago. I was team lead at the time and the team was using or at least trying to use SCRUM, so i begin to measure how fast the team was: based on if the team delivers or not on each sprint and how much fix of that value need to be re-introduce on the next sprint. The result was on a 40%-50% of that value, so in terms on how fast the team was the answer its cristal, only %50 fast.

So with that results over 4 whole sprints i propose a plan to actually be agile and deliver a good value for the same time as the first test, notice that the project was the same, an the team was the same, only the strategy changes. We now schedule time to discuss the solution, to research, to apply design patterns and to test the code. The measures where the same as the first scenario. The results where amazing, the team was 30%-40% faster at the first sprint, 40%-50% faster at the second sprint and 50%-60% faster at the two last sprints. Given that the team was force to think in another direction and we where working with a really bad legacy code, the results where amazing, the team was able to increase the speed at the end.

So what happens, the team keeps working on that bases and having a good retrospective at the end of the sprint, trying to look at sings that may lead to use the bad practices.

So as Robert C. Martin (Uncle Bob) advice on so many of his books and conferences:

By been agile, by applying design patterns and test your code; you will actually been faster by been slow

At the end even on those start-up projects with very limited budget use agile will provide a solution that ensure the quality that the client was expected from the start.

Conclusion

I know that much of this have its roots on professionalism and experience, but we should always look on better ways to do things, to build things. We need to encourage our self to battle and discuss the right ways, that is what make us professionals in the first place.

As a Software Engineer and as a Professional i toke a personal stance to explain, advice, educate and finally agree to code using Agile Development delivering software solutions at the greatest quality i can.

Advertisements