Where myths about Agile

Now they talk a lot about flexible approaches to software development. And even trying to implement to implement the state. contracts. On the other hand, many companies stumble on these approaches. And although the companies are doing what they need, and even the Scrum-master is in them, the software product for some reason ceases to evolve, and many problems appear to correct defects. Let's see why this happens.

How came to life such

Flexible approaches to software development, began to be applied in Russia since 2002, after the release of Kent Beck's books "Extreme Programming" (XP). But, the real popularity brought Scrum, led by the Scrum Alliance and certification of Scrum-masters. Everyone liked the ease of use, planning games, gamification of retrospectives, and the obvious daily planning meetings that were previously used in factories and design bureaus. And everyone believed that you could write less documentation and communicate more, and the code itself would create high-quality.

As a result, it turned out an interesting thing. Thanks to good propaganda (certification of the Scrum-master costs not small money) the Agile-process of software development began to understand Scrum and vice versa. But, often when introducing Scrum, and practices that improve communication, they forgot about engineering techniques that provide high-quality software development.
')
As a result, Agile has become a cargo cult in which they believe. A software product, as it was not developed good, and is not developed.

Look back

Let's look more closely at the Agility movement history as it relates to software development.

The main conflict that was resolved was the following:

In order for the Customer to be satisfied , you need to create high-quality and useful software. To create a high-quality Product, you need not to change the requirements in the software development process. And at the same time, in order to create a useful Product, it is necessary to adjust the requirements for the Product, to adapt it to the needs. You can not simultaneously change the requirements and do not change the requirements.

But how then to be? When you can not, but really want, you can. And the authors of XP thought: how to make it so that the requirements can be changed (adjusted), and the product was of high quality?

The main undesirable effect of changing software requirements is that the software package is very complex, and a change in one place may entail unpredictable behavior in other places. To reduce the effect of this effect, you should use modular tests, continuous refactoring and continuous integration.

Thus, all XP engineering techniques were linked into a single system:

• to implement new requirements, refactoring of existing code is needed;
• so that refactoring does not break anything - modular tests are needed;
• for unit tests to always work - one must be run every day on the integration server;
• So that tests do not forget to write - they need to be written BEFORE the code (Test Driven Develpment (TDD) technique);
• So that tests were not too lazy to write - you need to do this together.

On the other hand, it is necessary not to forget about the customer, and about that in time to know what he had in mind and keep him informed. And also keep up to date and the whole team:

• in order to find out in time about changing requirements - you often need to deliver the result to the Customer
• For the whole team to know where, who and what is refactor - you need to communicate every day;
• To improve approaches to development - you need to discuss the results in retrospect at the end of the iteration.

As a result, if we take out at least one brick from the whole system of practices, the system will collapse and bury the Product. Which, incidentally, is what happens.

What we have

As a result of the incomplete use of all the techniques underlying the myths described in the Hayim Makabee article . End of Agile: death from primitivism. // Practice of designing systems.-2015.

• Myth 1. Good design decisions are born when User Stories are implemented.
• Myth 2. Technical debt can always be paid in the future.
• Myth 3. Constant refactoring is an effective way to create code.
• Myth 4. Flexibility can be achieved by following the Agile process.

But I think that these myths did not originate from scratch. The root cause of these myths is that, instead of using the full-fledged XP process, which was the basis for the Agile approach, everyone uses the Scrum-communication framework, which simply does not cover all the needs of software development.

Total

No practice can be applied thoughtlessly, simply because it is fashionable, or so he said. Is always! You should always think ahead.

Unit Tests (TDD) allow you to immediately check and create the necessary program interfaces. But they do not protect against the wrong architecture. At the time of writing the test, we think tactically, not strategically. This leads to the implementation of ill-conceived decisions, and not willing to change in the future.

Good technology "pair programming", provides thinking strategically on the fly. In pair programming, one ALWAYS will be a “navigator” - a strategist (without a keyboard), and the second “pilot” behind the keyboard. This allows you to immediately cover all the code in general, and make decisions on the spot.

The XP Methodology never says "Do not write documentation." Communication is more important than documentation, but if documentation is a way of communication, the Wiki system ensures the creation of this documentation in exactly the volume necessary. That, in turn, improves the pair synchronization (pilot navigator) and the creation of high-quality code through the elaboration and discussion of the architecture.

Also, in the practices of Extreme Programming, it is not written anywhere “do technical duty and make the customer happy,” it says “do continuous refactoring, tests will protect you. May the Force be with you. ” This means that at the completion of EVERY task there should be no technical debt. Totally.

The XP Methodology also does not say “Do not design the entire system in advance.” It says “Be prepared for changes”, which means that it is necessary to make the architecture moderately flexible, and at the same time moderately sufficient to realize a certain amount of work and demonstrate the partial result to the Customer.

Conclusion

1. The worship of a cargo-cult and the mechanistic performance of actions will not give the desired effect. And it can make it worse.
2. If you do not use any of the XP techniques, you will not build a product with Agile. It will collapse along the way.
3. Each member of the team should have an understanding of why this or that technique is needed. for see clause 1
4. Never rest on your laurels, you can always improve something. Do not give in to inertia.

Literature

1. Extreme programming. Kent Beck
2. The mythical man - month or How software systems are created. Frederick Brooks
3. Professional software development. McConnell S.
4. Purpose. Elia M. Goldratt, Jeff Cox

Afterword

Q: Are there any successful Scrum projects?
A: Only if they are made using XP. Or if the entire project is completed in less than 1 turnkey month.