Notes on Agile Is Dead talk

I watched the 2015 Agile Is Dead talk by Dave Thomas on YouTube (link to the talk video -- this talk was delivered at the GOTO 2015 Amsterdam conference). Here are some initial thoughts.

The talk is pretty good -- because I think the main message is that we shouldn't be fighting agile methodology wars and we shouldn't try to make big corporate-looking processes... we should try to return to simple agile principles.

The "Agile is Dead" title is deliberately provocative, which isn't a bad thing. Dave Thomas's message is definitely pro-agile, but he wants to make sure that folks aren't just using "fake agile".

Say "Agility" rather than "Agile"

Within the talk, Dave's first point is that we should use the word "agility" instead of using "Agile" -- because Agile is an adjective, so it can't be something that we do.

From a linguistic standpoint, this is not a big issue. In the English language, the "parts of speech" are somewhat malleable. We often use nouns in a "verb slot" in a sentence, or adjectives in a "noun slot". Linguists are OK with this (although grammarians are sometimes upset about it). Linguistics is the study of languages as they are used in the world, not as the "should be" in some pure sense. "Agile" and "agility" are both reasonable ways to refer to software development approaches that are lightweight, adaptive, and iterative and incremental.

Dave goes on to make a valid point -- that the term Agile has been made synonymous with certain specific "name brand" agile development and agile management methodologies -- such as XP, Scrum, and Kanban. In addition, the training and certification business has diluted the "agile values" and reinforced the "cookbook" aspects of these agile methods.

Critique of Agile and Scrum short-course training

Dave really points out the problem of inadequate Agile training in the Q&A session after the talk. He is particularly harsh on Scrum training (such as a 1 or 2 day Scrum Master training course), because such a course is going to focus on a certain mechanical process -- which may actually be used badly by a novice Scrum team. A novice team will be reluctant to adapt the cookbook process to help meet their real needs.

Here is why I think that Dave's assessment is a bit too harsh... it is a problem where Alistair Cockburn has some important insights -- his "Shu-Ha-Ri" model of mastering a complex skill. (Here is a link to Cockburn article on Shu-Ha-Ri.) Novices are always need to start with some rote repetition... and a specific mechanical process is an essential scaffold for them to get started. Over time, as a team gets more experience, they can figure out which artifacts or meetings aren't really needed, or what new internal team interactions need to be added. At the highest level of expertise, a lot of the rules "go away", because the team can make things work without needing to follow a long checklist.

(Dave has a point that you can't just stop learning after a Scrum intro course -- you aren't really going to incorporate the real "agile values" if you stop at the level of rote repetition of a cookie-cutter process.)

Agile values and a really simple approach to agility

Dave suggests a very unstructured approach to "agility" -- his process is:

• Agility - What to Do
  • find out where you are
  • take a small step towards your goal
  • adjust your understanding based on what you learned
  • rinse and repeat

This process is extremely simple, visionary, and completely impossible. Why?

"Where you are" is not an obvious thing. In a big software project, the average team member might understand 2% of the code and 5% of the overall design. Even in a good XP team working on a small system, the average team member might understand 15% of the code and 40% of the overall design. There are three software engineering practices that allow us to still make progress in the face of this vast ignorance:

• architecture (someone has thought through the most important modules, interfaces, end-to-end scenarios, and "ility" requirements -- we have some documents and pictures that help us reason about how to adjust the architecture over time)
• information hiding (most modules have been designed to reduce coupling)
• automated testing and continuous integration (there is an automated build of the partial system, tests seem to work, each iteration seems to make progress)

"Take a small step towards your goal" isn't easy either. The biggest difference between professional software development and hacking is "written requirements". User stories, BDD, and test-driven development are acceptable ways (but not always perfect) to pick a short-term goal. There might be enough detail in these requirements artifacts to help individuals and teams to decide on some useful "small steps" that can be done in a short iteration. (On the other hand, the user stories might be total fiction... they might just be a set of CRUD operations on some architect's dumb data model.) "Refactoring" is another kind of "small step" that has a different goal (reducing technical debt).

"Adjust your understanding" is probably the hardest of the three. In my experience in Alcatel-Lucent, I have not seen any examples of agile groups that do an adequate job of running "retrospectives" (either at the end of an iteration or at the end of a release). There are huge cultural barriers:

• no one wants to admit to making a mistake
• we are more interested in thinking ahead to the next feature or next iteration, rather than "wasting time" on something that is supposed to be "done"
• retrospectives are group activities, but most developers prefer to work alone
• management schedule pressure makes it easy to skip retrospectives
• is it really safe to "say what you think"? (Norm Kerth's idea of "personal safety" in a retrospective)
• nobody wants to write down a "retrospective report" (they would rather be designing and coding instead)

Dave Thomas's "Agility - What to Do" process is a great inspiration -- it is consistent with the best agile values. But it takes some practice to figure out:

• "what do we need to know about where we are" (what should we focus on, what should we ignore)
• "how do we identify some small goals and a good 'small step' to take" (what process do we use to analyze, document, and prioritize requirements)
• "what kinds of retrospectives should we do" (how to keep things lightweight and safe, while still "learning")

On the whole, it's a valuable talk, but a bit unrealistic in his criticism of the process of learning about agility.

Notes by Dennis Mancl, MSWX Software Experts, dmancl@manclswx.com

Last modified: Apr. 11, 2017

This work is licensed under a Creative Commons Attribution 4.0 International License.