How do I know if I understand Agile? | Software development

It’s a very common complaint among Agilists that [managers | marketing | execs | product |+] don't understand Agile, that when Agile fails it is due to it being done wrong, organizational resistance and so on.

Let's face it, Agile is like pseudo-science or political ideology in that respect: you can always retort to critics that whatever went wrong in your Agile effort was because "it was not Agile enough".

Regardless of what you think of Agile, though, it's hardly controversial that there are different ways to work according to Agile. And it could be useful to wonder, before starting work, whether everybody understands what it is in compatible ways. The reason for this is that we know that it's easy to go through the Agile motions without getting any of the true Agile benefits.

I think there's a good case to be made, that Agile is first and foremost a decision-making system rather than a process organization. Yet, it's in practice quite easy to establish Agile process and workflow rituals (they are called ceremonies after all) that shield you from the AINO curse, but where Agile's raison d'être, its spirit and mindset, still get lost.

This is the question I'm considering here: even if I've been involved with Agile projects and governance, I've read Forbes articles about Agile and whatnot, and have even attended Agile coaching workshops or classes, how do I know if I really understand it? What are the criteria, from the point of view of an Agilist, that show that you “understand Agile”?

So I thought about that.

First, let’s frame:

1. Who is this about: we want to know if you know Agile even though you say that you’re “doing Agile”. If you’re a “Waterfall’s got everything I need, Agile is a hippie teenager’s dream” kind of person, then you’re not who we’re talking about here, although you might find this interesting too.
2. What do we mean by “Agile”: by Agile here I mean the actual practice of Agile in the real world, meaning that it’s also about elements of LEAN and development practices typically associated with Agile product development today.

Second, let’s set aside the obvious: knowing what a sprint and a PO and a scrum of scrums are, what a user story card is supposed to look like, or what an acceptance criterion is, is irrelevant here. It’s not about knowing a list of ceremonies or methods. That’s knowing, not understanding. We want to know what “understanding Agile” means.

Then, there’s the Agile manifesto. Have you read it? Do you like it? Do you agree with it? OK, sure, I love the Agile manifesto, it’s one of the most important 21^st century documents, I think. But the Agile manifesto is a 20-year-old text that doesn’t contain any of the knowledge we gained from putting Agile into practice for the past 20 years. Also, the manifesto doesn’t know about LEAN, and it doesn’t know about how Agile has been thrown around the business world since. So that can’t be just it. Although to be honest, I was tempted to do a whole answer on the Agile Manifesto. But this might be another post.

So I figured that the correct angle to know whether you really understand Agile when you’re claiming to subscribe to it or do it, has to have something to do with what benefits of Agile you’re able to articulate and expect. So to know if you understand Agile, I figured two questions would help:

• Why do you think Agile works?
• What business benefits do you expect to get from Agile?

This is my answer to these two questions.

Why does Agile work?

Agile works because it takes the productivity of expensive adult experts as the organizational problem to optimize for.

Adult experts are most productive when their job is to solve a problem and least productive when they are required to execute a task that someone else understands what it’s for. It also allows experts to get the satisfaction they need from solving problems for real people, and that increases creativity and productivity for intellectual work.

Agile works because it believes in the real world and in real people. It knows that entropy dominates every physical process and therefore development, business, product management, because life itself is a physical process. And it believes in the creative drive of real responsible adults, who will, faced with problems to solve in a safe environment, come up with effective ways to solve them.

Knowing that the world is a real physical place, Agile forces you to consider in real time what is the most important thing that needs to be done right now, with a view into the future that reduces in resolution with time, because that’s the way the world really works.

Agile works because evaluating outcomes based on the value of working output is a better incentive for creating value than how close we are to someone plan. When you focus on the plan, it's easy to forget about the value, because you assume someone baked it in the plan. When you focus on value, you plan as much as you can for the real value that you can actually deliver. The further out in the future you go, you have to decide on whether you give up on time resolution or on functional resolution.

What business benefits do I expect from Agile?

I do Agile because the way it works makes it possible for me to be quite sure that the results that I’m getting are the best possible outcomes that our organization was capable of. In other words, if what we did is crap, I’m pretty sure of two things:

• it would not have been better without Agile, and
• without Agile it would have taken me longer to realize that it’s crap.

The benefits of Agile are that I get the best possible results given the resources and talent that I apply to it.

Now, if you understand Agile you also have to accept that Agile is like democracy: it’s the worst form of organization, except for all others (h/t for the insight @Andrew Barban).

Just as democracy gives a people the leaders they deserve, Agile doesn’t make a team of incompetents produce works of genius. Whereas you could argue that non-agile, authoritarian, control-oriented, top-down frameworks might, assuming some genius leader applying and maintaining enough force and control long enough to bring their vision to life.

But let’s face it, on one hand, you don’t have genius leaders in most organizations, and on the other, most people are actually quite smart and creative if you don’t crush their spirit, give them space and trust them to solve problems. Thus, even the genius leader will achieve more with it.

Ask yourself: given a random group of developers and business people who have gone through some selective pressure of being employed in a reasonably well managed company, in which of the following settings are you most likely to have a team over-perform given a set of skills and abilities:

• teams split up based on their skills (front-end, back-end, architecture, product management, project management, deployment, QA…) under a set of hierarchical functional or organizational silo managers acting as the interface between business owners and devs, assigning tasks based on their individual understanding of a subset of the requirements and whoever happens to be available this month, or
• multidisciplinary teams in a well-governed self-organized framework, with clearly stated business and/or user problems to solve, collectively accountable for the final result and updating their knowledge in short iterations?

I say that I understand Agile, because I know which of these two setups is most likely to deliver value that matters to my business.

Better requirements

Because Agile is built around teams discussing how to solve a problem, I also know that this will lead to better requirements. If your project is built around the writing of a requirements document, that needs to be complete and signed off (and making  changes to it later requires a change process with signoffs and budget reviews) before work can start, you are absolutely certain of two things:

• The requirements are bad. However smart the team (or often person) writing the requirements document is, there is no way that this document doesn't suffer from two major flaws: a) it's incomplete and full of bad design, because it's not possible to anticipate how a complex system will actually work in the hands of real users months or years before users actually start using it; and b) it's full of useless stuff, because given the stress of not being able to change later, the writers of the requirements will have crammed in there every possible feature that they could think of, every pet idea that the PM wants to make sure doesn't get lost.
• The product will be old by the time it ships. Working off of a requirements document cements into the process the fact that, even to the extent that the requirements are good, they are good for the time when you started writing that document. Once this document starts being written, the only thing that matters from then on is a negociation about what should stay in it or get canned. By the time it's frozen, the requirements will already be months-old. By the time the software gets delivered, the requirements will likely be years-old.

I do Agile because I understand that my product will do better with its users if the features that I ship have been designed with them a few weeks ago, rather than in my head two years ago.

What does "not understanding Agile" sound like?

Now I want to close on the two worst single reasons to believe in Agile, and which are in fact the definite tell-tale that you don’t understand it:

"Agile will deliver the product I have in my head faster and cheaper than Waterfall"

There is no garantee that an Agile program will complete any given set of pre-existing requirements before a non-Agile setup. You can guarantee that Agile will start earlier, for sure, so you do get a headstart.

One thing that's probable, is that Agile completion of the requirements will take longer than what you thought the non-Agile project would have taken! But that's only because the idea that you had in your head about how long it would take was simply wrong. Yes, it was. You're no different.

An Agile development will just look very different from a non-Agile one. Since you design things to deliver working software early and often, you will discover things that would have escaped you in a Waterfall project until it was too late. Maybe your Waterfall project would have delivered a "complete software" earlier, but that would come at the hidden expense of extra training and documentation after the fact, or of a new version to account for all the new things that your users needed and were not in the requirements.

That's the thing about Agile: it brings problems to light earlier, it doesn't hide problems behind the nice feeling of having delivered according to plan, where it's someone else's problem to deal with the consequences of bad requirements.

"With Agile, I can change my mind about my requirements whenever I feel like it"

Agile is designed to be able to react to new priorities and new requirements. But new priorities and new requirements are not the same as "changing your mind". When new priorities or requirements arise in Agile, it's because users have started to interact with the software, and things become apparent that were not foreseen at the initial requirements or design stage.

"Changing your mind" means on the contrary that you couldn't be bothered to do the work to clarify your need before you asked people to start working, you didn't dig down into the problem to be able to state it well enough. Being a Product Owner comes with a responsibility to the team to put them in the best situation to succeed, not to get them to do sloppy work that you can decide to ditch later.

"Agile is a how a development organization works, it's not for management"

The way governance of product development functions can tell us a lot about how Agile a project is. Maybe now is a good time to clarify what we mean when we say "non-Agile". What does a project that is "non-Agile" look like?

Here are a number of governance characteristics of a project that is not Agile:

• it works off of a set of requirements documents that were negotiated, budgeted and signed off at some fixed point in the past
• the governance of the program consists in the product development organization reporting progress to the business organization
• production releases are planned in months, with documentation and testing as tasks that happen in large activity blocks at the end of the development process before release
• it has a resourced delivery plan, with deliverables milestones and task dependencies, spanning several months or years
• it has a whole set of activities and milestones defined around "business acceptance"
• success is understood and reported at steercos in terms of how well we are tracking the % completion on the plan

There are a lot of Agile challenges when it comes to making contact between the operational world of getting things done and the management world of having to decide what needs to be done on a different scale than a project. This is typically where Agility tends to break down when it does. There are ways to make that work, but it's hard and requires smart management.

Do we really understand Agile now?

No. The enthusiastic endorsement of Agile on the basis of the benefits that I describe is necessary, but not sufficient.

There are real challenges in Agile delivery, in particular when it comes to scaling, whether in size, complexity and time. These are often acknowledged. But there are also issues with how Agile interfaces with the management of business in general, which I find are more often overlooked. I discuss this quite extensively in this post that focuses on the SAFe scaling framework, but where I also dig into the problems that it is attempting to solve.

Understanding Agile is also understanding the problems with Agile. If you love Agile and think that it solves everything, and makes everything easier, then likely you don't understand Agile either.

Acknowledging that there are real, hard difficulties that run up against significant other anthropological and organizational fundamentals, and that resolving these tensions is not a solved problem today, is part of understanding Agile.

The crux of my argument advocating for Agile here is that Agile cares about the real world as it is and tries to deal with it in a human and realistic way. In that spirit, advocates of Agile must embrace the fact that these big scaling, organizational and business management problems are also real issues of the real human world.

So, do you think you understand Agile?