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
Two points. First, it struck me as sad that Agile techniques, which started out with a commitment to pragmatism and empiricism over tradition and dogma have now become a dogma unto themselves. Certainly not with everyone, but with the majority, Agile in the mainstream is not a mindset and values (as we might have hoped) surplanting traditional techniques, but rather one dogma surplanting another. People yearn for and respond to dogma.
You mention yourself that Scrum and XP are retrospective within the process itself, but not, as far as I can see, of the process. It's pretty clear that the preference of the industry is to "settle" on a process. There are good reasons for this. Those involved with the development of new methodologies, conciously or not, in turn exploit this tendency and seek to have "their thing" entrenched. Once you have an industry of "Scrum Captains", then your flexibility to innovate within Scrum (or XP, etc.) is severly limited.
To some extent, XP and Scrum have become the "perpetual revolution" that, of course, isn't. This is not a knock on XP and Scrum, or even their institutionalization. The fact is that something *has* to be institutionalized, and Agile is certainly an improvement. My point is that 'perpetual revolution' is a synonym for 'status quo'. XP, Scrum, and other 'distilled' Agile techniques have already happened.
To that point, I also found it a bit off that experience was given such primacy. Experience can help, but it can also be a hinderance. The key is whether the experience was introspective and reflective or merely rote. I would say that most people's experience tends to be rote, and rather than lead to greater understanding, is simply 'time invested in the status quo', and thus antithetical to the kind of experience you're talking about here.
Even making that distinction, however, reflective experience is useful, but I'm not sure it's necessary. Indeed, my own experience, and I dare say your own, Cote, was one of people with almost *no* experience, who independently replicated many of the ideas of Agile development. Certain techniques were lacking, but we had a flat organization, transparent design, emphasis on communication, and constant customer consultations.
The experience/non-experience dimension is one in which value comes from both ends. Unique insight and fresh perspective are both valuable to process innovation.
I prefer the term "Scrum Lord," coupled with the derogatory alternative, "Scum Lord."
As with all things once they're written down (like specific Agile implementations such as Scrum), it's all to easy for doctrine-driven people to treat the printed word as The Logos. I'm not big on Logos-think. It goes pear-shaped quick. Indeed, I've had many exciting, late night conversations with Zane on the topic ;>
People in organizations, of course, are often eager to latch onto a set way of doing things. There've been countless times in the shops I've been in when someone has made an absurd statement like "we can't choose not to have a retrospective, the retrospective is all about choosing what we do! And it's required!"
So, yes, treating Agile like dogma is just dog-doo. I've butted my head against that dilemma many times. Once again, our man Cockburn has blazed the trail on this topic.
See my man Heraclitus…and never mind the mind-screw vortex in the statement "nothing endures but change [except the fact that nothing endures but change…ahhh!]"
Cockburn is awesome. And so dapper too. He's the Red Irish to your Black, Cote!
/Muito obrigado/ for the kind words and good thoughts … just writing to fix a couple of broken URLs: the "Iterations" article has a '?' (%3F) at the end:
http://alistair.cockburn.us/index.php/Are_iterati… (http://tinyurl.com/39wjul)
and the "dapper" picture is probably
http://alistair.cockburn.us/index.php/Image:Sepuk… (http://tinyurl.com/3ap4eq)
although this one might be a runner up:
http://alistair.cockburn.us/index.php/Image:2003w… (http://tinyurl.com/3ap4eq)
And yes, "Agile techniques, which started out with a commitment to pragmatism and empiricism over tradition and dogma have now become a dogma unto themselves." … that seems indeed to be a common characteristic of people, to simplify and dogmatize /whatever/. Even if someone wrote in a holy testament, "Be kind to each other", we'd find before long people slugging it out because how someone else was being kind didn't fit their local dogma (… oh, that already all happened, oops…)
cheers – Alistair
Thanks for the corrections/updates!