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?
Originally from Ben Lee -ReplyDelete
Interesting and thought provoking article. Most of your concerns are common struggles I see everyday. My gut reaction is that the easiest way to make someone "believe" in agile, is to show them results. Let your delivered software be the salesman. If you can show them tangible and demo-able progress each and every iteration, an understanding of what your current obstacles are, and how your evolving your development practices to constantly deliver more value .... it should be too hard. Granted, that doesn't solve the problem of the initial sell. I am going to discuss this with some of my coworkers and see what we can come up with. I will let you know what they say.
Also, I would suggest focusing on the core agile principles more than the particular practices. The practices are important b/c they are the tangible manifestations of the principles, but it easy to lose site of they why when discussing the how. A lot of processes I have seen, especially at larger companies, fall down in the face of questioning. Focusing on the core principles (e.g rapid and constant communication, valuing people and conversations over documentation, etc) may help you in finding out why agile might succeed over other methodologies. If the client is consistently delivering software using something else, let them keep doing it. If they aren't, why aren't they? And why hasn't anyone figured that out before and changed it?
Ya your right in that my focus should really be on the principles and not the practices. Maybe that's part of the problem of the management sell. If i go to people saying "i need you all to do this stuff" they find it difficult to see the payoff. If instead i say "do you think we would benefit from a smaller feedback cycle and better client interaction" it becomes a lot harder for someone to say no.ReplyDelete
Originally from Sensei -ReplyDelete
This might sound a little strange, but why not bring agile about in your company in an iterative manner? Then you don't need to sell it :)
That actually looks like what I (and a couple other co-workers) are going to do. We are working on rolling out an integration environment and trying to break different projects down into iterations. Its really the customer dependent stuff like feedback and customer involvement I expect to be a bit more difficult.