Why failing Agile is so easy
For the past years, I have had the chance to implement Agile in many different types and sizes of organizations, in two different…
For the past years, I have had the chance to implement Agile in many different types and sizes of organizations, in two different countries and even in my own companies. The successes and failures I have accumulated along that time allowed me to compile a list of facts and thoughts that help the successful implementation of processes guided by the principles and values proposed by the Agile manifesto.
Being Agile before doing Agile
It does not matter which methodology the team is using today. It is more important to understand how the team operates daily, how members collaborate to tackle problems, and how they accept and acknowledge changes and new ideas. In general, a team that does not evolve at the same pace as their market peers is very likely not to be suitable for an Agile practice — at least not before doing other small changes to improve speed and value-driven mindset.
“If you want truly to understand something, try to change it.” — Kurt Lewin
Agile is a mindset, all about culture. Changing anything related to that is hard and painful for us as human beings. It demands us to move from our comfort zone, to challenge the status quo. It requires effort and engagement not only from the dev team but all the other stakeholders. If you are interested in reading more about the human factors of changing a behaviour I recommend the book Changing for Good written by Ph.D. James Prochaska.
Before doing Agile, it is necessary to be Agile. Every time I tried to implement a new practice before fostering the principles and values of Agile on each person that was not used to them, I have experienced a tortuous path. I tried that many times and in different environments such as public and private sectors, small and big teams, from startups to enterprises. Small steps and teams were always the best path to follow and the less harmful for the relationship with the client — stakeholders and dev team included.
Often I heard executives saying that their teams were already doing Agile since they had implemented standup meetings, kanban board or sprints — some of the most known terminologies being thrown away. Investigating further I could find that in fact, they were not. They were not working on delivering value but solely planned work, the team was not motivated, continuous learning was not part of their process, deadlines were still enforced, “sprints” lasting months, product owners showing up just to drop more tasks, delivery was a painful process, communication between team and stakeholders did not exist, among other things followed in traditional environments.
What makes these teams believe they are doing Agile? Agile is not a recipe or a framework that you can follow steps to implement. It is open to interpretations, and that is a fertile ground to grow misconceptions in the name of being trendy or whatever other pseudo-motivation to adopt it. If you never had the chance to read the Agile Manifesto from the source, I urge you to do it, it just 4 values and 12 principles, a five-minute reading which shows Agile is all about trust, collaboration, learning, quality, communication, team effort and last but not least: innovation.
If you can identify in your teams two or more of the following items, then you are not doing Agile:
Countless initiatives with urgent deadlines rather than assigning the highest priority and choosing two or three to tackle
Managers overturn team decisions
The best talents are spread across too many projects
Too many meetings with team members, causing them to work less in the project
Excessive review layers
Mechanism of reporting or controls are created or already exist to ensure that mistakes are not repeated
Managers and leadership talk more than listen
Nonessential ideas are promoted, especially the ones that the team has previously considered and deferred
Lack of communication cause conflicts or rework
Quality Assurance is not part of the entire process
Changes are not well accepted by the team
Change requests seem to be unjustified or not qualified
Delivery or deployment is painful — require working after hours, lack automation or have too many approval requirements
Customers or end-users feedback are neglected in favour of the original plan or scope
The scenario where executives believe they are doing Agile, but in fact, they are not, is still common. In those cases, the challenge was much more laborious, requiring enormous effort to convince they were on the wrong path, show the real Agile and its benefits. It is not rare in those cases to have someone saying that Agile is equivalent to anarchy, running without direction and losing quality. As mentioned before, implementing Agile requires a change in culture, mainly in traditional industries which are still very hierarchical, and decisions are made exclusively by the top of the pyramid. Executives must empower their teams in order to implement Agile successfully.
An easy decision with a high cost
Unfortunately, top-down decisions still exist, and it happens more often in the public sector and traditional organizations. I would not say that having a decision process like that is the same as setting the implementation to fail. In fact, it worked more than a couple of times, mainly because of the pseudo-motivation created by that being an order from the senior management team. However, every time that the Agile process started because of this type of decision, it was more laborious and time consuming to make the whole team to onboard and follow the new practice and the chosen framework.
The top-down decision is quite often taken using KPIs from other companies as a benchmark showing an increase in user satisfaction, productivity, code quality, velocity or similar metric. My experience shows that 5 in 10 teams that implement Agile experiments better productivity, customer satisfaction and quality increase in the mid-term and a total cost decrease in the long term — not to mention the other KPI improvements. That number changes to 8 in 10 when I trim my data to teams where the decision to implement Agile was a democratic decision, making all members of the team part of the process.
Selling the idea, presenting pros and cons, implementing as a trial in a specific project or debating the topic has always shown as the best path to follow. It is time-consuming as well, but in a good way since the team’s motivation and engagement is being built from day one by letting them participate in the decision process.
The main point is that Agile is not a framework or a process based on rules, well established or that dictates how to do things. Teams must be free to implement in the way it fits best for their project, choosing an existent framework (Scrum, Kanban, XP, Lean, SAfe…), even creating a new one based on those. They also must be free to choose the tools that support better the practice daily.
Failing must be a tool for improvement and learning — not shame, not punishment or an excuse to revert the Agile implementation. Teams need to be free to question every process, requirement and try new approaches. When failing, they have enough material to learn from mistakes and improve in the next cycle.
“Failure is simply the opportunity to begin again, this time more intelligently.” — Henry Ford
Sometimes Agile is not the answer
The fact is there is no such thing as a right or wrong way of working. Each methodology can work in different ways depending on teams and organizational culture. It is important to say that Agile can be applied to any business, product or services — and not only for software development. Companies are using the philosophy to build airplanes, elevators, create new marketing campaigns or even to modernize an entire conglomerate.
However, there are a series of conditions, not related to people or culture, that creates unfavourable scenarios for implementing Agile, they are:
Problems can be tackled sequentially, in siloed teams or priority to solve them is just a matter of urgency
End-users can not start using the product or service before it is completely done
The organization should be operating as a machine, very hierarchical where constant changes and innovation is not necessary
Customers or end-users are not available for collaboration
Making late changes is cost-prohibitive or even impossible
Failures and mistakes can cause irreversible harm
The market is stable and predictable
Existent solutions are stable and are solving the problem in a way that innovation would not change or cause any benefit
Digital Transformation is not necessary for the type of services or products that your company offers
Changes based on customer feedback, if not implemented fast and frequent, does not cause any harm to the business
Unless you have identified factors that make Agile unfavourable to your business, failure should be expected, and it is very likely it will happen, based on my experience, if you do not observe the points discussed in this article. Failing to implement Agile’s practices can lead to, at least, a better understanding of your organization and drive other processes of change. Take advantage from those learnings and find ways to improve your business, at the end of the day, that is the primary goal.