Recovered from the Wayback Machine.
A week or so ago I made a comment about not caring for the new current crop of agile programming paradigms including one of the more controversial, eXtreme programming. Stavros asked what my concerns were about these approaches. As a response, I pointed to the web site for the Agile Programming Manifesto. If a picture is worth a thousand words, a web site and a picture is worth even more.
Let’s take a look at the Manifesto and the site.
Leaving aside the use of such terms as manifesto the site promotes certain development philosophies and approaches. Among these are:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
This as compared to what, delivering software late and disregarding the customer? For all that we tease companies like Microsoft about being devil driven rather than customer driven, many of the company’s deliverables are customer driven–just the customer tends to be the corporation rather than necessarily any single user.
However, what the makers behind the Manifesto are promoting is incremental releases–the continuous state of beta that we see at Flickr, Google, Yahoo, and other sites. Yup, that’s where it came from folks: agile programming.
The principle isn’t bad: release small, release often, and don’t get stuck in analysis paralysis. However, the problem with the concept is that many applications can’t be released small, and beta is only cool in certain small circles. Most of us don’t want the systems we’re dependent on to be in a permanent state of change, of beta. I don’t want my income taxes managed by beta software. I don’t the hospital lab’s work to be managed through beta software. I certainly don’t want NORAD to use “Radar by Google”.
The release early, release often doesn’t solve the problems of managing larger and critical need software applications. As for applications that have followed this approach, such as Gmail and others of that nature, we’re already seeing a great deal of pushback against features appearing and disappearing without warning, and applications failing, and cute little plumbers popping up saying, “Ooops! Something broke”. It’s wearing thin; it’s no longer so fun.
Agile programming pushes a four-week release cycle. It’s not a bad idea — define what you can deliver within a four week timespan and then focus on adding new functionality with each release. The only problem is, there’s no room for humanity.
When you timebox an application, and a critical person falls ill, you disrupt the flow and since so much is dependent on this flow you could be months trying to recover. Agile programming is incredibly inflexible when it comes to time, and puts the onus of sliding applications and failed deliverables on the developers rather than on the management. In fact, timeboxing is a lazy manager’s tool–it’s a way of pushing a team off to the side and forgetting about them until time to take credit for a deliverable. Where did technologists ever get the idea that timeboxing was our benefit? Well, all I can say, I have a nice Arch in St. Louis I’m selling and you must be buying.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
What a crock of shit. This is machismo programming at its worst.
Requirements can and do change in development. It is important for a team to be able to incorporate a change in requirements, especially ones driven out by the development process. But by introducing this as a goodness, the concept undercuts understanding the business and the business needs during design, when change is cheap.
What the Manifesto developers are pushing here is modular programming–isolated bits of functionality so that changes to one piece don’t impact on the other pieces. This is a goodness, and one I support. But it’s also been around since we started working with languages that allowed for this concept. By tying this modular or component based development into requirements, we’re undermining the essentialness of upfront design.
Yes, yes, flap your hands — it’s not fun to do requirements. It may not be fun, but it’s a hell of a lot better than throwing something to your users and then gather requirements based on the oos and screams you get as a result. Let me tell you something: don’t let the weblogging community noise fool you–when you ’surprise’ your user, you’re undermining their confidence in using your product.
I gave my older PC laptop to my roommate, with WindowsXP instead of Windows 2000 installed, and OpenOffice instead of Office. He was happy to have an up to date machine, but I could see his level of stress rise when he started working with the products, even though they were all very functionally similar. My roommate is not a stupid person–but the number of people who like to ‘play’ with beta, and get all excited at newness is a small fraction of the number of people who just want to use their computers to do things.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
See my view of timeboxing above.
Business people and developers must work
together daily throughout the project.
In a word? No.
No, the business people don’t have to work daily with the development team. There are two reasons for wanting your customers with you daily: first of all, a crappy job of gathering requirements. Second, rather than set user expectations, get them involved daily so when the application doesn’t work as planned, you can all share blame equally.
I agree that the community that uses the software should be involved. There should be testing; there should be a way of communicating concerns and bugs to the development team; the community should be involved with creating test plans; the community should feel as if they’re a part of the process. There should be mutual respect between the community and the developers…but daily contact?
Why? This one I don’t understand, though I imagine if I paid a couple of thousand dollars for one of the new agile programming conferences or training sessions, I would get the answer.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The thing is, what each individual needs differs.
Some developers do poorly when management hovers over them. Other developers, though, need this or they can’t focus on getting a project done. There is no one size fits all environment–agile programming isn’t a magic wand that somehow transforms all of the developers into one specific type of person.
And that’s one of the things I have most against agile programming: it assumes a specific type of developer, and almost inflexibly forces others into a mold that conforms to being that specific type of developer. Probably because the Manifesto is a product of those who are a specific type of developer–and we’ll really get to this one later.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
I love this — the tech community has spent the last 30 or so years developing techniques to work remotely, only to toss it aside because face-to-face is the way to go.
Perhaps face-to-face is the way to go because many of the Manifesto developers don’t have the writing skills–or interest in same. If you’re not color blind and you live in a land of people who can only see blue and yellow, then seeing red and green is an abberation. Given time, even the most color sighted people, will only see in shades of extreme blue, and extreme yellow.
(”That’s the color red.” “No, that’s just a very dark and vivid yellow.”)
If you don’t have patience for writing, or your writing skills aren’t particularly good, or you just don’t like to spend time doing more than ’skim’ any written material, then I imagine that you view face-to-face communication the only way to go. Just think: there’s no accountability when nothing is in writing.
(”Whose idea was this?” “I don’t know.” “Me, neither.” “It was Jay’s.” “Jay doesn’t work here anymore.” “Yeah.”)
But I know where the agile programming people are coming from with this one. They’re saying that people shouldn’t work in a vacuum–that we need to work as a team. Rather than sit slumped in your cube working a problem on your own, ask for help. However, face-to-face has nothing to do with solving this problem, and everything to do with the heads of the people doing the talking.
(This is where the ‘pairs development’ approach comes in from eXtreme programming — all development is done by people working in pairs. I’d rather muck out horse stalls than do pairs programming. Seriously.)
Working software is the primary measure of progress.
As compared to documentation, testing, written use cases or requirements, project plans, user feedback….
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
No one can sustain a constant pace indefinitely. There is little more mind-numbing than a constant pace — to have no peaks and valley’s in one’s job.
Now it’s true that development in crises mode is probably the number one reason developers burn out; and forget the 16 hour day schedules. But a constant pace can be just as unhealthy as one based on periods of frantic activity followed by recovery.
The farmer works longer hours in the summer and fall than in the winter. The doctor has days when she visits the hospital and days when she sees patients in her office. The accountant has month end. An unvarying pace is not healthy. The Manifesto developers know this, but what they’re doing is pushing back at the overlong hours and working in crises mode. Unfortunately, managers don’t know this–all they see is ‘maintain a constant pace indefinitely’.
Continuous attention to technical excellence
and good design enhances agility.Simplicity–the art of maximizing the amount
of work not done–is essential.
Now, these I can agree with, without reservation. But not the following:
The best architectures, requirements, and designs
emerge from self-organizing teams.
Oh wouldn’t it be wonderful if we lived in a land where no one is aggressive, no one shy, and there is no bias. But since we don’t, the mechanics of organization have to account for these behaviors being a major part of any ’self-organizing’ team. Self-organizing teams are ones where he or she who is most dominant, wins.
For the most part, as anarchists, we suck. We’re abusive, intolerant, inflexible, self-indulgent, fearful of difference, reward the aggressor, and snear at the passive. We like pretty lies, we want to believe regardless of the facts, and we’re easily distracted. We’re ruled by our emotions first, sex second, and then if there’s anything left over our intellect. Oh, and a tiny part of ourselves is formed of compassion–usually invoked via some form of pretty lie. Most of our political systems are based on people having a good understanding that this is how we are as people.
Over time, we have learned to evolve as a group and by doing so we have become better than we could be. This evolving is considered “self-organizing” behavior, but it’s self-organizing that takes years, decades, centuries, and still isn’t right. We elected Bush, didn’t we?
Giving people room to reach their full potential means providing a stable enough environment that they feel they can explore and range. It doesn’t mean that they have to keep their back to the wall while the more aggressive elements in the group go gunning for the rebels.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
Coerces and enforces compliance to group behavior is what you mean. Oh, it may be a good thing, but that’s what’s happening. What this does is take the responsibility for being the ‘bad guy’ off of the manager of the group and places it firmly into the hands of the group–which then acts in typical pack dog behavior, demanding bared throats from some, tossing biscuits to others.
Postmortems on applications just rolled out isn’t that unusual and it is a good idea. But when you start referring to a group’s behavior, you’re walking past practice and into personality and that’s when things get very, very dangerous.
I’ve just spent a few minutes ‘trashing’ agile programming. What do I recommend then? After all, applications are delivered buggy, schedules aren’t met, customers aren’t happy, and so on and so on. So, Miss Smarty Pants–what’s my solution?
I’ve been on several projects over the years, from small to large and working with several different types of business. Some were successful efforts, some less so. Spectacularly less so in a couple of cases. One of the successful ones was for Nike years ago, developing applications for its clothing line. I worked with a couple of pretty sucessful groups at Boeing. Another was at Sierra Geophysics –Halliburton closed the doors on our group primarily because of advice from a Big Consulting Company, not because we weren’t successful. Probably the most successful was at John Hancock.
There was one thing these groups all had in common. It’s something that the Agile Programming Manifesto group didn’t have. Take a moment to go back to the Manifesto page. Look at the photo in the background. Other than it being a rather disturbing picture, can you tell me what’s missing?
Unless you answered “diversity” go to the back of the class and put on that damn pointy hat.
The Agile Programming Manifesto and most of the agile programming paradigms and techniques are the product of a specific group of people: primarily white, all male, and most living within the Silicon Valley region of California. I bet if we go further, we’ll also find that they share the same set of behavioral characterists, and perhaps even background. What is missing is diversity.
There are no women. From the picture, there are no minorities. There aren’t any people from Austrialia, or Africa, or the Middle East. I didn’t check–are any European? Russian? I don’t even think there’s anyone from Canada. Certainly not anyone from Mexico or South America. I don’t see any Japanese or Chinese or Korean folk. How about someone from Malaysia?
No, what we have is the tech equivalent of The Beach Boys. (Excuse me, the Beach Boys joining the Jesus Freaks, because as I was reminded by McD in comments, many of the agile programming ‘camps’ have all the makings of modern day cults.)
What agile programming is, is a way of compensating for behaviors based on the fact that too many teams doing technology share these same characteristics. Mostly male, mostly white, mostly of a same personality, same culture and economic status, and sharing some of the same massively competitive, obessive, and lack of balanced approach to technology.
Think of Robert Scoble and his 863 feed subscriptions. This is a group of people who have no patience for details, are obsessed with being ‘on top’ of anything new, regardless of how new it is, and who don’t want to take the time for ’slower’ mortals to do their thing. The whole principle of agile programming is this: get the hell out of my way and let me code something. They want on-demand feedback from the user, they don’t want to be personally accountable for problems, and they want to have a continuous cycle of pats on the head for frequent releases. They eat alpha for lunch, and piss out betas by afternoon tea.
All of which is compensation for the fact that most of the developers work with people just like themselves. There is no diversity.
Returning to the projects I’ve been on, the one thing they all had in common was they were diverse. In all cases, at least 25% or more of the development staff members were women. In half the jobs, women were managers. At John Hancock, not only were there women developers, but we also had black developers, Asian developers, not to mention a geographically diverse labor pool: we had a couple people from Russian, several from India, one from South Africa, and one person from Vietnam.
This project was critical–it was based on an industry wide lawsuit and all insurance companies had to comply with government mandated demands to have certain processes in place at a certain time. And we were delivering. More than that, we were delivering virtually bug free software. But we didn’t adhere to SCRUM or follow eXtreme programming or anything like that — our projects succeeded because were were more unalike than we were like. As such, no any one person’s ‘bad’ habits would find a likely mate in his or her worker’s. More importantly, we were able to learn from each other’s ‘good’ habits.
(We also had good management. All the agile programming techniques in the world won’t compensate for bad managers. Read through that Manifesto: where is management accountability? Where’s Tom Sawyer, I want to paint a fence!)
Any time in any industry you have fundamental problems with the industry as a whole, so much so that you have to start up a whole new sub-industry ’selling’ techniques to fix it, it’s because the industry is not diverse. End of story. That agile programming is now the new marketing darling doesn’t change this fact.
Agile programming, with its tendency to enforce a particular work style, as well as reward a specific set of behaviors, ultimately validates the tech industry’s lack of diversity.