The dark side

of Agile

Today many company executives in and outside of IT see in flexible methodologies a tool that will increase the speed of work on projects. For this reason, organizations without these methodologies are striving to actively implement the Agile.The question arises: can it really help? Or Agile is only a convenient technology for inventing apologies for deadlines?Let’s discuss.  The values of flexible methodologies are declared in the Agile manifesto. There are four of them: 

Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan 

Any software development methodology that satisfies these four values can be called flexible. 

Let us explain the value of this research by example. Suppose that programmer instead of writing code, would have to build a wall of bricks. Conventionally, he would have put the first brick in two minutes, the tenth - in five minutes, and the thousandth - in ten hours already. 

At the same time, we expect that his bricklaying speed will not decrease with time, but increase - due to the experience gained. But this is not. Moreover, if the programmer gets a fixed monthly salary, it turns out that the cost of laying one brick increases as the wall grows. 

Have you ever wondered why companies, releasing a new version of their product, proudly talk that it was written from scratch, without using the old code? This is contrary to common sense: the old code cost a lot of money, so why do you need to throw it away if the new version also contains the functionality of the old one?! Unfortunately, this graph shows that from a certain point the project is cheaper to rewrite than to change. Some companies turned it into a business, regularly releasing new versions and forcing consumers to pay for it.

In a situation when the pace of development falls, companies need more and more programmers to maintain their previous level of development. Moreover, this need is growing like an avalanche. The industry is experiencing a strong shortage of qualified personnel. 

Programmers do not fit well in the promised time frame. The required time is calculated based on the fact that the development speed is always constant. But, as we already understood, it is not.  Therefore, even if everything else is done correctly, the time error can reach 100% or more, if the planned amount of work is large enough.  Solution: iterative development processes.  With small volumes of work, development speed varies slightly. Therefore, it is possible to achieve acceptable accuracy in estimating the required time. This means that you refuse to evaluate the entire project.You break it into small pieces - phases. Before the new phase starts, you should calculate the necessary time only for it. This is how the iterative development process works.  Presentation of the solution: you say thatthe reason to use aniterative development processesis the need to get feedback. At the end of each iteration, you need to get feedback from the customer to be sure that the project is developing correctly.  Feedback is certainly very important, but modern practices, such as Continuous Delivery, allow you to receive it at any time, without waiting for the end of the iteration. Nevertheless, the practice of iterative development has taken root - as one of the flexible methodologies.  The result of solving the Problem № 1: labor productivity is still declining  Team productivity declines with time. Therefore, even with iterative development, the number of errors will only increase.  Solution: Velocity. In Agile there is the practice of Velocity, the essence of which is to determine the coefficient - the difference between the actual amount of work and the planned, divided by the planned amount of work. On that coefficient you will need to multiply the score of the next iteration.  This means that we simply describe a nonlinear labor productivity curve using a set of small linear sections, reducing the error in our own estimate. In mathematics, this technique is called piecewise linear approximation.  Presentation of the solution: no way. This is a time buffer that every competent manager should have on the project. 

The longer making changes is delayed - the more expensive these changes become.  Solution: prioritize. The sequence of implementation is very important. First of all, you need to do what brings the greatestprofit.  Incase of reduced work performance, task prioritization takes on added meaning- we need to implement functions for which the user will pay money until the whole budget is exhausted. The question is how to evaluate the benefits. Evaluation is very subjective and varies for the same customer requirement from iteration to iteration.  Presentation of the solution: willingness to change is more important than following the original plan (see the fourth value of Agile).As a result, the customer, perhaps unconsciously, accepts that not all the features he wants will be realized, but only the one for which he has enough money. At the same time, no one knows in advance what exactly he has enough money for. 

Code writingwill striveto spend the entire project budget. As we have already understood, nonlinear dependence is caused by the need to make changes to the "text" of the program. At the same time, the documentation is the same text, therefore the edits in it will also be nonlinear. Instead of one nonlinear curve, we get two already.  Solution: refuse to write documentation. Good code must be self-documenting,it means understandable enough to not need documentation.It looks crazy at first, butin practice, I have not seen a project where the documentation would be in order.Most often, the developers begin to write it, but then they stop because there is not enough time to develop.  Presentation of the solution: a working product is more important than comprehensive documentation (see the third value of Agile). 

The classic project management triangle describes three constraints: the timing, cost, and financial support for the project. Changing one of the parameters affects the other two. What does the customer want? Get the necessary functionality for the agreed money in the specified time frame.  Timing is difficult to comply with, and therefore manage it too. So, in order to save the functionality, it is necessary to increase the budget, and to save the budget, to cut down the functionality.  Solution: to complete the project, you will have to either increase the budget or reduce the functionality. The customer can agree to change the budget or reduce the functionality only if he has a high degree of trust towards the company.  Presentation of the solution: cooperation with the customer is more important than negotiating the terms of the contract (see the second value of Agile). 

Solution: you should give people a sense of responsibility for the result. On this basis, Agile uses a lot of psychological techniques, the purpose of which is to make people accept responsibility.  For example, quite often the programmer can refuse responsibility for meeting the deadlines for a separate task if he did not give it an assessmenthimself. To eliminate such a situation, Planning Poker is used, this is a collective assessment of tasks for iteration and the final result of it is the agreement of each team member with assessment for each task.  Presentation of the solution: individuals and interactions over processes and tools(the first value of Agile).