The Seven Deadly Sins of Agile.

Last February marked the 20th anniversary of the publication of the Agile Manifesto, which set forth the principles on which methods such as Scrum and Kanban are based.

Over the years, the use of these methods has practically become the norm in software development. But the fact is that not many companies in Spain are entirely happy with having adopted them. Big Spanish companies are pouring ever more money into software development – but they are not getting the results they expected yet. Hence, to this day they still haven’t been able to get a return on the investments they have made on this kind of projects.

But you can’t “blame the gun for what the killer does” either. In general, it is a lack of experience on the part of some teams and the misinterpretation of these methods that are damaging the latter’s reputation.

The funny thing is that many of these teams think they are applying Agile methods correctly – when they don’t focus on the value they provide to the business, the backlog remains unchanged, or the team is made up solely of developers.

Thus, I think it is more or less accepted now that few companies are applying Agile methods to their full potential. In view of this situation, here are my questions: Is there really no fault in the methods themselves? Can we continue to blame everything on misinterpretation? Here are 7 problems for which, in my opinion, Agile methods are also partly to blame.

Lack of affordance

Generally speaking, Agile is not the problem; the problem is who apply it. But what is it about such a simple method that people misunderstand it so much?

The concept of ‘affordance’ in the context of interaction design was introduced by Don Norman, who defined it as: “Those perceptible properties of an object that determine how it can be used.” This means that the appearance of the object should leave no doubt as to how it should be used. This is true for any object, regardless of whether it is a doorknob, a web interface or the steering wheel of a car.

I think Scrum is missing this concept. Otherwise, how is it possible that each person understands something different after reading the guide? How is it possible that teams always tend to make the same mistakes? I myself go back to the Scrum Guide and the Agile Manifesto from time to time. Everything is in there one way or the other. The main problems that arise during project development are the result of these documents being misread. Therefore, can’t they be improved so as to prevent them from being misinterpreted?

Becoming an end in itself

Anyone who has taken part in a Scrum project has felt at some point that they were getting into a rut. Planning-review-retrospective, planning-review-retrospective, planning-review-retrospective… After 5 straight Sprints, you suddenly find yourself in Groundhog Day.

The team has devolved from a group of motivated people to a bunch of code monkeys whose job is to close tickets in Jira. And the backlog, instead of being a living thing that grows smaller after every Sprint, becomes an ever-growing graveyard of functionalities that everybody knows will never be developed.

This is mostly due to the fact that, by following the Guide, you unintentionally enter a wheel, and before you know it, you are striving for perfection in the application of method whilst forgetting about the goals of the product.

The very definition of the role of Scrum Master, i.e. the person who is in charge and is the guarantor of the method, also contributes to this mistake being made. The end result is unmotivated teams that never become true product teams. This is one of the arguments that the people of Basecamp use to criticise Agile methods and that has inspired them to come up with their own Shape-Up method, which is highly tailored to their specific context.

Product Owners are expected to have superpowers

In my career I have been very lucky to have met true Product Owners. People who made me realise how crucial this role is for the team and who have left other people I’ve met later on who were trying to play this role looking like fools.

These true Product Owners were able to stretch a shoestring budget to the utmost, applying their creativity to turn their weakness into a strength and make a mediocre team become a good team. They were product-orientated people who had things clear and were always paying a close eye to their team.

But thinking about these true Product Owners has also reminded me that they were few and far between because they are a rare breed. The fact is that most Product Owners are not up to the task.

I think the problem lies partly in the definition of the role itself. It is without a doubt the most complex role in Scrum, and the people who play it are expected to almost have superpowers.

This is too much responsibility for people who are usually experts in their line of business but do not know the ins and outs of software development. And, on top of it, if this is compounded with a team that heaps all the responsibility on them, disaster ensues.

Self-importance

The Scrum Guide clearly says: “It works well as a container for other techniques, methodologies and practices.” However, as Ramón Nogueras explains in his talk “Cuando falla la profecía” (When Prophecy Fails), as humans we have a bias that makes us keep looking for silver bullets. A lot of people are unaware of this bias and see Agile as the umpteenth silver bullet, encouraged by the cottage industry that has sprung up around it and thrives on selling silver bullets: trainers, coaches, lecturers, writers, and so on.

Poor agilists need to draw a perfect line between what the Guide explicitly says and what it doesn’t. Anything not in the Guide is a second-class citizen.

First of all, this situation is aggravated by the high degree of inbreeding in the development community. I think we need to stop reading books on Agile and attending Agile events and look for ideas elsewhere. There is much to learn from the specific knowledge of a vertical business or from fields such as strategic design or product management.

The second thing that makes the problem worse is the proliferation of profiles under the umbrella of Agile who don’t care much about the value that projects should actually deliver and are more preoccupied with the ‘method’ as an end in itself. This is happening – no matter how much the principles of the Agile Manifesto say it shouldn’t.

Bear in mind that product management, which is halfway between an art and a science, is a very complicated thing, and that doing it right requires experience.

The Agile boom caused salaries to go up rapidly. This prompted many professionals from a wide variety of backgrounds to get themselves certified – relatively easily – and become “Scrum Masters” overnight. Moreover, any “Scrum Master” with a couple of years of experience suddenly became an “Agile Coach.”

The problem is that these profiles who lack the necessary experience are hampering those who feel Agile is their true calling.

A lack of strategy

Every product needs a strategy that lays the foundations for what is to be carried out. In turn, this strategy should be reviewed over time.

Because Agile does not expect us to mindlessly throw things at the wall and see what sticks but instead is a call for changing tack quickly and overcoming our natural tendency to having everything planned from the start.

Scrum does not reject strategy – but neither does it have any artifacts or events where product strategy or vision is explicitly discussed. Indeed, these two words – “strategy” and “vision” – are not mentioned even once in the Scrum Guide (only its review speaks timidly of adapting the backlog somewhat to meet new needs).

This causes many teams to forget how important strategy is and hence to fail as a result of iterating without having any underlying strategy, thereby contributing to burn the money of clients and investors who are driven by an overdose of the Lean Startup methodology that has been misconstrued and is even a bit outdated now.

Focus on artifacts, roles and events

In my opinion, the main problem with Agile methods is not what they say but what they don’t. For example, XP focuses on those engineering practices that are needed to make frequent quality software deliveries and ignores other components that in all likelihood have a greater influence on the success of a project.

To give another example, the Scrum Guide focuses mainly on three things: artifacts, roles and events (the latest versions also attach importance to values). The Guide occasionally mentions a few other concepts, but its bulk and structure revolve around these three things.

This unwittingly leads many teams to concentrate on these three aspects and not on others that are equally or more important to the success of a project.

Why not focus on how to achieve product/market fit? Why not focus on getting business performance metrics? Why not focus on the process of discovering new functionalities? Or on risk management?

The top product teams go beyond Agile methods. They apply many of its principles but use different names and roles and, above all, worry more about things. For instance, the book Inspired (for me, a benchmark in software product development) names the three basic principles a true product team should govern itself by:

01. Risks (technical feasibility, business…) should be addressed at the beginning, not at the end.

02. Products should be defined and designed collaboratively, not sequentially.

03. It’s all about solving problems, not about implementing functionalities (it stresses that business results are what matter).

These three principles are compatible with Agile principles and the Scrum Guide – although there is a major difference if one focuses on one or the other.

Working software as the main measure of progress

Measuring progress in terms of working software is a principle that makes it clear that we are not here to make presentations, i.e. that reviews are not project status meetings where PowerPoint charts with traffic lights are presented but meetings for reviewing whether the objectives of the Sprint have been reached, getting feedback from stakeholders and going over the backlog.

The problem is that sometimes there are more important things than working software. Indeed, the purpose of product teams is not to “deliver functionalities” but to “solve business problems”. Functionalities are answers to problems. Why do we want working software if the product is meaningless and nobody uses it? So, for me, the real measure of progress is not just working software but its impact on the business: how many new users it has helped me to gain, how much more efficient I am thanks to the product, how much revenue a certain functionality is bringing me, and so on. That’s the data that matters. That’s why business results need to be the main goal of development teams.

Another thing is innovation environments. In environments where uncertainty is very high, validated learning is more important than working software. Sometimes, literally months are spent building a productive MVP when the same learning could be achieved in weeks with a good interactive prototype and a good research strategy using a representative sample of the target audience we want to reach. It will never be a completely real environment, but you can achieve 90% reliability at 10% of the cost.

Compatibility with the constraints of a real business

Most projects have one or more of the three variables of the so-called “iron triangle” – scope, cost, and time – fixed. This is the reality of a business. Thus, the software development methodology has to do with these constraints.

“We do not make estimates,” “we do not set dates”... The rigidity of some teams with respect to these variables forces them to operate based on a model where the Product Owner uses a double-entry system and individually takes on some of the risk. Often times, the Product Owner makes up – without any input from their team – an answer to the constraints their company has imposed on them, thus opting for a solution that only makes the situation worse, since dates are set too early without letting the team discover things at its own pace.

We know that the software development context is changing and that any attempt at deducing a solution is a recipe for failure. We must be able to inspect and adapt things within certain limits – provided, of course, that these limits leave some room for manoeuvre and that they are actually the minimum that are strictly necessary: that you have an end date but are flexible regarding some functionalities, that you are clear about the scope but have some flexibility regarding dates, and so on.

Because real businesses require a certain amount of planning: they carry out marketing campaigns, they come up with sales strategies, they have dependencies with their partners, they have to submit their annual accounts, etcetera. Agile teams cannot be oblivious to these facts. We must be able to work around these restrictions if we want to work on a real business and not on a boundless imaginary business.

Conclusion

In my opinion, we can no longer claim that all Agile problems are the result of poor implementation, completely absolving Agile methods from any blame. In any case, one way or the other, the fact is that these problems exist.

Will these problems be the death of Agile? NO. Agile principles are here to stay. However, I think that, using these principles as a guide, we should move away from dogmatism and strive for best practices that focus on what is really keeping projects from being successful from a business standpoint.

And this is what Paradigma does. For years we have been incorporating tools and practices to our way of doing things, which has helped us to adapt Agile methods to our specific context based on our experience of what helps us to provide more value to our clients.

“Adopt principles. Adapt practices.”