More = Better ?

I had a discussion yesterday that touched briefly upon how agile our project is (or is not). The answer was that we're probably more agile than some other projects I've been on, but that we could be more agile. The underlying assumption was that things would be better if we were more agile. I think this assumption happens to be true, but it's not fundamentally true. Let me explain.

A former manager once said to me that he thought I was process-oriented. My response was, quite emphatically, "I'm not process-oriented; I'm results-oriented!" (I swear this is true. It just popped out.) The reason I'm a proponent of agile techniques is that I think we can achieve better results using them. Otherwise, what would be the point? If we made some change that was more agile, but our results didn't improve, there wouldn't be any benefit. Or if we made some change that did improve our results, I'd be in favor of it regardless of whether or it's considered "agile".

Note also that I'm using "results" in a very generalized way. For instance, if the team were to deliver the same product, feature set, quality, etc. but with less overtime and stress, and more time spent relaxing with families, and so forth, I'd consider that to be an improved result.

The default in my area seems to be for projects to be very plan-driven. Frankly, I don't think they've worked well. For this reason I've looked to alternatives, including many agile techniques. But the point isn't to be agile for the sake of being agile; it's to get better results. Let's make sure we don't forget this.

Comments:

For those of us on the periphery, who can only guess from context, could you explain what you mean by "agile" techniques? I suspect this has to do with making the development team able to more rapidly respond to changes in the environment, such as new APIs, changing customer requirements, moving ship dates, etc. But that's just my semi-educated guess.

However, I think your point, whatever "agility" means to software development, is a good one. I remember being at the Apple Developers' Conference in 1990 or 1991, when "Object Oriented" was the buzzword of the day. That same timeframe in pop culture, oat bran had risen to prominence for being cholesterol-lowering, and it was showing up in everything from pretzels to toothpaste. One of the speakers at the conference advised developers to "avoid object oat bran" a phrase that has obviously stuck with me.

What he was saying was, don't just sprinkle object-oriented techniques into your code for the sake of following the popular fads. Use them where they make sense, avoid them where they don't. Put oat bran in the muffins, not the spray-cheeze-in-a-can.

I'm suspecting that "agility" is becoming something like object oat bran in the industry right now.

Posted by Andi on February 22, 2008 at 09:35 PM PST #

Responsiveness to change is indeed one of the values of the agile approach. I think there is a lot of merit in this and in other agile values and techniques. Unfortunately, there is a lot of faddism and consultant hucksterism going on too, which has led to something of an agile backlash. There's a lot more to be said about both of these topics. Perhaps I'll address them in future posts.

Posted by Stuart Marks on March 06, 2008 at 05:39 AM PST #

Post a Comment:
Comments are closed for this entry.
About

user12610707

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today