My step-father has been very successful in academia, private business, and–most relevant here, oddly—making buildings. As far as I know, he only knows about Agile because of my yammering on during some visit. Nonetheless, I learned many of the truths underpinning Agile and Lean thinking from him.
Note that I wrote “truths underpinning Agile and Lean”, not “core Agile/Lean principles”. The folks who wrote the Agile Manifesto didn’t hunker down in some laboratory and invent Agile ground-up as a theoretical framework. Rather, they extracted certain commonalities from their empirical observations of real work experience. Indeed, they start: “We are uncovering better ways…” (emphasis mine). Read the manifesto or any of the principles. They don’t say why the approach works, but only that they have observed it to work.
This is one reason I believe so strongly in Agile: it stems from broad empirical knowledge, and not just some cool theory that seems like it might work. For those new to Agile, though, it can smell like the emperor’s new clothes. “I can’t really tell you why this works, it just works. Trust me. It’s magic.”
I am generally trusting, so it’s enough for me to give it a shot and see for myself. However, I am also obsessively analytical, and—especially when I am asking others to take a leap–I like to have a better theoretical understanding. I want to connect the empirical observations of others to some less lofty things that I have observed myself.
That’s where my step-dad comes in. Before working in Agile, I worked in a variety of roles in different organizations. During those 18 years, I noticed many things that don’t work and a few that do. Near the beginning of that time, I worked for a consulting firm of my step-father’s, and toward the end of it, starting renovating my house with him. During work weekends, I and others were repeatedly stunned by how much more work we got done when he was there leading. The model presented by this productivity and his superlative discipline allowed me to distill my rough observations of work into–yes, I’m going to say it, and with a capital T, no less–Truths. What a nerd.
When I started working in a Scrum shop, I read Ken Schwaber and Mike Beedle’s Agile Software Development with Scrum. Here was a way of working that mapped to the Truths I had seen. Woohoo! Again: what a nerd.
Why does this matter to me? It calms my anxiety that this new set of clothes is of the imperial variety. And it helps me, as a coach, calm similar anxieties in others. I’m grateful to my step-dad for showing me these things, and I’m planning a bunch of posts about these Truths that I learned from him. He’s from a small town called Foster, so I’ll call the series Foster Agile. Let’s see how far I get.
- Foster Agile: Keep Your Eye on the Ball
- Foster Agile: Not Gonna Happen
- Foster Agile: Not Gonna Happen, Part 2