Previous Lecture Complete and continue  

  What the $%&^$%@^ is Agile, Anyway?!

Question

How can I work with agile development? When I search in google about "what is agile development" I can't understand a single word like if I read a philosophical book (sorry if this is an insult.)

Discussion

Boy, do I understand what you mean!

I've been roaming Europe for a few years now trying to cut through this nonsense. (Europe, because nobody in Canada seems to care.) It started in 2011 with "The Extreme Decade" in which I reviewed over 10 years of failing to get the essence of the Agile message across, including how "Extreme Programming" appealed to early adopters, but confused almost everyone else. Three years later came "The Next Decade (of Agile Software Development)" in which I shared why I think most people aren't succeeding with Agile the way they could do. The short version: enterprises (especially) treat Agile like a new defined process to follow instead of as a set of guiding principles to help you figure out what you should stop doing, so that you can stop doing it.

I think that the key point of Agile is this: maximise work not done. Figure out what you shouldn't do, then stop doing it. "Extreme Programming" started with "what's the least we can do and still ship great software?" All the other stuff offers varying levels of detail of how to try doing as little as possible. That's it.

Scrum, for example, says focus on creating something every month that you can ship. It suggests some roles that you'll probably need, like someone with the authority to decide what we'll try to build and whether we've really built it (Product Owner), someone with the authority to keep us focused and the responsibility for clearing our path to stay focused (Scrum Master). It also suggests some basic activities to do in support of creating shippable products: a daily meeting to coordinate work on the fly (Daily Scrum), a monthly meeting to show off to stakeholders (Sprint Demo), frequent planning to avoid misguided forecasting (Sprint Planning), and keeping track of what we intend to build (Product and Sprint Backlogs). All this is nothing more than someone's opinion about how to ship great software with less nonsense. Don't interpret it as The One True Way.

I can say the same thing about how Extreme Programming does it (more opinionated about which activities to do, with a greater emphasis on technical excellence to smooth out the rate at which you can ship new features). It thinks that its practices will guide you towards actually shipping software (not just creating a "shippable increment") every two weeks (not every month).

The Kanban Method uses a different philosophy: start where you are, make strong-but-incremental changes, focus on the flow of completed work that you can sell, visualise what needs to be done so that everyone understands what to focus on, and finish things instead of starting them.

Extreme Programming treats you more like Daniel in The Karate Kid, whereas Scrum acts more like the annoying consultant who teaches you three mind-blowing things at a very high level, then leaves. Kanban Method acts more like the consultant that supports you, but continually (and often painfully) pushes you a little out of your comfort zone at a time. They all work for different people at different times. I use them all.

If you really want to understand Agile—really grok it—then it's this simple:

Lock your team in a room for two weeks. They have one mission: build something of demonstrable value to a real customer in a way that retains their ability to do the same thing again two weeks later.

The act of figuring out what they need to do—THAT IS AGILE. Everything that people like me want to teach you represents only one opinion—however well-meaning, informed, and intelligent—about what your team will likely figure out.

Seriously. That's it. Now you know. Now you can just do it.