It is strange that today, on a quick search of the word Agile on the internet, you get two categories of answers: a first category contains explanations regarding what Agile is and how it functions and a second category that argues why Agile doesn't work. There are obviously two points of view: one that offers to introduce you to the Agile secrets and the other one, less numerous, but which is beginning to be heard louder and louder, which thinks that the Agile practices are harmful and can negatively affect the development of software applications.
I personally consider the Agile values and principles as being very natural and fair. I have always thought that a good part of the Agile practices are common sense and that they suit very well the development teams of software projects. Of course, the arguments of this type (natural, fair, common sense) are not meant to satisfy a person accustomed to the demonstrations specific to exact sciences. Therefore, I began to examine more closely the benefits brought by Agile to the development teams.
The conclusion I have reached is that the Agile paradigm adapts the processes to the human nature, this being in a contrast to the classical management approach which imposes the members of the team to adjust to a particular development process.
In the following lines, I will offer you a few examples to support my statement, concluding by some pieces of advice regarding what should be done when things don't work out as we wish in a project.
There is a series of situations that we have all come across in the projects we have been working on, situations that go beyond the technologies used or the degree of experience. One of these examples is the level of effort that a team makes when they are supposed to carry out something that seems to obey Paretto's law, also known as the 20/80 rule. More precisely, it seems that the team makes a constant effort during 80% of the time it has at its disposal. Generally, after that period of time runs out, the team realizes all of a sudden that it is not possible to complete their target in the allotted time and the effort level increases considerably (Picture 1). It seems that this pattern repeats itself over and over again in different contexts, for teams of different sizes and configurations, but which have to carry out some creative activity. The development of a software application is also a creative activity.
One of the approaches of this situations is to search for a method for the team to work constantly during the entire period of time available, but it seems, however, that this thing is not in the human nature (see Parkinson's law).
Picture 1. The distribution of a team's effort in the process of development
On the other hand, many of the Agile methodologies propose an iterative development, where each of the iterations lasts from 2 to 4 weeks, and at their end, the team has to produce a functional application. Although this approach does not change the rule of effort distribution, towards the end of an iteration, it is much more reduced than in the case when the development period would have been one of three months, for instance, making, thus, the production process smoother, with minimum and maximum levels of effort that are closer to one another.
Picture 2. The distribution of effort using successive iterations
Still in the area of time management, this time on the personal level, it is worth mentioning here another human habit, considered normal up to a certain degree, called procrastination. Procrastination represents a behavior characterized by an unjustified postponing of actions and tasks for later, which is seen as a reaction to the anxiety associated with the beginning or ending of a task or making a decision. This thing can be found precisely in the strategy called "last responsible moment", especially in the Scrum and Lean methodologies, which implies postponing some irreversible decisions till the moment when the cost of not making them is higher than the cost of adopting them. This strategy is considered benefic since it makes the development process more efficient, as it is not blocked by making some decisions which can be made later on. As it is emphasized in many papers, the "last responsible moment" strategy should not be turned into a justification of procrastination, but rather a way to eliminate it.
Estimating the tasks we have to carry out represents, from my point of view, another example suitable to prove the fact that the Agile paradigm is oriented towards the extraction of the good things out of those behaviors which, in other contexts, would be considered defaults. As I was writing in one of my first articles in Today Software Magazine, "Peculiarities of informatics projects", the activity of software development is a creative one and there is no schedule to specify the usual period of time necessary for the implementation of certain functionality. One of the things I have noticed while coordinating different teams engaged in the development of software applications is that the motivations and perceptions based on which an estimation is made, differ a lot from one person to another. On the other hand, I have also found out that the accuracy of estimations does not greatly improve with gathering experience. This is due especially to the complexity that is characteristic to software projects.
What improvements does Agile bring to estimation? Firstly, it is the collective estimation. Instead of the estimation being made individually, by each person for their own tasks, the entire team takes part in the estimation of all tasks. This substantially reduces the estimation errors and the differences of perception are discussed and cleared out with the entire group. In addition, moving your attention from time estimation to the estimation of the necessary effort by using a particular system of evaluation, leads to an increased estimation speed, without reducing the estimation accuracy. Through these approaches, the experience in the domain is much better turned into advantage and the estimation effort is much reduced.
Coming back to the previously mentioned idea, namely that the software development activity is a creative one, I cannot help drawing a parallel between the way in which an application is developed and the way many of the artistic works are done. As you can see in Picture 3, which shows an unfinished painting, the painter did not split the canvas into 6 or 9 distinct areas to be painted successively (characteristic of the plan-driven approach, where the person carrying out an activity is supposed to have in mind, very clearly and detailed, what the result of this activity should look like), but drew a first draft of the entire picture, which he later improved, finally using colours to complete the painting (characteristic of the evolutionary approach, which implies the fact that the final product is completed after a series of successively enhanced versions). You can notice that even at this stage, which is far from being completed, we get an idea of what the painting would look like after being finished and, very importantly, it is still in a stage where substantial improvements can be made with little effort.
In all the Agile methodologies, there is support for the evolutionary approach to product creation, the imposed development cycle also has, besides the quality of being interactive, that of being incremental. Thus, the software development activity is sustained on the methodology level, as it is approached in the same manner most of the creative activities are approached.
Picture 3. Paul Gauguin - Tahitians at Rest (1891, unfinished)
One last example I would like to give is the one related to the fascination we have for complexity. In many situations, we embrace the more complicated solutions to the problems we have, and when we don't do it, due to the lack of time or other resources, we appreciate them more, anyway, as we are often dissatisfied with the simple solution we have chosen instead. This fascination for complexity is often found also in the software projects development activity: we often prefer the implementation of a framework which can solve much more than the problem we have to solve, without taking into consideration the very high maintenance costs derived from it. And the examples could go on.
Here is an interesting experiment. The Bavelas experiment shows us that when there are several solutions to a problem, the one that is the most complicated and sophisticated usually attracts most appreciations. Aware of this fact, Stefan Roock, consultant, speaker and known author especially for his expertise in Extreme Programming, said at one point that "in software, the complicated solutions are wrong, even though they are right".
Agile introduces the "just enough" concept. From the definition of user stories or the writing of documentation to drawing up the architecture and planning, everything is carried out in the "just enough" approach. This time, Agile no longer lays so well on human nature, but on the contrary: it searches for strategies through which to diminish the negative effects of a common human behavior. The processes are adjusted so as not to give too often the opportunity to the project team to think in a too complicated way.
There would be many other examples, from the structure and importance given to the retrospective meetings in Agile ("man learns from his mistakes") to the idea of user story, which is based on the fact that people's attention and ability to understand are influenced a lot by the manner in which something is presented. But these things will probably make the topic of a future article. What is more important to understand right now is what we could do …
One of the things Agile couldn't treat yet is people's tendency to think into patterns. Thinking into patterns represents an advantage most of the times, because it helps us to observe, analyze and react correctly and faster in many situations. It is the manner in which we have managed to learn many of the things we know today. However, in certain contexts, thinking into patterns may distract our attention from important details.
Somebody used to say that in software development the only sure thing is the change. In such a context, trying to apply certain practices and processes which worked out in the past is often dangerous, and most of the times, when things don't turn out well, we don't say that the processes or practices are not suitable, but we are rather tempted to put the blame on the people, the context, the lack of resources, etc. Now, to conclude the article, my advice is that, when something doesn't work in our project and this goes on for a period of time, we should try to analyze and maybe adjust the processes we are using. They might be totally unsuitable to the context and our persistence in changing the context might attract even more problems.
by Ioana Varga
by Peter Lawrey
by Monica Rațiu
by Călin Biriș
