You’re Asking The Wrong Question.
I’m in Hawaii for the Aloha on Rails conference. The last session on Monday was a panel moderated by l4rk that included Obie Fernandez, Pat Maddox, Blake Mizerany, and Tammer Saleh. The topic: “Is Agile Too Slow?”
Ostensibly we were there to talk about whether there were any circumstances under which agile practices actually take too much time. As Obie, Pat, and Tammer talked about their preferred set of agile development practices, and how they’d never take a client who didn’t want to use them, it hit me that the whole premise of the question they were answering was just…wrong.
Agile is not about checking off every entry on a checklist of practices. Agile is about adapting your process to fit the project you’re on. If you think that every project absolutely must have tests, you’re not agile. If you think that every project absolutely must be storycarded, you’re not agile.
If you can’t adapt your process and add or drop practices as appropriate – including dropping down to no process at all when it makes sense – then you might as well be doing waterfall.
Agile is never too slow. Dogmatic adherence to practices, on the other hand, is.
Exactly! It was difficult to elicit “what does it look like to scale back practices and processes appropriate to context, ROI, opportunity cost, and risk management” at the panel. But that’s where I intended it to head. Not that I minded where the discussion went. As long as the panel spawns a few blog posts and tweets and furthers the agile (little “a”) discussion, I’m happy. Thanks for the post!
“If you’re never too slow, you’re never too slow” conveys the same quality/quantity of information as “Agile is never too slow.”
In other words, yes, it’s the wrong question. But “Agile is never too slow” is also the wrong answer.
Great post Sarah. I completely agree. The (product) companies that I work with look to become more agile not necessarily to gain speed of development, but to deal with fluid environments where they have direct contact with their customers who are giving continuous feedback. These companies are leading their industries, and do not want process changes to derail the progress they’ve made. Having said that, they do know and understand that things need to improve process-wise. My job then becomes to ensure that everyone is on the same page with the vision and goals of the company and releases, looking at the current process, and then making that process more agile, taking into consideration existing tools and culture.
Adaptation is the name of the game.
In principle I agree: Agile teams adapt practices to fit the business context. They reflect and adjust at regular intervals to improve their overall performance.
But too often the call to “Adapt the Process to the Context” becomes an excuse. The disciplined engineering practices like Test Driven Development, pairing, and Continuous Integration go by the wayside because “we don’t have time for that here.” Then the organization gets itself into an even bigger mess than before with higher levels of technical debt and an unshippable mess of undocumented spaghetti code. And then they blame Agile.
Ultimately, Agility can only be assessed by the results: Does the team produce releasable product increments at least once a month, consistently, as a matter of course and without heroics or shortcuts, while adapting to changing business needs? If so, they’re Agile. If not, they aren’t. It’s that simple.
The best way I know to achieve those results is with the disciplined engineering practices that may feel slow initially, the practices that I suspect Obie, Pat, and Tammer were talking about. (I don’t know the others, but I’ve paired with Pat Maddox and that man rocks a keyboard.)
So yes, I am dogmatic about certain practices especially with organizations that are in the process of transitioning and are trying to take shortcuts: the Agile transformation equivalent of get rich quick schemes or miracle diet pills. And no, I won’t work with clients who think it’s just dandy to play whack-a-bug at the end of the development cycle instead of testing throughout.
It’s not that I’m completely inflexible. It’s that as an Agile coach my job is to help clients learn how to be really, truly Agile and not just fool themselves into thinking that they are.
@Elisabeth: you bring up a number of great points. Ultimately, every team needs solid engineering practices in place in order to produce a quality product. Many companies don’t have those in place however, and the road to implementation can be a rough one, though it must be traveled to ultimately be successful. So an honest look at the current situation is needed, in addition to a “where do we need to be” assessment. Once you know those two, you can chart a successful course. That course is not a one size fits all solution, which is where folks like you and I come in.