Here is a good read; http://www.softwaremetrics.com/Agile/Agile%20Paper.pdf

Like to hear your thoughts.

Craig

As the senior project manager recently hired at a small company I’m mid process of moving us to more agile methods. Because I’ve initiated the move my internal reputation and probably my job are on the line. That’s a lot of risk I’m taking on that many others wouldn’t, and I think that’s the largest barrier to agile adoption.

The reason I’m doing this is my own experience with quality management early in my career and the parallels I see with agile methods. Done the right way for the right reasons it works and done half way or in the wrong place it fails spectacularly, but regardless the cultural change is hard. There are huge challenges just in exploring the cloud of terms, branded processes, and tools. Which are Agile, which are charlatans?

I’m trying to bring agile to my company because I’m confident in my ability to manage risk and change and I believe agile has a place in our business.

Something I’ve not seen anywhere: You can divide agile into agile project management and agile development. They’re good compliments but aren’t dependent on each other. I’m introducing agile PM (scrum) because that’s my domain but I’m not going to ask developers to start doing pair programming or test-driven development.

That is the key point to everything we discuss on this topic….
1) Did the customer just not know what they wanted? If so, what did they say they wanted? Just make something up?
2) Did the customer really want one thing, but said they wanted something else? Good lord, why?
3) Did they really want what they first said, but now the need has changed due to a change in the business environment?

In the case of (1), of course it would be better if the customer just said they weren’t sure what they needed (often because they are entering a new business line), so an exploratory/prototyping approach is the way to go.

In the case of (3), this is a real situation to be managed. It has become the most well-known situation because many past projects were too long nd delivered in a big bang. Everyone should know by know that this a recipe for failure. Whether you call them iterations or phases or whatever, a project has to deliver something usable on regular basis, no longer than 3 months apart.

If you are dealing with (2), go home and get out the Glenlivet…

In the end, I am getting a little bored with the “one methodology is better than another” discussions. No one approach works in all cases. I think it is very dependent on the people doing the work; if you are lucky enough to have ‘generalizing specialists’, go Agile. Most people, however, are more specialists than generalists, so agile may not work in that case. Division of work into specialized tasks has been around along time, for a reason.

So, the issue here is not agile or waterfall, it is effectiveness. Mis-using resources in the flawed belief that one approach is best will breed failure as well. Remember, the customer has other options too. As a Business Analyst, it has been several years since I worked on brand-new development, it has been maintenance of existing systems or purchased packages. Agile or Waterfall makes no difference in these projects.

I’ve been on projects where the client insisted on “complete delivery” – where people express a position that “if it doesn’t do everything I need, it isn’t worth using.” In those cases, the final, formal release will be “everything.” And I’ve delivered on those projects both as waterfall and as incremental development projects.

I’ve been much more successful when managing internal deliveries / beta releases, etc. Along the way. By getting partial releases, and eliciting customer feedback – with a willingness to change the objectives along the way, I’ve been able to operate as if it were an agile project. Even if the end customer is not realizing benefits from the incremental releases, the feedback cycle still provides the “do the right thing” benefits of agile projects.

I like your article Scott, but as a practitioner of both large waterfall projects and of smaller iterative developments I can’t yet buy that Agile is the best model.