When implementing a project whose team is made up of customer employees, and vendor consultants, there are to be honest many competing agendas in forming that team. The customer wishes to keep costs down, and utilize the consultants for as few hours as possible and still get the job done. The Vendor wants their consultants to be vital to the success of the project and to be key players, thus causing the customer to rely on the consultants for a longer period of time.
It’s all money driven from a management perspective. However despite all that, often times the team members could care less. Their goal set is always different than those worrying about contracts and costs. The successful implementation of the project is what is the most important to both consultants and customer employees. So no matter what the overriding agenda is from management, typical team dynamics are always the same as if everyone worked for the same company.
So given this, why aren’t more mixed implementation teams using Agile development rather than the Waterfall method?
From my experience, teams aren’t using Agile for a few key reasons.
- Change – Customers and Vendors do not want to change how they have been structuring contracts for years, which they view as a tried and true method.
- Having two deliverables; Requirement Study, and Finished Product, is much easier to manage than having many deliverables. (Sprints)
- A perception by the customer that using the Agile methodology will result in longer project times, and therefore higher costs paid to the vendor.
- Worry by many that the overall goal set of the project is not understood with the Agile methodology so you can’t properly estimate the overall cost of the project.
- Trust – Most managers do not trust vendor provided consultants.
These are all valid concerns, so how do we in the software industry alleviate them?
I think it is going to take a little more than just getting a few more evangelists into our industry. Most of the above points deals with fear and trust. Fear that something might not work is most often times more important than the know ledge that something won’t exactly work well. So how do we as developers, implementation experts, project managers, and sales people convince the customer and our own vendors to accept this new way of doing it? First and foremost I believe it’s up to the project teams to prove to management and sales that this leads to happier customers. Happier customers tend to purchase more products, and likely will invest in more services as well. Secondly, we have to begin to think differently. It is so easy to fall back on the old “document what your going to do, then go do it philosophy” that thinking in the Agile mode becomes an after thought.
So how to we as project teams begin to think differently?
I think it’s important that we all come to some consensus that software development and architecture design is not a process that has been perfected over thousands of years. It’s a relatively infantile field in regards to physical construction disciplines in that one can say it’s only been around for 60 some years, and that improvement is possible.
If we all agree to this philosophy, then maybe we can begin to feel as if improvement can be made, through a new more flexible methodology.
Also I think it’s important to fully grasp the concept of what Agile is and how it improves team work, and better more directed delivery of solutions.
I would also recommend reading anything by Scott W. Ambler of IBM. The guy is a very good speaker and accomplished writer.
see, you don’t get any of my responses from yahoo pidgin
