As some of you may know, I’ve talked about agile methodologies in software development in previous blog posts (see links below). The topic of Agile methods still seems to be quite hot these days and many organizations want to ‘go agile’ and many vendors sell themselves as being ‘agile’.

This is great….but many of these same organizations and vendors don’t really understand what it means to be agile and to use agile methodologies in projects. It isn’t just about having a daily scrum or developing in iterations…it also includes working with your teams and clients in a more agile way and involving those people throughout the development process. This involvement of clients is a key piece of the agile world….but some organizations just don’t get it.

I’ll use an example from my past to illustrate:

I had a vendor working for me to develop a software product. The vendor was selected based on experience, recommendations and the fact that they were user iterative development methods. I spoke to them about their iterations and methodologies and was given the rundown of how they do daily scrum meetings every morning and are very agile in their approach. This was great news to me.

The project was scoped and approved and the vendor began the development process. As part of the expectations that I set at the outset, the vendor knew that I wanted to be very involved in the iterations and they agreed to do so. The day of kick-off came and went…and then another few days went by with very little communication from the vendor (and a few emails & phone calls to the vendor from me).

A week passed with no communication….I was a little disturbed but I thought that the 4 week iterations must have the vendor extremely busy and that I’d hear from them the next week. The folloing week came and went (2 weeks since kick off) and I had heard very little from the vendor and zero insight into their progress.

During the 3rd week I was finally able to get some time with the vendor’s project manager (note to vendors: don’t ever let 3 weeks go by without speaking to your client!) and he told me that they were still in ‘definition mode’. Huh? They had the requirements for the first three iterations….why were they in ‘definition mode’? What in the heck is ‘definition mode’ anyway?

I asked the project manager what he meant by this and he said that their first ‘iteration’ was always a project definition and requirements gathering mode and then they would move into development.

I asked him to look at the scope of work and explain to me where it says that the first four weeks would be spend gathering requirements. He couldn’t find anything like that but said that it was common practice for them.

If I had the decision making powers, I would have went to another vendor…but that wasn’t my call…the decision maker liked this vendor and so we stuck with them.

After 6 months of development and many discussions about what agile/iterative methods are and questions about when I could see some output from the iterations,, we were finally able to see the ‘finished product’….and it wasn’t anything like what we asked for or needed.

My boss finally allowed me to close the door on that vendor and bring in a few software developers to tweak the product. We were able to get what we needed out of it with another two months of work.

Funny story about that vendor…they finally stopped using ‘agile’ to sell and went back to their old waterfall methods and they are doing well. They have some good people on board but they were trying to be something that they weren’t.

The point of this story? If you claim to be agile, be agile. Don’t use agile and iterative development methods as a sales tool and then try to sneak waterfall methods into the project. Truly embrace the agile methods and in turn, embrace your clients and involve them in the development process. You’ll save yourself a lot of time, money and heartache.

Oh…and if you want to use waterfall methods….go right ahead. Take the same advice to heart though and embrace your clients during the development process and your projects will turn out much better than if you try to develop in a black box.

A few more of my posts on the subject:

• Agile or Waterfall…does it matter?
• Billy McCafferty – Introduction to Scrum and Agile Development
• Agile Project Management & Product Strategy – A Case Study
• Agile Management

[tags] Agile, Iterative Development, Client Management, Project Management [/tags]