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]
6 responses to “If you claim to be agile, then be agile”
This is good advice, Eric. I’m always amazed, being in technology, how many different methodologies are talked about but never implemented. Same ol’ same ol’.
My curiousity: how can a client tell if the vendor is really doing Agile or any other type of methodology? You were expecting Agile, but didn’t get it. What could have been the tip off before the contract was signed?
What I’ve found is that many vendors bring in ‘experts’ in a methodology during the sales process…that’s when I get worried. I don’t really want to be sold on the methodology…I want to be sold on the people behind the methodology. You have good people and you’ll get good results.
The last technology selection project I worked on, I had 4 vendors that I was dealing with. The technology was almost identical with very little feature differences and price was similar. 3 vendors tried to sell me on their ‘methodology’ while the 4th sold me on their people. I bought from the 4th and the project was a huge success.
[…] If you claim to be agile, then be agile | Aligning Technology, Strategy, People & Projects (tags: agile) […]
Where do you draw the line, though? We are engaging a vendor where the manager and her local team are new to Agile methods but eager to learn, but they in turn outsource some development offshore. Should we insist that their offshore developers be at the Scrum meetings, too?
Good question Chris….I don’t know that I have an answer for you other than to manage the vendor closely.
I would think that you’d want the vendor at the scrum meetings….this will help you get a very good feel for what’s happening with the vendor and to ensure that they are tracking closely to what they’ve agreed to do. I wouldn’t invite the offshore resources to the scrum meetings to start with…you should be able to rely on your vendor to manage that relationship. You should be able to get a good feeling from the vendor’s communication whether they are managing the offshore resources appropriately.
Not sure that any of this answered your question though.
[…] If you claim to be agile, then be agile | Aligning Technology, Strategy, People & Projects (tags: agile) Share this:Share […]