Bill Higgins and Richard Brown where kind of enough to use the name of this blog to spark a conversation about process in software development. While we might dismiss old blue as a process heavy place, if Bill and Richard can be treated as an anecdotal data point, there could be plenty of Agility running around there. Now, being a large company, I’m sure there’s plenty of “waterfall,” as us Agile-dorks call “everything else” slouching through the hallways too.
Cockburn the Anthropologists
In fact, my favorite Agile thinker, Alistair Cockburn kicked off his career with the work he did at IBM. As he writes up in Crystal Clear, in 1991 IGS, and more specifically, his boss at the time, Kathy Ulisse, wanted to come up a new, better process to use for OO projects. So she sent Cockburn around to as many groups as possible to find out what they did:
What they told me was very different from what I had been reading in the books. In particular, they stressed aspects not covered in the methodology texts: close communication, morale, access to end users, and so on. It was not long before these issues separated in start contract the successful projects I visited from the failing ones. I came to see these issues, and not the design techniques, as the key to reaching a successful project outcome.
As Gladwell’s success proves, people love counter-intutive thinking, and the above was, at the time, counter-intutive…at least from what books were saying. Ironically, Cockburn took a very academic approach to coming up with a very non-academic methodology: he did an ethnographic study of software development “tribes,” and then shaped it into his research, reports, books, and an entire career. In a very real way, he and other Agile thought-leaders are software anthropologists, which is simply fantastic: we’re lucky as a community to have people like that who we can draw on to improve ourselves.
Good People
To mash in a quote, slightly out of context but happily related to the above, from Mr. Brown:
The only thing I’d add is that, in order to classify a process as mindless and choose to throw it out, you don’t just need good people; you need experienced people.
Richard’s point is the second part of what makes me like Alaistar Cockburn so much: his pragmatism. At the begining of his Agile Software Development, he lays out a process for assessing the expierience (or “maturity” to use CMM terms ;>) of the people on your team. The write-up is much more thorough than the almost footnote-ish comments along those lines in other books, for example, “we assume you start with good people…right?”
After laying out a model for asses your team’s skills — complete with fancy spider diagrams — he then make this extreamly pragmatic statement along the lines of: if you don’t have enough well seasoned people, this Agile stuff isn’t going to be easy. In fact, you might want to slow it down a bit. He’s since suggest a few core “tools” to hedge against all manner of development challenges, including, I’d argue less than optimal skills.
I’d quote from the book the assessment process from the book, but it’s such a great book that it’s always loaned out to someome. It’s one of those books I should keep a box of to give out ;> Needless to say, Bill and Richard are spot on to point out that skills are key.
More War Stories
I’ve been off the enterprise agile horse for awhile — distracted by identity, systems management, and all manner of other shiney object ;>. It’s be great to hear from people like Bill, Richard, and others more stories about doing Agile development, marketing, selling, and the software in general.
Several of the vendors I’ve spoken with have alluded to adopting Agile practices — BEA is the last one that I recall — and I get the feeling that those stories aren’t being told as much as they should. On the “customer side,” I know that people like Scott Mark, James McGovern, and my buddies back at BMC would love to hear about how Agile is going in big shops.
I’ve been keeping my eye out for such stuff, but it’s worth putting out a general request to have more people write-up blog posts. To get the ball rolling, for those of you haven’t been long-term DrunkAndRetired.com podcast listeners (why not?!), here’s a couple Agile war-story episodes we recorded over the past year:
I’d be happy to record a podcast on the topic with you if you’d prefer that over blog posts, emails, or wikis.
To succumb to my habit to go parenthetical every other sentence: along those lines I’ve been talking with several people in Austin, Kert Peterson and the AgileATX group in particular, about turning up the dial on the Agile community in Austin. If you’re in Austin and interested in doing that, send me an email, and I’ll drag you into the efforts ;>
The Will to Change
When I evangelize Agile, one of the points I try to make (when applicable) is that you’re not so much arguing to replace an existing process with an Agile one as to have a process. That is, too often development groups think they have a process, but they really just have a loose collection of folk-lore, anecdotes, and tools. The degree to which you have great people or few people makes a loose process easier. But, for the majority of the development teams out there, a process gives them the time to do the real work instead of floundering about process concerns.
One of the reasons that I like Agile processes are that they commonly include frequent retrospectives where you can ask, “should we keep doing this?” Scrum and XP in particular have iteration retrospectives (every 2 weeks or a month), where you have the chance the change what your doing…if your organization has the will to change. Too often, of course, the org. doesn’t have the will to change, and what was once an Agile process becomes yet another dogmatic process used simply for CYA.
And that’s where thinking about people over process comes in. As I said on Bill’s blog:
as long as you can ask what “process” means and change your work habbits according to the answer you come up with, you’re probably operating under a principal of people over process: the people and roles are defining and driving the process, not the other way around.
Disclaimer: IBM, BEA, and BMC are clients.
Technorati Tags: agile, prjmgmt, programming, software