Agile, emergent design, and bugs!
Before saying anything bad about Agile, I do need to recognize its virtues. Software development is time-consuming, and having a methodology that accounts for continuous release, continuous adaptation for the market changes, and quality control of small iterations… well, it is both ingenious and necessary.
However, as I describe in my book Professional Front-end Architecture, most of the Agile methodologies and their resources seem to entice a bad feeling about planning. They don’t forcibly raise against it, but use terminologies and promote practices that, in the end, is unfavorable to planning. What comes in place, though, is what most of their authors call “emergent design”, which in my opinion is a very misleading concept. In reality, that emergent design should be called “chaotic design” or “the no-planning approach”.
But not all is lost. Also in my book, I discuss many ways that we can elevate the amount and quality of planning, within realistic and desirable levels, while keeping Agile alive. Actually, that increase in planning leads to a significant reduction of bugs and on costs with later changes, which not only is compatible with Agile but help it reach its full potential. In other words, planning is not opposite to Agile but is an instrument to keep it alive.
I’ve seen many people (in real life) and articles (online) talking about the “downfall of Agile“. The problem most frequently presented is that, if by one side Agile was promising rapid software development and high adaptability to changes in the environment, on the other side it seems that it brought back the “software crises“, where creating the final product turns out to be more time consuming, and maintaining it is many times more costly than creating it. In other words, the planning that most of the methodologies proposed to solve the software crisis, especially in the 1980’s, is now damaged by the attempt of speeding things up with Agile, and therefore bringing back some of the issues it tried to remediate.
Unfortunately, a simple article like this is not enough to explain “how” the planning should be done, so it doesn’t become an unrealistic set of instructions that only hinders development and adaptation. It took me a whole book to achieve that. The goal here is to remind this simple truth that planning is still necessary to help reduce the time and money spent dealing with bugs and changes. This would be an irrelevant reminder if it wasn’t by the fact the most front-end shops, developers, and managers just go through the motions with the Agile methodology, without questioning how it could be hurting them in the long run.
This article really is a call for a critical evaluation of Agile, and how it is affecting most of the established and new best practices regarding planning. It is also a promise that there is a way of planning that actually favors Agile, promotes quality, reduces costs with changes and bugs, doesn’t affect development speed, and doesn’t become a roadblock to the programmers. Read more about it here!