A friend and an ex co-worker of mine sent me a few days ago a post on the death of Agile – The end of Agile. Since then I did some research on the subject, and indeed there are quite a few who claim that Agile is either obsolete, abused or simply doesn’t work and fit the current industry. I will try to write in a series of posts my view on the subject, referring to other blogs and articles. In this post I will try to explain why I think the post above is somewhat missing the point.
Hayim Makabee, the author of “The end of Agile” claims there are a few myths that Agile consultants believe in, which underestimate the complexity of software development. His list includes statements like
“Good design will emerge from the implementation of user stories”, “It will always be possible to pay the technical debt in the future” and “Constant refactoring is an effective way to produce code”.
I wouldn’t say that any of these are accurate phrases of Agile thinking. First of all, I would claim that “A good design will help the implementation of user stories” and not the other way around. Whenever we need to implement a complex feature, my experience shows that taking the time to design it is a necessaty to have good results. Usually the design yields the idea of how to divide the implementation into steps or user stories, which in turn can be executed in a sprint.
As to always being able to pay the technical debt – I must admit I never heard this phrase before. Technical debt is just one way of relaxing the scope of a feature so that you can implement it in small bites and iterations. Nobody I worked with ever claimed you can always pay the debt in the future, nor was glad to add more debt. In certain circumstances, there is no choice but to avoid a few known issues, some of them technical, and put them aside for future implementation. This is not an easy decision, nor is it one that you are glad to do, but it is something that reality forces you to always consider. Just recently, in SQream Technologies, we faced a problem of either adding additional technical debt to the backlog and finishing the work on time, or doing the work “right” and delivering it late. This was no easy decision, but both R&D and Business decided to go with the former, because of the need to finish on time. You could even argue that it wouldn’t matter if we were using Agile or not, the situation and decision would be the same (the need to deliver on time is not coming from a sprint or any other Agile concept, but from the business needs), however I would think that if we were not using Agile, R&D would probably decide to work “right” and eventually, in some future day, Business would learn that this is the case and that there is nothing to do but to delay the time to market. Having the ability to decide on this together, by putting R&D and Business together in one team, is one of Agile’s biggest advantages.
As to constant refactoring – again I would argue that in all my career, I never heard someone say that it is one of the most effective ways of coding. Refactoring is sometimes needed. It may be needed because of bugs. It may be needed because of changes in the technical aspects, or business aspects, that were not foreseen and it may be needed because we were in a rush. I agree that the Agile mindset does allow refactoring as another tool to cope with the timeline and the time to market, but this is just another tool in your toolbox to choose from. Having more tools is better than having less, as long as you know when and how to use them.
Hayim finishes his articles, stating the following:
In my personal opinion, we will have to go back to the basics: To all the wonderful design fundamentals that were being discussed in the 90’s: the SOLID principles of OOD, design patterns, software reuse, component-based software development. Only when we are able to incorporate these basic principles in our development process we will reach a true state of Agility, embracing change effectively.
This is where I think Hayim, and others, are getting it wrong. In my understanding, Agile never said to stop designing, stop using patterns or reuse code. It just says to use them in the appropriate place, at the appropriate time, and in iterations where possible. In my opinion, we were always able to incorporate them in our development process. This doesn’t mean we are doing it the best way possible, there is always how to improve, but we never said to stop doing them just because we are in a Scrum team. Agile makes you think more about what to do and how to do it, giving you more tools to use but seldom requires you to let go of a tool or process.
It is true that Agile can fit very well when working on very simple software projects. It is also true that almost everything would work in such simple projects. Saying Agile doesn’t fit in complex projects is, in my eyes, misunderstanding the true meaning of Agile. But let’s save that for another post in this series.
Now I am the Master 