Heather McLean

Well, I think I had a big win today with the director for my current project. He agreed that the waterfall way of doing things is not working well for us, so we spent an hour-and-a-half discussing project methodologies as a team. By the end of it, I think we had him sold on iterative development (we’ll work on other aspects of Agile later, of course).

Afterward he sent an email out with the things we had agreed upon, and at the top was a direct quote from me:

Deliver faster, deliver more often.

I’m not ashamed to admit that a recent post from Dave Nicolette reminded me of myself. After spending most of the past year being indoctrinated with Scrum, it is very, very tempting to start trying to apply iterative development to everything. I mean, why not? Iterative development is superior, right?

As with all things, the answer is “not always.” With my current project, the temptation is high. The organization and the project already exhibit several agile/XP qualities:

• Continuous integration.
• 30-day release cycles.
• The project has already been broken down into smaller chunks of deliverable features.
• We do daily status meetings. (Although they are an hour long and much less focused than a daily stand-up.)

As you can see, it has the potential… on “the cusp of greatness,” you might say. It would be tempting to think that we could just overlay Scrum or some other form of iterative development and succeed, and trust me, it is very difficult to resist that urge to evangelize Scrum. However, there are several factors that mean I must take a healthy dose of reality first:

• The organization has no agile history, and I would bet that 99.9% of the managers and developers have never heard of agile development, let alone practiced it.
• The “product owner” currently lacks the discipline/desire to commit to a set of requirements for any length of time. (We would be aborting sprints right and left.)
• Policy prevents us from actually working on anything until it is completely designed and documented. (Of course, the policy is not always followed 100% of the time.)
• The developers are not accustomed to self-managing.

Those are just a few off the top of my head. As you can probably imagine, trying to throw Scrum into the mix here would not work out so well. On top of the above hurdles, it would be a hard sell to management, and I have a feeling any initiative would be quickly abandoned if positive results were not immediate.

Still, that doesn’t mean I’m not going to try at some point. I just have to be subtle and introduce things one step at a time rather than going whole hog from the beginning.

I haven’t posted in a little while, so I just wanted to assure everyone that I’m still alive. I had a nice week-long vacation, and now I’m working on getting up to speed on a new project and company.

In the meantime, here’s a little gem from Dave Nicolette that I found amusing and sadly true:

Why is agile software development like teenage sex?

It’s on everyone’s mind all the time.
Everyone is talking about it all the time.
Everyone thinks everyone else is doing it.
Almost no one is really doing it.
The few who are doing it are:

• doing it poorly,
• hopeful it will be better next time,
• not practicing it safely.