Last night I had the pleasure of hearing Jon Stahl‘s introductory presentation on “Agile Explained” at a joint meeting of Cleveland IEEE and the Firmware Engineers of Northeast Ohio. The lighting was not so good for picture-taking on the LeanDog boat, so sadly there are no photos to share.
It was a nice crowd, although I’ve got to say one of the least diverse I’ve ever seen even at a technical event. Being mostly hardware and firmware engineers, they were skeptical about the idea of continuous deployment to production for obvious reasons; the guy sitting across from me used to design circuits for pacemakers! But they asked excellent questions, and in true Agile style Jon gave them The Simplest Answers That Could Possibly Work.
The value system
Long story short, Agile isn’t a methodology. It’s not even really a set of practices, although practices are important in implementing certain values in real life. The real deal is that Agile is a value system. In short, you prioritize doing stuff that works rather than what theoretically should work; you prefer to let people organize their own teams rather than assigning overly specific roles; you change the plan where it’s obviously not working; and you focus on delivering value to the customer rather than avoiding blame.
Also, very importantly, you presume that people are really smart and want to do good work. (Have you noticed how much of business management assumes–without any actual support–that rewards and punishments are the best motivations?)
You know what else is incredibly important, although Jon didn’t state it explicitly? It’s the kind of trust that comes from an atmosphere of no finger-pointing. I think the family metaphor is overused in business… a lot… but have you spent much time being around (or living in!) a family where everyone has to be “right” and you “win” by showing others up? It’s stressful. It’s counterproductive. It’s actually kind of boring, amidst all the drama. And it kills risk-taking. Who wants to try new things when you’re just going to get shot down?
I hope your family isn’t like that. I hope your family members notice when you’re brilliant, pick you up when you fall down, accept help when it’s useful, recognize all your strengths and weaknesses, and don’t much care about who gets credit when things go well.
It’s not a stretch to observe that offices go like that too. There are some hypercompetitive environments that isolate the weirdos, find reasons to cut people off, and enforce an arrogant kind of mediocrity. Less dysfunctional ones still hold everyone to strictly measurable standards even when their skills and contributions aren’t so easily measured. The best professional settings, like the best families, easily reveal and nurture everyone’s positive attributes while ameliorating or adapting to the problematic ones.
But I digress.
Okay, Jon didn’t say any of that last family bit actually. That’s all me. But he gave us a great overview of why Agile even exists, and what it feels like to work in that kind of environment. As I said, the hardware and firmware dudes (and by “dudes” I mean there were two women in the crowd, just two!) struggled to figure out how they can actually use Agile in environments that are sometimes audited, highly regulated, or very expensive in which to fix mistakes. Reinstalling and rebooting is kind of a big deal when you’re NASA and the deployment is Mars-based! Someone else asked how you can possibly use Kanban-like methods when your team may have 200 members. And so on.
But Jon implicitly answered one of my most nagging questions about Agile development. See, here’s my thing. I first applied Do the Simplest Thing That Could Possibly Work to great effect in… oh, like January of 1989. (It didn’t go over well, actually.) It’s always been pretty darned intuitive to me–I’m not big on methodology, and I tend to have trouble observing protocol, and hierarchy seems totally artificial–so while I’ve read most of the classic books, I’ve never taken a class in this thing.
I don’t implement anything like a pure Scrum or XP or Kanban setup. And I sure don’t have the certifications for any of them.
In response to all those really tough (and fair) questions from the crowd, Jon’s answer was essentially the same: You adapt. Nothing about Agile is a hard requirement, if you’re following the Agile principles.
- Auditors want permanent documentation of each iteration’s release? Fine, create a story card for that and carry it from board to board.
- Can’t push releases to the Space Shuttle in orbit? Okay, let a simulator be your “production” system and find another methodology to update the Shuttle when it lands.
- Is a developer:QA ratio of 3:1 not enough? Super, just go for 3:2 if that’s what you need.
- Really big dev team? Consider a Scrum of Scrums. And so on.
That made me feel better
You’re reading it here. Until last night, I felt like an Agile Fraud! To wit:
- There was a time when I did nothing but pair programming, which worked great and got my pair partner up to speed on ASP.NET incredibly quickly, but I thought I was doing XP wrong.
- Another time I kept using the Three Questions even though it wasn’t a true Scrum, but it served well enough to keep the project on track. And I was certain I was ruining Scrum.
- Right now I’m looking at a stack of story cards wrapped with a rubber band, because I haven’t figured out how (or even when!) to organize them yet. That must be wrong.
Wait a minute though. If I’m applying the techniques that work for that project and which bring out the best work from my colleagues and make them more productive… that’s good, right?
Basically yes. It’s all about doing what works, observing the results, and adjusting.
There’s no formula. That’s the formula.