Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Dr. Dobb's Agile Update 06/09

In This Issue

  • RFPs the Agile Way -- or -- Fear and Loathing in the Procurement Department
  • Take the "State of the IT Union" Survey and Potentially win a copy of "The Economics of Iterative Software Development" by Royce, Bittner, and Perrow
  • Hot Links

RFPs the Agile Way -- or -- Fear and Loathing in the Procurement Department

Many organizations will outsource software development projects to external services vendors, either because the organization doesn't have the capability to do the work themselves or they feel they can get better value by doing so. Because of the increasing evidence which shows that agile approaches to development are more effective than traditional approaches to development, they often want to take an agile approach to outsourcing. This would be a perfectly reasonable request if it weren't for the minor detail that their procurement processes often reflect traditional styles of thinking which are antithetical to agile approaches. What can they do?

First the good news with an agile approach to outsourcing. The increased visibility which agile project teams provide to stakeholders make them easier to govern, even when they're outsourced. The bad news is that this assumes that the customer, the organization outsourcing the work, is capable enough to procure the services of an agile supplier, the organization doing the work. This in turn implies that the customer is able to issue a request for proposal (RFP) which reflects the realities of agile development, the topic of this newsletter.

Traditional approaches to RFPs are questionable at best. They are typically based on the premise that the customer specifies the work to be done, this specification is provided to potential suppliers, the suppliers ask clarifying questions, and then once the answers are provided the suppliers are given time to respond with a proposal. Most traditional RFPs require that the supplier provide a precise estimate and schedule for performing the work, and very often a proposed architecture for the solution. Sometimes the customer will be flexible and accept a ranged estimate and schedule although this is unfortunately rare in practice. Then the customer will then choose the proposal which they feel most comfortable with " experienced customers know that they shouldn't necessarily accept the lowest bid.

The traditional approach sounds great in theory, but in practice it doesn't appear to work out very well. As I've written in previous newsletters the fixed price/bid approach to software projects where the scope, price, and schedule are set at the beginning of the project works very poorly " the customer is unable to accurately define what they want, and even when they do it takes them so long that their requirements change anyway, and therefore it is virtually impossible for the supplier to provide even remotely precise proposals. The traditional approach has it's roots in generic project management strategies, and I'm sure this is a great approach for projects where you really can specify the requirements accurately. However, very few development teams find themselves in a situation where this is actually the case, regardless of the wishful thinking of senior management.

Because we know the traditional approach works poorly I have argued that it is in effect unethical to follow such a strategy without giving the customer other options for working and educating them on the trade-offs (see the links at the bottom of this newsletter). This is of course very easy to say, but the reality is that the customer drives the RFP process and even though the supplier knows that the traditional strategy is problematic they rarely push back because they're afraid to lose the business. The end result is that the customer never gets the feedback that they need to improve their RFP process and continues to accept unnecessary levels of project risk.

So, let's assume that you're in a position to change your organization's IT services procurement process. Yes, that probably gave you a good chuckle, but the reality is that somewhere in your organization there is in fact someone(s) in this very position. So, if you can't change your approach then please email this newsletter to them and ask them to think about the agile strategy that I'm about to describe. You can't improve your procurement process if you don't take the first step.

The strategy has its foundations in three concepts from three different publications within the agile canon. The first concept is the third value of the Agile Manifesto, "customer collaboration over contract negotiation", which tells us that although the contract between the customer and supplier is important a far greater determinant of your project's success will be whether the people involved will work together closely. The second concept is derived from the fourth value of the Manifesto for Software Craftsmanship which states "not only customer collaboration, but also productive partnerships". This implies that not only should everyone strive to work together closely they should also strive to work together effectively. The third concept is from lean development governance, which includes a practice "align business strategies and IT strategies". This practice basically tells you that a traditional strategy to RFPs is best suited for traditional strategies to development, and if the customer wants the supplier to adopt an agile strategy to development then the customer must adopt a corresponding agile approach to their procurement process.

To effectively procure the services of an agile development team, an "agile RFP" would require the supplier to:

  • Indicate who are the people, or at least the type of people, that the supplier will have on the project. The supplier should provide resumes and the customer will likely choose to interview some or all of the team.
  • Follow a reasonable set of rights and responsibilities for both the customer and the supplier to adhere to throughout the project. These rights and responsibilities will provide the foundation for how they will collaborate together.
  • Propose how they will work with the customer organization.
  • Produce potentially shippable software to the customer every X weeks (for me, X is usually 4 or less).
  • Allow the customer to monitor their work and work products. Depending on the situation, the customer may insist on having one or more of their people on the supplier's site throughout the project. The customer should insist on access to the source code at all points in time so that they can inspect it at their leisure, including but not limited to running it through a static code analysis tool. They should also insist on access to a project management dashboard whose metrics are populated automatically, in (near) real time by the tools the supplier's development team is using.
  • Follow the customer's corporate development guidelines which they will provide to the supplier. The customer will be monitoring their compliance to these guidelines throughout the project.
  • Do full regression testing throughout the lifecycle. The customer should favor any bid which indicates that the supplier will take a test-driven development (TDD) approach.
  • Provide a minimal set of deliverable documentation, particularly user documentation, operations documentation, support documentation, and high-level systems overview documentation. The customer should provide examples of such documentation if they're available.
  • Accept a realistic payment strategy that is based on a low time and materials (T&M) rate for the supplier with bonuses for continued delivery of high-quality, potentially shippable software. This is a shared-risk strategy which is fair to both customer and supplier. Pure T&M puts most of the risk on the customer and fixed price puts most of the risk on the supplier, both extremes which in practice increase overall project risk.
  • Indicate rough estimates and schedules, in the +/- 30% range, to give the customer a good feel for the overall financial risk. Anything less than a 30% range would be phenomenally nave for the customer to request due to the realities of software development (once again, regardless of the wishful thinking of the generic project management crowd).

This strategy suffers from a few potential challenges, all of which are fairly straightforward to overcome. First, because suppliers generally don't keep people sitting on the bench waiting for a customer to come along, it can be hard for them to say exactly who will be on a given project ahead of time, particularly if the customer's decision making progress is slow. The implication is that the customer must have reasonable expectations regarding staffing, but must still be wary of bait-and-switch tactics where the supplier promises senior people but delivers juniors. Second, it requires the customer to be accountable for the decisions that they make and to be actively involved with the governance of the project. A "hands-off" strategy to outsourcing with relies on contracts and reviews of documentation is little more than gambling on the part of the customer in my experience. For outsourcing to work customers must take a hands-on approach where they actively monitor and steer the project. Third, it requires suppliers to be disciplined enough to work in an agile manner, producing high-quality code and supporting artifacts throughout the project. Having consulted to several major services providers with respect to disciplined agile development, I can safely say that many of them are very eager to work this way if only they were allowed to do so by their customers.

So why hasn't this sort of strategy been adopted in the past? Interestingly, when you talk with procurement people you quickly discover that they are very intelligent people who know full well that their processes are broken. Unfortunately, they often feel disempowered to change the RFP process, either because they haven't pushed back against their management or because they believe that the suppliers that they're working with don't want to work in an agile manner. I suspect that if customers and suppliers were to choose to have open and honest conversations around improving the procurement process, and to start working in a collaborative manner based on trust, that together they could find a much better, mutually beneficial way of working together. But it requires someone to make the first move.

Survey: State of the IT Union

We invite you to fill the June/July 2009 edition of Scott Ambler's State of the IT Union" Survey . The goal of this ongoing survey series is to find out what IT professionals are actually doing in practice. There are 15 questions on 4 pages in this survey, it should take you less than 5 minutes to complete, and your privacy will be completely protected.

At the end of the survey you will be given the chance to be entered into a draw for one of five copies of "The Economics of Iterative Software Development" by Walker Royce, Kurt Bittner, and Mike Perrow, published by Addison-Wesley in April 2009.

The results of this survey will be summarized in a forthcoming Information Week newsletter by Scott Ambler. Furthermore, this is an open survey, so the source data (without identifying information to protect your privacy), a summary slide deck, and the original source questions will be posted at www.ambysoft.com/surveys/ so that others may analyze the data for their own purposes. Data from previous surveys have been used by university students and professors for their research papers, and hopefully the same will be true of the data from this survey. The results from several other surveys are already posted there, so please feel free to take advantage of this resource.

Hot Links

The March 2009 Dr. Dobb's Agile Update discusses the Manifesto for Software Craftsmanship.

The July 2008 Dr. Dobb's Agile Update describes five strategies for reducing the inherent risks associated with fixed price projects. If you can't avoid fixed price then at least be smart about how you go about them.

The August 2008 Dr. Dobb's Agile Update asks the questions "Is Fixed-Price Software Development Unethical"?

The March 2003 "Something's Gotta Give" argues against a fixed price, fixed schedule, and fixed scope approach and describes agile strategies for avoiding this serious mistake.

The September 2007 "Agile on a Fixed Budget", describes strategies for running agile projects for all combinations of fixing, or not fixing, the schedule, scope, and budget.

The November 2007 "Governing Agile Software Development Projects" shows how it is easier to govern agile projects compared to traditional projects.

A suggestion for the rights and responsibilities which you may wish to define in an agile RFP can be found here.

For an actual example of a project dashboard where the metrics are generated automatically from the integrated tooling used by the development team, visit www.jazz.net where you can find out what Erich Gamma's development team is currently up to.

The IBM Whitepaper Lean Development Governance by myself and Per Kroll overviews a collection of practice for effective governance of development projects.

My [email protected] blog discusses strategies for adopting and applying agile strategies in the complex environments.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.