The hard-hitting test of your Agile

I once had the opportunity to participate in attempts to implement Agile in a software development team. In regular discussions, trying to prevent this introduction from becoming a cargo cult, I quoted the blog post again and again by Elizabeth Hendrickson. He is already more than three years old, but I like him, and I would like to bring to your attention (and your struggle with the cargo cult) the translation of this post.

Some time ago I wrote about how I define Agile:

Agile teams produce a continuous stream of claimed code, at a stable speed, while adapting to the changing needs of the business.

This post made some noise, and several people told me that Agile has only one definition, which is expressed in the Agile manifesto. The implication was that, since my definition is different from the manifesto, it is incorrect.
At the insistence of a friend, I re-read the principles of the Agile Manifesto. And I found that my “definition” is there. It is in the principles: "... a regular supply of valuable software ...", "... changing requirements is welcome ...", "... a sustainable development process ....", "... maintain a constant rhythm indefinitely ...".
Ok, I give up. The definition of Agile is given in the manifest. And my “definition” is my impartial test, which does not look at faces and can lead to unpleasant discoveries.
Many organizations claim that they have Agile. Few have the courage and discipline to do anything but empty words. Then they say “Agile does not work” (my favorite reaction to this is the post “We tried baseball and it doesn’t work”).
Therefore, when the team declares to me that they have Agile, I use my test to check if it really is. I'm asking:

How often do you roll out updates?

When I say that Agile teams produce a continuous stream of demanded code, I mean that they produce a code that is valuable for business, ready for implementation / sale at least once a month, and preferably more often. "Ready for implementation / sale" must be understood literally. It is made, in the sense of absolutely. Implemented, tested and adopted by the Product Owner.
Some organizations push this to the limit with continuous integration. In this case, the code after the chekina turns on production after minutes. Of course, this is not always and not suitable for everyone, but even if it does not make sense for you at production, think, maybe it will be useful on your test or developer stands to shorten the development cycle.
Simply put, Agile teams often roll out ready-made pieces of product. Rolling out “almost done” or “done, but not tested” is not considered.
')

Can you work in this mode indefinitely?

“With stable speed” means that a team can do new functionality with a more or less constant speed, without taking into account changes in team size.
Two aspects are critical for maintaining a stable speed:

• people
• technical assets

Before I started working on Agile projects, I got used to the fact that the last weeks or months of the project were held in the mode “gritting my teeth”. The whole team processed (80-100 hours a week were the norm). We pumped coffee, exhausted and angry. But we did what was necessary for the delivery of the project.
Having passed the project, we celebrated our heroism and fell from our feet.
A few days later, we dragged our carcasses to the office. We said: “Now we will do everything right!” We spent time cars on planning, requirements and design. But, objectively, we were exhausted and worked more slowly. The deadline inexorably approached, again we did not have enough time, and again we found ourselves in the "gritted teeth" mode.
This mode can not stand for a long time. Several iterations, and people were caked. Someone went greener on the grass, attracted by a higher salary and / or more sane mode of work. Someone went to other positions. Few, due to loyalty or work ethic, have found themselves surrounded by novices or useless colleagues, and nothing can be done. Development progress squeaks, slows down and eventually stops.
Therefore, caring for people is the number one task for maintaining a constant development speed.
But it is not enough. The second part is taking care of technical assets. Easy wrong decisions, such as copying a large piece of code to another place of the program and refusing to refactor to correct duplication, or cramming the code much faster instead of the right place, or refusing to write an autotest that you need to write, and we know this, create technical debt. With the growth of technical debt, the interest that we have to pay grows.
Simple changes require working with many files. The code becomes fragile. In the end, the team comes to a state where even a small change leads to a huge number of bugs in regression testing (if you have one at all! - approx. Transl.). A small change results in the team chasing bugs for days, repairing what worked, but broke. Again, development progress squeaks, slows down and eventually stops.
Also, pay attention to the relationship between human and technical aspects - tired people will often try to "cut the path on crutches."
If the organization does not care about people, and people do not worry about technical assets, problems are inevitable. They will not come today, not tomorrow, but soon enough, and they will last the whole time of the existence of this code.

How does the team deal with the changes?

I visited one team during the transition to Agile. The team was very pleased with their progress. They worked with sprints for two weeks and coped well with achieving and maintaining a stable development speed.
But I shuddered when I saw their project plan. Their sprints were scheduled for six months ahead! They plunged into the plan for just a few sprints, but I saw the problem ahead. “What happens if the priority of requirements changes?” I asked. The project manager shivered. According to this plan, promises were made, it was impossible to deviate from it.
But change is inevitable. I don’t know the end of this story, but I’m willing to bet that the project manager redrawn this Gantt chart billions of times before they submitted the project.
If a team plans too far ahead, they will not be able to adapt when, inevitably, priorities and needs change. They will be able to consistently release updates, but these updates will have less value for the organization.

Few really implemented Agile.

Often, when I speak to an audience, I ask how many people work on Agile projects. Now, regardless of the audience, many hands are rising. Agile is a cool, fashionable thing, with all the younger developers playing with it. But when I invite the audience to check myself on these criteria and ask again who is working on Agile projects, my hands remain lowered. Very few organizations reach this level of Agile.
Consequently, this means that a very small proportion of organizations benefit from Agile. And in the worst case, Agile means deterioration, increased pressure and more exhausting work. People from these projects say that Agile ruins their lives.
In such environments, Agile is often implemented as:

1. Compressing the deadlines (because Agile means “faster,” doesn't it?)
2. Lack of documentation (because Agile means that we will not document, right?)
3. Writing the code to the last minute (because Agile means that you can always change anything, eh?)

This is a recipe for a nightmare: an increase in technical debts, stress, chaos and, ultimately, disruption of the project and several rounds of an exciting game "Who is to blame?" Yes, in these organizations, "Agile", or rather its perverted version of the "burner" , really destroys life .
I hope that if you find yourself in such an atmosphere, the “unpleasant test of your Agile” will help you to tell those at the helm what true Agile is and how it looks when done well.
Remember, if someone says that he is using Agile, this does not mean that it really is. Abraham Lincoln said: “If you call the tail foot, how many feet will the dog have? Four. Because to call the tail foot does not mean to make it foot. "