Dave Thomas wrote a blog post called “Agile is dead (Long live agility)“. In the blog post, he claims the use of “do Agile right” as a way to profit, whereas it should make people – developers specially – to deliver valuable software more effectively.

It had a huge impact in the community in a way that many other people came up to point out their opinions. Also, some good texts about the subject came up as Andrew Binstock’s “The Corruption of Agile” and Allen Hollub’s “The Agile Holocracy“. In reply to the last two articles, Uncle Bob wrote “The True Corruption of Agile“. These are the kind of movement that make the industry to evolve: to criticize the “state of the art” practices and ideas. And to better understand what’s going on, it is better to step back and look for what “Agile” is supposed to mean. Watching a talk by Martin Fowler and Neil Ford called “Explaining Agile” can help us to better understand it. I’ll try to tr;dl the talk by Martin and Neil, so we can follow along with the discussion.

Explaining Agile

Before the whole Agile idea had emerged, industry majority used to follow waterfall by using frameworks and methodologies that support its idea, such as ISO 12207 and CMMI. All of them established a strict set of practices that should be followed in order to be compliant. The practices became a process and each person would take an input and then transform it into an output which would be someone’s else input.

And so did the tools, they were designed to support the same process for every company. Everything should be automated in such way that development pipeline (requirements, design, development, test, maintenance) would work perfectly. The only team with autonomy to change the process was the process quality team.

A successful project in waterfall would be one where everything run as planned. All people did was following the plan and making an input into an output hoping to get the final product at the end of the project.

It was noticed that the plan needed to be changed often during the course of the development and the later changes were needed the more expensive they would be. Although there are certainly exceptions, it’s usually very hard to plan a project and not needing to change it.

It would be better if the plan period was shorter and, by making it shorter, one could adjust the plan between periods. In order to make a good plan, review and retrospective meetings came up, so it would be easier to spot problems and to solve them. And to do so, it is necessary to give the autonomy to the team to change its own process independently of its project or organization unit.

That’s why “Agile” came for. We would have iterations and after each one we would have a chance to change the course of the project, to change the way software is being developed and to change the whole plan, so that we would have an empirical process/practices and not a strict defined process.

Where the corruption is

All the discussions raised by the cited articles are being fired by the same reason: “agile” is being misused. People are creating strict practices and process and taking it as “the right way” of developing software, whereas they should consider the empirical knowledge that each project gives as feedback.

It is needed to adjust the process and practices in a way it makes sense and turn the software development easier to maintain and faster to deliver value. In order to accomplish that, you have to change things. Embrace the change was not supposed to embrace only the requirements change, but any change.

People has turned Agile into a set of strict practices, when it is a philosophy/culture of how to react to environment stimuli. The practices are the reflex of the reaction and, biologically speaking – don’t forget software is built by living beings -, people can react differently for the same stimulus. And in this thought is where people is corrupting the agile.

I’ll give a real example to try to make myself clearer. When you work on different projects with different clients, the cultural differences among the stakeholders are more evident. So, it is our job to make the project to succeed and the way of doing that is adjusting the process over the time and don’t be afraid of doing new things.

For instance, I worked in a project once that was following Scrum guidelines. At some point, the plannings were not taking even a full hour. The stories were well defined: PO and the Scrum Master already had prioritized them before the planning had began. We used to estimate them before the meeting and the only discussions raised during the planning were about making sure developers had understood PO’s needs.

Because of that, in some retrospective meeting we decided to merge Kanban with Scrum and have something hybrid. We would still estimate the stories so we could keep the predictability, but we did not had plannings anymore. Bugs and User Stories were prioritized in the proper column and the developer would assign himself to the most prioritized one. Plan changes were notified by Campfire. When a doubt about the US was raised, Scrum Master and the assigned developer would talk directly with the PO using Google Hangouts and/or Campfire. The changes were communicated to the others developers through Pull Requests.

We got autonomy to change things and it was very satisfying to see the results. Always remember those left-sided values from the agile manifesto and let it flow. Remember that the process cannot decide how you work, but the other way around. We had delivered with agility, even though we took the risk of going out of the box and not being tied to the conventional practices.

Finally, I want to thank everyone who is helping to push the community forward by raising discussions like that. As always, when discussing, be aware that we criticize the practices themselves, not people or companies. There is no such thing as “right” or “wrong” for subjects like this, there is what works and what works better for you. So, what other practices can we discuss about? Have you done any change which had a huge impact? Share with us on the comments below.