The Anti-Agile Manifesto

The Anti-Agile Manifesto

Warning 1: If you are an Agile Coach or a Scrum Master or any other form of proponent of Agile, many sections of the post will trigger you. This is a semi-organized rant with the intention to re-focus us, not just to hurl insults at Agile.

Warning 2: This post contains multiple Jerry Maguire References.

Over the past couple of weeks, I have been a part of multiple conversations about how we, as trainers, are reaching the wrong people. We are not able to connect to the “hands on keyboard” or “knee deep in work” developers. The conversation with my good friends Colleen Johnson, Daniel Vacanti, and Janee McConnell also extended to the other end. The C-Level or Senior Management leaders also have no interest in Agile. We, at the same time, complain about middle management and how hard they are to change and bring around to our Agile ways. If no one is really interested in Agile, maybe the problem is with the product itself.

This is what leads to this Jerry Maguire-ish manifesto.

Causing harm

There are so many things that Agile has prompted people to adopt that keep plaguing our industry. Many of these were intentional and many unintentional.

Go to any discord or subreddit or any form of user group where developers congregate. Check out their opinions of Agile. A vast majority hate it. They see it as —

1. Unnecessary interruptions to their day via meetings.
2. Estimating in Story Points and being held “accountable” for missed commitments.
3. Having a non-technical admin(Scrum Master) that keeps micro-managing them by bugging them for status.
4. Having to do Support and Business as Usual work while having the pressure of meeting sprint commitments.
5. Spending hours in planning and retrospectives that do not matter.
6. Overhead and added bureaucracy, especially while scaling.

It is just an extra burden that they have to carry which gets in the way of getting work done. If I were a developer in an “Agile Transformation” today, I would not know whose direction to follow — My Manager, The Scrum Master, The RTE, or The Agile Coach. I would also not know if my primary responsibility was to get work done or talk about getting work done.

We have, instead of helping, caused harm to the exact people we have been trying to support. Developers have been left behind in most Agile implementations.

Yes, I can already hear you all — Those are implementations of ‘Bad’ Agile. Sure, I accept that. I would like to counter with a question — What percentage of Agile implementations are ‘Bad’? I do not know the answer, but based on what I see in person and in online forums, my guess would be more than 90% are bad implementations. This is not due to a lack of effort from people to reform these implementations. Here is a follow-up question — If we agree over 90% of implementations are bad, isn’t the problem the thing being implemented itself? What guarantee do we have that 90% of future implementations will not be bad?

Agile might be great in its values and principles, but not great in its implementation. This is not because there aren’t smart and dedicated people working on it, it is because as tools, most Agile methods are broken.

They do not solve problems for developers and make no sense to CEOs/CTOs/CIOs. Why would I, in senior management care about Sprints, Story Points, PIs, WIP Limits, or any of that stuff? I am not here to “make the organization agile”. I am here to improve ROI — “Show me the money”.

Focussing on the Wrong Things

So, developers hate Agile. Senior Executives do not care about it. We have, as a result, targeted (deliberately or inadvertently) team leadership. We have taken team leads and made them Scrum Masters. We have taken others in leadership positions and created Agile Coaches. The entire business of Agile has turned into — How to help Scrum Masters be better Scrum Masters? How do we help Agile Coaches coach Agile better?

In the process of doing this, we have not tried to answer the simple question that every service provider should answer — What is the financial benefit of Agile? How many Agile Coaches or Scrum Masters can show directly, how their work makes financial sense to any organization? Every time we get paid, the expectation from the consumer is that they will get greater value in return. Can we prove, using dollars and cents that we have made the organization more efficient or effective? Can we prove that we have improved the organizations' revenue or reduced the cost more than what they have invested in us?

Agile has been focused on the wrong things for the longest time. A great example is the Agile subreddit. Take a look at the current (mid-August 2023) top posts for the past week. I am pretty sure if you go there right now, this will look pretty similar. There are multiple posts about which certification to take. Question about ‘Should UAT be done by PO or BA?’. A question about dealing with underperforming developers. A post about ‘Trust is more than agility’. My favourites — Difference between Framework, Methodology… and How long is your stand up?

Invariably someone will ask — “Do you assign story points to defects?”. The folks asking these questions are not wrong. The industry that we have set up which makes them ask these questions is wrong. We have been focused on all the wrong things.

Doing Agile Better

We have been so focused on ‘Doing Agile Better’ that we have underserved the people we set out to help. Developers do not care about Agile. They want to show up and build things that people will use. As a developer, my greatest moments of satisfaction came when I solved a customer problem, not when I got Sprint Planning exactly right. Instead of helping Developers solve the right problems, Agile seems to get more in the way of developers solving customer problems.

Developers spend more time attending Agile events(we are not fooling anyone by not calling these ceremonies) and sprinting than working with customers to solve problems. More money is spent on meetings than on working with customers to create products and services that they will pay for. Developers have no idea how they are contributing to the organization’s bottom line, but they definitely know what their velocity is. They are told repeatedly they are not doing ‘Agile Right’… and they rightfully do not care.

We need to move on from ‘Doing Agile Better’ to ‘Building what customers will pay for, efficiently’.

Ignoring Organization Needs

We have deluded ourselves into thinking that organizations need coaches who can help them “Do Agile”. That has no ROI for the organization. What organizations actually need is efficiency, effectiveness, and predictability. They need things that actually acknowledge the economic realities of limited resources and increasing demands. They need approaches that help them understand how to improve their finances. How many sprints equals a 10% increase in effectiveness? Or is that measured by the number of standups? Possibly it is about how much time we spend grooming the backlog rather than doing the work.

In tough economic times, we need to focus on making organizations profitable so that people do not lose their jobs. That should be the focus of Agile. How to operate and make better decisions under conditions of scarcity. The rest of this is just unnecessary voodoo for people to specialize in. Agile Coaches get laid off first because their value is understood the least. Not just by management, but by coaches themselves. We do not have an economic framework to show our value. We can not prove that we are contributing to lowering costs or increasing revenue. All we can show is — People do Agile things now.

This is a proposal for a pivot. We need to stop talking about Agile and start talking more about helping organizations become more effective, efficient, and predictable. Helping organizations manage risk a lot better rather than doing Agile rituals better. There are so many things we talk about in Agile, that run counter to these.

Deterministic Thinking

We have perpetuated deterministic thinking that is completely anti-agile. Story points, planning iterations, sprints, prioritization, and ordering backlogs are all deterministic in nature. These practices encourage people to think in terms of — This is the amount of work we are going to get done in this amount of time and in this order. Does not matter what comes, even if we gain new information, this is the plan for the next 2–4 weeks or quarter. We know this is wrong, but we still do it. The world is not deterministic, not every human head weighs 8 pounds.

There is variability in every measurement and process and our ‘planning’ methods do not acknowledge them. We come out of planning with a single deterministic plan that does not acknowledge multiple options and pivots that Agility is based on. We are then surprised when Senior Management does not get agility.

SO many people will read everything before this and be like “It’s not OUR fault that we were basically being forced to use these agile concepts in the wrong ways, and so, we felt it better to at least try and make small changes at the team level and just scream into the void, even while Rome burned all around us in a fire fueled by Taylorism, the desire for immediate change, and ignorance — and we never actually answered for how we were making our orgs more efficient, effective and predictable….because most of us couldn’t answer that with any level of confidence, let alone data and $$$ to back it up” — Janée McConnell while reviewing this post

Yes, I know that is not the way the enlightened Agile minds want these to be used, but that is how they are used… and yes it is Agile’s fault. If guns keep getting used in suicides and mass murders, we as a society at some point have to look at the culture we are promoting. We can not just sit back and say — People are using guns wrong.

All our methods are taken as exact and deterministic. There is very little conversation about risk. That is what the senior management is interested in- Where is the risk, how much, and what can we do to manage that risk? All the conversation in Agile is around how to set up a team and how to do standups and retrospectives and the right way to set up a release train. A very small minority talks about actual risk management. The thing that executives are actually interested in.

Small Teams

Most Agile Coaches and Scrum Masters came from team-level experiences. I did as well, till I went back to have a larger org-level experience. This team-level experience best translates to coaching teams. That is where all Agile Coaching seems to start. Let us make your teams more Agile. Further, we keep pushing this small team crap on organizations. Small teams are more agile, we tell people. In the process, we take an org of 200 people and create 25 teams. Great, now we have Agile teams in a dependency-laden system. A huge big mess of dependencies runs across the org that brings the overall system down to a snail’s pace. Every team by itself is producing more throughput, but nothing is reaching the customer, because of the dependencies.

Let us solve that, let us create more roles whose job is to manage dependencies and check on the status every week. In fact, let us have a big 3-day planning event to discover and coordinate all these dependencies. Let us talk about all the dependencies coming up in the plan for the next 3 months. All this while knowing fully well, that we live in the real world and the plan will fall apart within the next 5 days.

What about reducing dependencies by reducing the number of teams? What if the org on 200 was split across 7–8 teams instead of 25? What does that do for dependencies? What does that do for interactions? More importantly — What does that do for efficiency at the organizational level? What about Predictability? What about overall effectiveness in terms of Return on Investment? Larger teams can have more types of expertise on them leading to better end-to-end coordination for efficiency, more people available as backups to ensure predictability, and the capacity to get/handle feedback, thereby actually delivering what the customer is willing to pay for.

So stop setting up weird “two-pizza” type rules that actually limit organizational improvement. Help make organizations more effective, efficient, and predictable instead of making teams more Agile.

Bottom Line

There is a lot more rant left, but that is probably for another post. I have been preaching and teaching Agile for years. It did not “have me at hello”, but it definitely became a huge part of what I do. I believe we all need to move on to the things organizations actually need — Efficiency, Effectiveness, and Predictability. Be coaches for those things. In my practice, I am going to focus a lot more on these, than “Coaching Agile”. Yes, I have a podcast called ‘Drunk Agile’, and yes I teach Kanban. Those have for the most part been and will always be channels that help organizations become more Predictable, Effective, and Efficient.

I am pissed off at what we have allowed to have been created in the name of Agile. So sure, go ahead, and teach Scrum (or SAFe, or Kanban), but always tell your students, if this does not improve your organization’s bottom line, change it. Tell them to move on to practices that actually help, rather than banging their heads against figuring out 15-minute standups. Agile is one way to get to Efficiency, Effectiveness, and Predictability, but it is not the end goal in itself. There are other ways, organizations have been successful much longer than Agile has been around. Help Developers and Organizations do their best work, instead of doing Agile.

Acknowledgment: Most of these words are mine, but a lot of the ideas come from conversations with my ProKanban.org colleagues, in particular Colleen Johnson, Janee McConnell, Daniel Vacanti, and Olivier Jomphe, amongst others.