A couple of years ago at Agile Roots I was part of a panel discussion titled "There Is Only Us". The gist of the conversation is whether agile had reached the point where it was considered a best practice for the software industry.
As best I could tell, our consensus answer to that question was "Purple".
There's no question that awareness of this thing called "agile" has permeated the software industry. But the principles behind it? The point of it all? I'm not so sure.
According to a highly scientific survey of a few web sites I decided to google based on my own biases I can prove conclusively that the most common conversation about agile is "Why it didn't work for us".
But this entry is not about agile teen angst. It's about legacy - what we influence, what we pass on.
For many years I taught martial arts as a personal passion. Even tried to make it my career a couple of times. If you're wondering how successful I was just note the fact that I blog about the software industry and not the martial arts industry.
But the one thing I did do well was teach. And the interesting thing I learned about teaching is that sometimes you influence people's lives for the better. Seeing those changes in the lives of my students fed my soul enough to motivate me to keep teaching for over 20 years.
Sorry, was waxing nostalgic for a moment there. No, that's not the legacy I'm writing about.
Last night I was chatting with Daniel Spangler - a long-time friend and co-worker. Daniel is the kind of rock star developer that you build development teams around. I know this because I've done just that multiple times.
Unfortunately our last project terminated rather abruptly, so Daniel moved on to a new position that included...
(insert screeching horror sound track here)
Management responsibilities!
O, the horror of it all!
As luck would have it, the company he joined was just in the initial stages of rolling out Scrum through their development teams. Daniel, still reeling from the shock of becoming management, decided that I'd be a good person to talk to about this whole agile thing. Of course him coming to me for advice was all the evidence I needed that he was still in shock.
Daniel: "So we're doing Scrum, and I don't know anything about it".
Me: (insert spit-take here) "Daniel, you've been practicing agile for years! What do you mean?!?"
Daniel: "Yeah, I know we've been doing it, but I don't know what all this stuff is called."
What's tragic about this is that there's a large contingent of the "Agile" (yes, I used the big "A" intentionally) community that would agree with Daniel's sentiment that he doesn't know "Agile", let alone Scrum. Daniel isn't the only one. I've visited many teams in the guise of an agile mentor. Invariably they would disclaim that they didn't know (or care about the names) of whatever flavor of agile you'd care to name but were shining examples of how agile teams really work.
Once I had wiped the water off of my keyboard Daniel and I got to work translating Scrum terminology into practices we'd been using for years. Then we stepped back and reviewed the principles behind those practices so he'd have a good basis of why Scrum does what it does, and why we diverged in various situations in the past.
The payoff came in the form of a short conversation we had last night:
Daniel: "So I agree that focus is a key element of agile" (referring to our discussion that iterations provide a framework for the team to limit their focus to the work at hand)
Me: "Tell me more"
Daniel: "After drilling the team hard on better story definition at the beginning of the iteration we are seeing better velocity across multiple projects. Team members aren't wallowing around as much on what they should be working on" (their team works on multiple projects simultaneously)
Me: "So is this a focus success story or iteration definition success story?"
Daniel: "Both, but ultimately it is about better focus. More concise stories translates into less interruptions during the iteration. Less interruptions equals more work being done. We're catching up on several chronically late projects"
Me: "Woohoo!"
Of course this conversation begs the question of "Why don't we see this sort of success happening more often when teams shift to various agile methodologies?"
Wait, I know the answer to this!
Experience.
Daniel, who has at least 10 years of experience working with teams practicing different flavors of agile (Scrum, Crystal, XP) can tell immediately when something isn't right, even if he isn't always using using the right names for the dogma.
Contrast that with how agile adoptions typically work - companies hire external experts to provide training and mentoring, but don't invest in installing persistent expertise at the team level where the rubber hits the road. Is it any wonder why we see "We tried Agile but it didn't work for us" so often?
My hat is off to Daniel. Thanks to him, I have a new element of professional legacy that I can point to and admire.
Oh, and I guess I'll have to claim one less "Agile didn't work for us" story too.
This comment has been removed by the author.
ReplyDeleteTotally agree, experience is what matters. I think there's even more to it than the intellectual knowledge gained from experience. Experience builds habits, and habits are what we use 95% of the time, every day - it's just being human. So your blog post reminded me to ask myself - what kind of habits am I developing through my experience right now?
ReplyDelete