Once again, the main Agile conference was an extravaganza of serious ideas, fun interactions, and maybe also the occasional party. The conference this year was in Dallas, at 100 degrees and humid, but that didn’t matter because the hotel had enclosed and air conditioned a space about the size of a football stadium. Gotta love Texas.
The theme I got out of this year’s conference was “moving on.” It seems to me that the core elements of Agile are starting to be baked in—in fact, this was the theme of Bob Martin’s talk Demanding Technical Excellence and Professionalism. It should just be expected, at this point, that engineers follow basic good practice—which means a highly structured process, not the cowboy coding that some still attribute to Agile.
But at the same time, more and more practitioners are moving beyond the basics of Agile. The Lean approach is starting to affect people’s thinking in profound ways. The session Scaling Lean by Dean Leffingwell continued this trend, discussing how to think about resource utilization within a sprint in Lean terms.
Dean also, by the way, had a useful metaphor for explaining systems thinking: What part of an airplane is responsible for flight? It’s not just the wings, though they’re critical. It’s not just the engine. It’s the whole thing, working together.
Taking these ideas even further, Alline Watkins in her User-Driven Development session took out a whole bunch of Agile sacred cows and used them very roughly. As a UX person, I had to love the way she handled getting user feedback—every few days, if you please, and no complaining about how hard it is.
But it was her treatment of some of the basics of Agile that intrigued me the most. How done is “done”? You think “passed QA” is good enough? Nope—“done” means a real user is actually using it. It’s a Lean principle that everything is waste until it’s delivered, right?
Or the backlog—got a large backlog? Why? All the work of creating and maintaining a backlog is just Big Design Up Front. You Ain’t Gonna Need It—just write the user stories at the beginning of the sprint, right before you’re ready to start implementing them. Put off all work until the last responsible moment, yes?
Did I say “user stories”? Pardon me, no user stories. Just declare what you’re going to work on and start right in. Did I say “sprint”? My mistake, no sprints. Just quick iterations with the user. How quick? Every two or three days. Why would you need longer?
I don’t believe all of this is necessarily good practice, but I think it’s great to challenge our thinking this way. People adopting Agile tend to fall into the mindset that since development proceeds in 2-week sprints, everyone must do work in 2-week chunks—you can’t think a thought that takes longer than 2 weeks. Incorporating Lean concepts of work flow and work in progress gives us more flexibility in how we think about structuring project work.
So Agile is busting out of its shell. The fundamentals of Agile—short iterations with quick user feedback to guide changing direction—won’t change. But the procedures Agile puts in place to achieve those fundamentals (sprints, user stories, backlogs) are likely to evolve, and are evolving.
Remember folks, you heard it here first.