Dave Nicolette tells what happened when Jon Kern (one of the originators of the Agile Manifesto) gave a talk on agile development to the managers in a large corporation’s IT department.
“Jon knows his stuff, and the content of his presentation was right on the mark. But I got the distinct impression he is unaccustomed to dealing with an ignorant, hostile audience. He answered their questions in a way that suggested he had overestimated their knowledge of the underlying concepts. His answers would have been appropriate for an audience that already had a general idea what agile methods were about, and who were looking for a little more information. Instead, he had an audience who would rather stick their fingers in their ears and chant “La, la, la!” than to be confronted with the possibility that Firesign Theatre had been right all along.
Dave doesn’t say what forces brought Jon into his workplace, and I’m guessing when I say it has all the hallmarks of management preaching. Does it do any good? I don’t know. In every situation like this (I’m guilty of having done it myself) there will be those among the audience who are ready to hear the message, and for whom this is exactly the spur they need to jump in with both feet. And there will also be those who are antagonistic to the idea, and who entrench themselves even more after such an exercise. Mary Poppendieck suggests that the nay-sayers should be disenfranchised, pushed out into the corridor while the rest get on with whole-hearted enthusiatic agile adoption. Presumably because that’s the cheapest option in both the long and short term. These lost souls will then either leave (she hopes) or try to change things back, or snipe and spit from the sidelines. Only the first of these presents a win-win opportunity, but surely it doesn’t have to be done that way? Is it just possible that those folks actually have something valuable to contribute as the organisation moves forward? Or is the cost of including them too high, when everyone else just wants to get on with it. Include or exclude, the result will depend on the individual. And those around them. What forces created an organisation whose strategy is heading one way (towards agility) while some of its staff actively oppose that strategy? Was someone being less than authentic when the hiring was done? Or has someone in a leadership position learned something that ultimately will require a different workforce? Useful to know the difference when attempting to instigate change…
I’m going to quote an entire email sent by Kent Beck to the [extremeprogramming] group on Yahoo, because it hits so many nails right on the head all at once:
In trying to understand what you’ve written I don’t find the traditional dichotomies of software engineering very helpful.
- Unit vs. functional test — I test what I see. Sometimes I think big thoughts and I write big tests. Sometimes I think little thoughts and I write little tests. My first test of a system is a big test of a little system. Are these unit or functional tests? The question doesn’t help me.
- Top-down vs. bottom-up — I try to have a “whole” system quickly, then expand the parts that need expanding. Is this top-down or bottom-up? The question doesn’t help me.
I could go on with other dichotomies that aren’t helpful to me– black box vs. white box, programming vs. QA, phases, customers vs. programmers. I wonder how our thinking about software development got divided into such tidy-yet-unhelpful little boxes.
Three Rivers Institute
In Agile implementation anti-patterns Esther Derby has it just right, in my experience. She concludes:
“Changing the organization to Agile methods means that managers have to change, too. And letting go of the old top-down, command and control model of change is the place to start.”
Of course, that’s easier said than done…
I’m basically an analyst. I’ve developed domain models for numerous different types of business, and latterly as an agile coach I’ve done a deal of process analysis too. In these roles I’ve always found the use of hierarchies to be very limiting and frustrating. Relationships between things rarely, if ever, fall into a single neat tree. And whenever I’ve seen a hierarchy imposed on something, future pain is the inevitable result.
So today I’ve added a ‘see also’ link to my blog entries, courtesy of David Raynes’ MTRelatedEntriesByKeyword plug-in for Movable Type. (It worked straight out of the box.) During the coming weeks I’ll gradually add semantic links between the entries and see what effect this has, if any, on the use of the category indexes.
One afternoon this week I was sitting in a meeting room with a manager in a local company. To help me understand some context, I asked how the company was organised. She jumped up to the whiteboard and drew a management hierarchy. With the CEO at the top. I hate hierarchies. Maybe it’s my problem, but I just don’t like people in an organisation thinking that they are somehow “above” others.
Wouldn’t it be great if people thought of their organisations in terms of responsibilities, interactions, client-supplier relationships? What if everyone – managers included – behaved as if they were performing a service as a role in a Collaboration? What if everyone respected the skills of the specialists around them?
Just once, I wish someone would talk about their job using CRC cards.
It seems to me that one of the principal reasons for the apparent rapid rise of agile methods in software development is the romanticized battle between programmers and managers. Spend any time reading any extreme programming discussion group, for example, and eventually the topic of adopting XP in the face of management resistance will crop up. Agile methods, and XP in particular, would appear to be the saviour of the oppressed programmer; finally the evil tyranny of the waterfall and the heavyweight methodology are crumbling in the face of guerilla resistance from programmers who knew they were right all along! Or that’s how it seems to them.
Does the extreme (sic) zealotry of the programmers represent years of pent-up frustration with the situation in which they found themselves? Do they blame management for controlling them, for keeping them strait-jacketed in heavyweight methods for so many years? If that’s the reason, why were such methods of control deemed necessary in the first place? Two words: manufacturing metaphor.