{{announcement.body}}
{{announcement.title}}

Why Agile Doesn't Work for Large Projects

DZone 's Guide to

Why Agile Doesn't Work for Large Projects

Evgeniy Tyumentcev, the founder of the development company Hello World Technologies, talks about why the values of a flexible methodology like Agile are not suitable for large projects.

· Agile Zone ·
Free Resource

It's sad that Agile can't always work.

But we want Agile to work all the time!

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 Agile.

You may also like:  We Can't Seem to Escape the Problem of Complexity in Software Development

But the question arises: Can it really help? Or is Agile only a convenient technology for inventing apologies for deadlines? Let's dive into it.

Flexibility rules (right?)

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 is flexible.

In the 1960s, Naus and Farr measured how source lines of code affect the duration of a project. They found a nonlinear relationship, which had the form of a power function with a factor of 1.5. You can see this in the picture below. The dotted line shows the graph of linear dependence, and the solid line is the actual graph.

How source lines of code affect project duration

Let's consider the following example: Instead of writing code, a programmer would have to build a wall of bricks. Conventionally, he would place the first brick in two minutes, the tenth in about five, and the thousandth -- well, if it took less than 10 hours we'd all be surprised. 

At the same time, we expect that his bricklaying speed would increase eventually due to the experience gained. But that actually doesn't work for programming; moreover, it turns out that the cost of laying one brick increases as the wall grows, especially if the programmer gets a fixed monthly salary.

Programming is characterized by a decrease in labor productivity as the project grows

Have you ever wondered why companies, when releasing a new version of their product, proudly talk about how 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 would you throw it away if the new version also contains the functionality of the old one?!

Unfortunately, the graph shows that the project is cheaper to rewrite than to change from a certain point. Some companies turned this into a business, regularly releasing new versions and forcing consumers to pay for it.

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

There are several other problems caused by this reduced productivity and are directly related to Agile. With that in mind, we describe each of the problems from two points of view: how programmers solve them and how the solution is presented to clients.

Problem № 1. Failed deadlines

Programmers don’t 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 percent or more when 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 estimation. This means that you refuse to evaluate the entire project, instead breaking it into small pieces or phases. Before the new phase starts, you should estimate the necessary time only for it. This is how the iterative development process works.

Presentation of the solution: Immediate feedback is the reason to use an iterative development process. At the end of each iteration, teams have to collect 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 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: There is no need for that. This is a time buffer that every competent manager should have on the project.

Problem № 2. The cost of meeting customer requirements increases over time

The longer one delays changes, 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 greatest profit.

In the case of reduced work performance, task prioritization takes on added meaning; we need to ship solutions the customer will pay money for until the whole budget is exhausted. The question is how to measure 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 will be realized, but only the ones that fit in the customer budget. At the same time, no one knows in advance what exactly the budget can cover.

Problem № 3. No time for documentation

Coding will strive to 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.

You may also like:  Agile Documentation: Fact or Fiction?

Solution: Refuse to write documentation.

Good code must be self-documenting; it means understandable enough without any doumentation notes. It looks crazy at first, but in 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).

Problem № 4. It is impossible to complete the project, observing all three constraints at once: functionality, time, budget

The classic project management triangle describes three constraints: the timing, cost, and project functionality. 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 as well. 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 in case of extremely high trust in 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).

Problem № 5. In an environment where deadlines are difficult to predict, the result of a project depends on the efforts and abilities of specific employees

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 assessment himself. 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).

I want to note that I have never believed that the values of flexible methodologies are incorrect or harmful. Each one benefits in its own way.

The case is different: Agile does not solve the problem that exists in the IT industry since its inception but instead adapts to it for both customers and performers. In this regard, the Agile Manifesto is an excellent guide on how to turn disadvantages into advantages. But this is not enough for large-scale projects.

Further reading

When Scaling Agile Is Not the Answer

Large-Scale Agile: Where Do You Want Your Complexity?

Topics:
agile at scale ,complexity in software development ,flexibility ,it ,large projects

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}