I'm a bit of a Reddit lurker. I hang around the tech communities. Occasionally, I review memes. You know, serious business. Over the years, I've noticed a shift in sentiment about agile working methods in these communities. “Agile is dead”, they say.
In this article, I'll introduce Corporate Agile as a way to label dark patterns that drive the rising negativity about agile working methods. As a path forward, I will make the case for a return to principles with Basic Agile.
The Heart of Agile
I welcome a change of attitude - too many Agile implementations seem to create significant worker frustration and corporate overhead. It inevitably leads to debates about whether “insert-your-favourite-flavour-of-agile” is inherently broken or poorly implemented.
Nevertheless, I don't think the agile principles are wrong. An agile mindset is fantastic when working under complexity and uncertainty. In circumstances like these, a plan-driven approach isn't helpful because the outcomes of the process are too hard to predict.
Consider questions like these, common-place in start-ups and software shops:
What is the best way to do something you’ve never done before?
What do customers want, what do they need, and what will they pay for?
How could markets and funding impact our capacity to do the thing?
What might competitors do, and how should we react?
As workers in tech, we participate in hard-to-predict Complex Systems because people, markets and new inventions are involved. How can we thrive in such conditions? Well, in an agile spirit, we make headway by:
Collaborating closely and communicating often to come up with good starting ideas.
Working in small increments, doing the important parts first to test our ideas against reality.
Continually reflecting and improving from our experiences, changing course when needed.
Dead simple. That’s just my rough summary of Heart of Agile, by the way - a response to the overly complex state of the Agile industry launched by Alastair Cockburn, an agile-manifesto-original.
There’s no need to evangelise or make a religion of it: Working “Agile” boils down to prioritising adaptability over predictability. We minimise risk by reacting quickly to unforeseen troubles, and we maximise impact by reprioritising based on the opportunities we see. In times when the future is hard to predict, an agile way of working is remarkably efficient.
Corporate Agile
The straightforward and practical mantra of Agile is getting lost in complicated processes, pedantry and productivity theatre.
Reputable Agile voices have highlighted this problem before: Agile, as implemented in many organisations, is bloated, inefficient and, frankly, missing the point.
Martin Fowler calls it “faux-agile”, perpetuated by the “agile industrial complex”.
Ron Jeffries talks about “Dark Scrum”.
Andy Hunt said, "Agile now means we do half of Scrum poorly and use Jira".
Some even advocate for leaving the “Agile” label behind to escape its widespread misimpression. I think that would be throwing the baby out with the bathwater, but that's just me. At least, we should continue to shed light on the dysfunction and figure out how to avoid it. I'll call it “Corporate Agile”.
Corporate Agile attempts to prioritise adaptation AND predictability, not realising that you must prefer one over the other. It maintains a strict hierarchical decision-making process. It assumes general managers are qualified to decide how specialists should do their work.
Corporate Agile reckons splitting work into arbitrary deadlines (like “sprints”) improves meaningful outcomes. It believes estimates are accurate and uses them to plan delivery timelines. It uses prescriptive metrics like “velocity” and “burndown”, prompting teams to do work that fits in the box, regardless of whether it’s valuable.
Corporate Agile needs coaches, consultants and middle managers in abundance to keep workers in line. It supposes that a 2-day course prepares someone without technical or domain expertise to run the process. It does not show concern that all involved attend lengthy mandatory meetings to conform to the process. It does not admit to the astounding amount of time and money wasted, which could’ve been spent working on tangible outcomes for real customers.
In summary, Corporate Agile practices emerge when businesses attempt to implement Agile as a "canned process" while continuing to apply traditional project management thinking to the process, unwilling to pass control to the workers.
The price of planning
To get an indication of the price we pay to do Corporate Agile, let’s review the time spent to perform a typical process. I’ll take a Scrum team as an example, making a few simplifications to make measures easy to follow.
Our hypothetical team consists of 7 Developers doing 1-week sprints. They have four team meetings each sprint: Refinement, Planning, Retrospective and Review. We’ll assume each meeting takes one hour, totalling four hours a week per person.
That's 28 person-hours spent each week “doing Scrum” instead of doing work that directly benefits customers, and we’re not even counting the Daily. Now add the overhead of a professional scrum master, dedicated product owner, and layers of management between the team and its real stakeholders.
I think it's fair to say this team uses the equivalent of a full-time role (or more!) in meetings and management to keep the gears turning. Think about that. What did they gain? In my experience, efforts toward backlog grooming, task refinement, and sprint planning rarely yield noticeable benefits except to make work fit in a box.
For those currently in Scrum teams, ask yourself which would make your products more awesome: These meetings? Another engineer, designer, artist or domain expert? Budget for tools, services or runway? A few hours to relax and recharge?
Of course, coordinating a group of co-workers costs something. My point here is that Corporate Agile encourages wasteful behaviour - large groups of clever people sitting around in lengthy sessions to “coordinate”, “align”, and “plan” work that is likely to change before it's even ready to be started. These meetings are typically run by managers, and only a few participants contribute. We can do better than that.
The blame game
Techies often point to “the business” as the perpetrator when an organisation devolves into Corporate Agile. But I've also noticed that some technical types are quick to forfeit responsibility, like taking the role of a “code monkey” working on tickets and waiting for payday. Compared to speaking up, taking ownership and collaborating intently, working tickets is a simple and comfortable life (but only half the fun).
Zooming out, I do think multiple groups contribute to the problem:
Leaders keen to exert control and influence may disempower the teams, denying their ability to reflect and adapt.
Managers who seek self-preservation may unnecessarily insert themselves into the work, making processes complicated and bureaucratic.
Consultants and trainers who hunger for sales may tell corporate clients what they want to hear: “Sure, Agile methods are compatible with a top-down, plan-driven approach. It's called SAFe. Yes, you can have your cake and eat it, too!”
Workers who choose the path of least resistance may not speak up about barriers to work that they face for fear of conflict or apprehension to change.
Stakeholders and customers who feel unsettled by uncertainty may push toward fixed-scope solutions that require a more plan-driven approach.
Yeah, I'm firing shots at everybody here. If you agree with me, you can see that a goal of “being agile” concerns the entire organisational stack, not just a single group.
Every individual is unique. Some struggle without the predictability of a plan-driven approach, while others thrive. It's important to be empathetic to that, understanding that agility does not come naturally to all.
Basic Agile
If Corporate Agile is so bad, how can we do better?
I think we need to strip away the broken processes and go back to basics. I'll call it “Basic Agile”, but it has many names: (lowercase) agile, Heart of Agile, the Agile principles and “being agile”.
Basic Agile is about returning to the principles of agility, allowing teams to self-organise to be efficient and under uncertainty. It's about rejecting the complicated processes that spawn from corporate bureaucracy. It's not something you can easily buy or roll out as a one-size-fits-all ruleset. It's about adopting a no-nonsense way of thinking about work that lowers the barriers to prioritising things that make customer's lives better.
Basic Agile empowers those closest to the work to decide how the job gets done. It flips the control flow of the organisation from top-down to bottom-up: Managers support the teams to do their best work rather than telling them what to do. That leaves less to manage, and naturally, the management layer shrinks as a result.
Basic Agile is about embracing uncertainty. It's being humble to the fact that we simply don't know enough for “big plans” to be realistic. It's about climbing a mountain one step at a time, finding the route as we go, and making our way to the peak at a sustainable pace.
Basic Agile has certain prerequisites. You need:
Strong teams that can get great work done without intervention.
Managers who support their teams without controlling or sheltering them.
Leaders who can set a goal without dictating how it should be achieved.
Contracts that are flexible in scope. If you’re working under fixed-price-fixed-scope terms, agility is impossible.
A readiness among all to face uncertainty, make changes and figure things out along the way.
If you can't satisfy these requirements, you may be better off dropping Agile entirely and embracing a plan-based approach like Waterfall despite its well-known disadvantages.
How do teams practice Basic Agile? The short answer is that it's up to them. People, projects and priorities differ, so it makes sense that a team can figure out a workflow that suits them instead of just following the Scrum Bible.
Tools? You can use Jira, Monday, Trello, Tuesday, Atera, Wednesday, post-its, or whatever works for you. The critical thing is that everyone involved can:
Collaborate closely and communicate often.
Work in small increments.
Continually reflect and improve.
I'm starting to sound like a broken record here. By focusing on principles over process, Basic Agile encourages teams to learn and develop the best approach for their problem space.
Basic Agile is less like executing a plan and more like a process of evolution that drives towards more optimal solutions. However, we can still understand our progress by projecting past work into the future. These projections are like weather forecasts where results are consistent in the short term and get more uncertain as you look further out. Forecasts are much better than estimates because they're based on empirical data instead of guesswork. If you're interested in this, I recommend you watch Allen Holub's talk on #NoEstimates.
A Basic example
To make things more practical, I'll share some highlights from the process we’ve developed in my current team. For context, we work on spatial training simulators.
Our daily routine starts with a 15-minute "App Bash" for testing the latest build - optional and open to all. A focused 15-minute Daily follows this to hash out findings and today's blockers. For deep dives, we turn to Slack and ad-hoc huddles.
Sprint planning stays short and flexible, focusing on weekly themes and potential dependencies between people. We break features into tasks when we're actually ready to work on them, and we don't spend time on estimates.
Immediate concerns? We tackle them on the spot and hold a Retro every few months for a deeper look.
For those interested in our progress on long-term objectives, we make rough forecasts based on past work. Between forecasts, open builds and Slack updates, we don't need formal Review meetings.
Compared to the Corporate Scrum example from before, we get by just fine with less than a quarter of the weekly person-hours dedicated to team meetings. We don't have a product owner or project lead, as we collaborate directly with our stakeholders.
We've worked this way throughout 2023, and things have not descended into chaos. To the contrary: The team is healthy, and we keep delivering great work in good time.
Your mileage may vary. The point isn't that you should replicate our process in your teams, but it's worthwhile allowing your teams to find their own.
Now what?
If you just read this and thought, “That made sense to me”, then maybe you should try making things more Basic and observe the outcome. If things get better, try doing more of that. Let me know how it goes. If you're looking to shake things up, you could quit doing Scrum and re-design your process with adaptability and efficiency in mind.
Tell your friends - the extent to which the organisational stack understands agile principles is vital to the success of a Basic Agile approach.
Walking away from established processes takes some courage, but remember: Nothing is stopping you from going back if things don't work out. You might learn something new, and if you can adapt and improve from it, that is an agile way to be.