Comments on Agile Development Thoughts: No Really, What is Agile?

In response to the questions "what functionality c...

2008-06-11T09:20:00.000-04:00

In response to the questions "what functionality can be included in each release?" and "criteria for deciding what functionality to introduce in each release" :

Keep in mind that iterations and releases are not synonymous. You might have 6 iterations (or more) between releases. That said, each iteration should be shippable, so I'll answer your question as though each iteration was a release.

In any case, the single criteria for what to include in a release is business value. The content of an iteration is whatever the top business value is that will fit into the next iteration.

In most cases, that business value will be determined by a variety of factors including your business strategy.

In regards to interdependencies including the need to create foundation libraries first, Agile treats this issue a bit differently using something that is called incremental design, aka emergent design or iterative design or evolutionary design. There is more information in the following links:

Agile Adoption Stage 2 See the section "The Backlog".

Iterative Design of a Lego Sports Car

Is Design Dead? Martin Fowler talking about evolutionary design.

Seems like the key to Agile development is determi...

2008-06-10T20:19:00.000-04:00

Seems like the key to Agile development is determining what functionality can be included with each release. This planning must include interdependencies and definition of 'core' functionality (i.e. code that other functions are built on). Maybe you have this somewhere, but criteria for deciding what functionality to introduce in each release would be helpful. Issues include: How solid is the requirement (vs subject to change), What interdependencies exist, etc..

You may not like my definition of Agile. That's fi...

2008-01-09T12:44:00.000-05:00

You may not like my definition of Agile. That's fine with me. I don't like it either! I'm much more interested in discussing what Agile brings to the table than trying to nail down an exact definition. Sometimes I think that it may be pointless to define Agile development. It may be better to just talk about the concepts and the practices and say "these things are worth learning about regardless of what you call it or how you define the overarching concept." I still think it is worth a shot so as to establish a starting point for discussion. So, let's discuss the definition of Agile a bit and then move on to the nitty-gritty.

I've updated the original post to take some of the comments into account.

My thoughts exactly: You cannot define a methodolo...

2008-01-09T01:24:00.000-05:00

My thoughts exactly: You cannot define a methodology in terms of the benefits it is supposed to provide.

I guess this is a useful definition for Agile evangelists because with this definition every Agile project is successful (any project that is not successful is, by this definition, not Agile - hey presto, 100% success rates with the methodology!).

A further weakness of this approach to 'defining' Agile is its reliance on being better than other methodologies (i.e. all the points require getting better results than other methodologies would give). So, apparently you are Agile if you're getting better ROI than other methodologies.
With this definition Agile takes the high ground: 'Whatever methods you use, if its better than what you might have got using a different method, then you're on the Agile track.'. Right!

You basically said in your opening section (I'm no...

2008-01-08T20:53:00.000-05:00

You basically said in your opening section (I'm not reading further because what you said was so ridiculous) that if you are successful using Agile techniques then you are Agile, if you are unsuccessful using Agile techniques then you are not Agile.

Shall we define waterfall or traditional programming in the same way: they are only so if they are successful? This seems like an easy, and sleazy, way to redefine success in Agile's favour.

I think that the tendency to make out Agile as a "...

2007-11-29T14:52:00.000-05:00

I think that the tendency to make out Agile as a "cult" is a very clever tactic used to discredit the actual people in the trenches who have successfully used the methodologies. If you can't successfully engage with the ideas, it is much easier to stoop to personal attacks.

I think your description is spot-on, especially the piece that Agile relies on quality. Unmaintainable software is unmaintainable software, regardless of how it's been produced. Agile just relies on it's software being maintainable to deliver value Waterfall development never promises.

I usually attempt to communicate Agile development in terms of releases and communication. Waterfall development intends to deliver once, whereas Agile attempts to deliver periodically. This allows Agile to communicate what it is possible to accomplish before the next release with more accuracy than Waterfall, especially after the first release, and to honestly and openly shape development based on other people's priorities. Most manifestations of Agile development I've encountered share these features.

But this is the other thing; there is only so far you can generalize. XP went off in a completely different direction, but since then many threads and theories have spun off of it and gone in all different directions. To paint all of them with the same brush is to do both them and the methodology a disservice.

"Many shops say they are Agile, but that doesn't m...

2007-11-28T13:25:00.000-05:00

"Many shops say they are Agile, but that doesn't make it so...."

I think that's a good observation.

I've seen Waterfall shops that could care less about code reviews and test plan reviews, much less nailing down requirements with the customer, or changing requirements at the last minute and causing panic. They had layers and layers of bureaucracy and nobody of importance seemed to talked to each other. I call that seriously dysfunctional and a case of bad management.

On the other hand, I've seen Agile shops that could care less about story planning, much less nailing down requirements with the customer, or changing stories at the last minute and causing panic. They had layers and layers of bureaucracy and nobody of importance seemed to talked to each other. I call that seriously dysfunctional and a case of bad management.

I have read enough to know that the Agile Kool-Aid drinkers think they're immune to such concerns. Sadly, that is not the case. Instead, the Agile types keep moving the goalposts: "Oh, that's not Agile!" or "They're doing Agile wrong!"

Guess what? Eventually you'll move the goalposts so far that you'll hit the stands.

Enough big crappy companies with too much money and filled with dumb upper management will "try Agile" (they're already doing this) and where is your movement going to be when they totally bastardize it and projects fail? Well, Kent Beck and his gang started this movement with a huge failure of a project at a big company, but you always conveniently ignore that history. Perhaps in spite of that, Agile still seems somewhat immune to being looked at in a mocking manner except by Scott Adams.

Don't get me wrong there are a few good aspects to Agile, XP, Scrum, etc, but not enough to where I'd totally change philosophies and become a devotee and get baptized. But you people who are neck deep in the movement need to wake up and quit making excuses when the management of companies is turning your way of life on its head. Agile is on the verge of becoming a laughingstock, and already is in some arenas. Just try going to Slashdot and posting your nonsense. They can be quite vicious.

I suppose my point is: don't be afraid to be self-critical about Agile. Don't make excuses.

I think you've got it figured out but I tossed my ...

2007-11-27T16:20:00.000-05:00

I think you've got it figured out but I tossed my own two cents in too with YADFAD. I think one of the things that makes Accurev great is that the developers are the users and you guys think of stuff that helps others do their job. Kinda the eat your own dogfood thing. Thanks for sticking with this.

Mike