THE FAKE AGILE: When you say you are agile because you are “using” scrum, but actually you are not agile at all.

Fabulous unicorn

Origin of the problem

Since all these agile frameworks appeared: scrum, kanban, lean,… many companies liked them and tried to bring them to their businesses, because they understood their principles and their goals and it made sense to be implemented.

Soon after, they wanted to be certified, so they sent their managers to a two day course to start “doing” agile at the company. The problem was that all these managers came from business and they skipped all the software technical practices during the process. They were only focused in scrum principles.

Agile was created for well disciplined software professionals, to enclose the gap between business and technology but the result is that (in most of the cases) it didn’t happen.

Understanding the consequences of the problem

When you talk to these people, many say that they “do” agile, but that sentence does not make any sense in English. Agile is not something that you do, agile is something that either you are or you are not. And in this specific case it refers to be agile to adapt to the change.

Agile is about having short and quick feedback loops. This feedback is what lets you react and adapt constantly during the whole project lifecycle. Agile does not solve problems, agile exposes problems. Shows what is wrong, and then is up to you if you do something about it.

Managers usually do not appreciate much the developers, but they do not realize that they are their hostages. In a software project, the pace of the business is set by the developers not by the business. The business can only go as fast as the developers go, business is trapped by the software.

On the other side, developers should produce software that grants freedom to business to change and evolve. The software must be agile, fastly deliverable, so when the business changes, the software can be quickly adapted. If this doesn’t happen, is the fault of the developers because they didn’t let the business to be agile. These cases always mean lose of money, but in some cases may be even the end of a company. The software should be able to change just as fast as the business needs to change.

The symptoms

You could tell you have a problem in your company when your software is something fragile, it is not stable and even has some known bugs. When a software is difficult to change and to maintain because it is highly coupled or it is difficult to understand. When it requires months to be tested and takes forever to be deployed. When iteration after iteration, the software becomes more and more hard to work with due to the technical debt… If you have these symptoms, maybe you are not that agile. Any change in the software should be able to be deployed to production in hours if not minutes, being sure that everything works properly.

Software development is an iterative and incremental process, agile provides you a way to gather feedback during the whole lifecycle in order to improve your software continuously and before it is too late. If you are not gathering any feedback after each iteration, you are failing at the most elementary concept of agile.

When you change the methodologies but you still have the same problems that you had before, it is because you are producing the software in the wrong way. It happens, you think you are doing good but then at the right moment, you realize that everything is a mess. In a software project the most important deliverable is the software itself, it doesn’t really matter which methodologies or processes have you used at the end.

Being truthfully agile

Discipline and technical practices are the glue that makes the whole agile process work properly. Currently, there is a lack of discipline and professionalism in the industry. Many developers only commit with their code, they don’t go any further. They should ask themselves everyday: “How can I improve the system?” and simply do it. Bring quality and excellence to the software. Question everything, gather properly the requirements and make sure that all of them are satisfied at the end, just like any other professional of any other sector.

Agile software requires discipline and good practices, there are thousands of resources out there to get the information about them, but to have something to start, here is a very short list:

        Disciplines                         Technical practices
==============================       ==============================
  - Work in fixed time boxes            - Test Driven Development (TDD)
  - Estimate in relative units          - Refactoring
  - Customer communication              - Automated Tests
  - Continuous integration              - Simple design
  - Team Collaboration                  - Pair programming
  - And more                            - And many more

As software engineers we have to take the risk of bringing good practices to the software development, we cannot delegate the decision making to the business because they don’t understand the problems, so they cannot evaluate properly the risks. As good professionals we have to make the technical decisions, and decide when we invest time or money in something assuming the risk, because that is what good professionals do.

Master good practices is not easy, it requires some time, but just like mastering anything else in life. Be patient, keep on working. Using good practices is not enough to guarantee the success, but the lack of them, is usually the main cause of failure.


Thank you for reading all the way until here! If you want to comment this post you can do it on medium.com or dev.to.