As our focus shifts we find ourselves trying to develop a niche as a project specialist shop. Part of that process has been having a lot of conversations. Conversations about project metrics, project accounting, tools, best practices, methodologies, et. al.
Thursday afternoon I was having just one such conversation with one of our managers. The topic of agile development came up, what it does well, how it would fit into our business and what we can learn from it. Up to this point we have mostly approached projects in a very traditional, waterfall-esque manner, and more often than not it has worked. However there is always room for improvement so, being a bit of an agile "believer" I've been wondering why not adopt the approach.
The general consensus was as follows:
- Iterative development is a fairly solid way to enforce discipline, make a project segmentable, and improve quality by shortening the feedback cycle.
- Establishing the end of iteration review culture, essentially showing our work to our clients on a periodic basis while in development is a good thing. It's always preferable to deliver what the client wants now, not what they asked for 6 months ago.
- TDD, from a management perspective, has its advantages but as always its a hard fight. Personally I'm preferable to the "why even ask just do it approach" but the topic came up so the natural reaction of a manager tends to be "what do i get out of it besides lost time." Fortunately one of our guys has had some luck showing the benefits so this might be a battle we can win pretty easily.
But in despite of these net positives there were some unanswered questions. Most of them revolved around metrics and measurement. Things I vaguely know the answer to but having never been an iteration manager or agile project leader would need to read into a bit before being really informed.
The most signifigant question, and really the point of this post, is how do you sell agile to your customers?
Considering my companies background the majority of our clients are large, fairly traditional organizations. None of our clients with whom we do project work are inherantly agile shops. The leads to conversations about some really core aspects of the methodology that I can't answer, like:
- How do you convince a company to dedicate a resource to being available to do periodic reviews, iteration review meetings and other feedback you need in order to have that short feedback cycle?
- How does the billing and project initiation process work? Specifically we do work in two different formats: Time and material or fixed fee. Time and material projects would be fairly easy to do in an agile format. In that format you essentially bill as long as your doing work. Fixed fee though are problematic. In a fixed fee project you generate a proposal up front, quoting a particular amount of time and money and at the end of the project that is what you are paid. With agile it is encouraged to make changes to the requirements as time passes which has the potential of changing the overall scope. However if the project was quoted fixed fee the increased scope doesn't necessarily result in a expanded budget. Additionally how do you estimate that agile project and generate an up front number? If you have a set of previous agile projects you can likely base your estimate on that however what if you are just getting started in agile consulting?
I have had the opportunity to work on agile projects before, and have found that the clients are almost always happier with the result, the developers feel more consistantly focused and challenged and the quality of the code if improved. I have not, however, worked on an agile consulting project. So this being my first post and all an open question to anyone in the know? How do you sell agile?
