Today, I spent the afternoon with a client from a large state agency here in Denver. We were onsite for a project kickoff meeting. At the meeting, we discussed several pertinent issues about the project, including our use of agile practices to manage the project. The client and our new employer are very open to our use of agile practices. However, the question arose about how to handle changing requirements over the course of the project. Now, I should state up front that this is a fixed-price contract. Essentially, we all agreed that for most changes, we would work within the bounds of Scrum and use a prioritized backlog to move items in and out of scope. However, for large scale changes to the requirements, we would probably need to use more formal channels like change orders. We discussed this for a bit, and everyone felt comfortable with this decision in the end.

However, on the drive home to Ft. Collins, Dave Bouwman and I had a discussion about change management in the hybrid world of fixed-price agile contracting. The main point was about contract negotiation over the lifespan of an agile project. Now, I know…one of the tenets of the Agile Manifesto is that we value client communication over contract negotiation.  While this may be true, there is also an element of reality that requires us as consulting-ware developers to have to deal with contract negotiations in the fixed-price world.

In the consulting world, we are frequently bound by contracts that, at some level, define the requirements we need to deliver.  As we proceed through a project using agile practices, we frequently rearrange the priorities of these requirements (or user stories).  In addition to rearranging the priority of user stories, we often find it necessary during a project’s lifespan to remove some stories from the backlog and add others.  Whether we like it or not…whether we consider it agile or something else, these changes to the product/project backlog may require change orders. Most of the time, this is not really ideal for either the consultant or the client. We’d rather just embrace the change, and move on to continue developing valuable software.

However, at most government agencies and even some private companies, there is a contracting officer, whose job it is to check the “boxes” to confirm that you delivered functionality X, Y, and Z at the end of the project. If we make a noticeable change to the requirements (especially removing one), we may need to change those “boxes” so we don’t get dinged for non-performance. Not quite agile…but a very realistic and common scenario.

So, back to the manifesto…client communication over contract negotiation, right? Well, I’m not sure that these two need to be mutually exclusive (and I don’t believe that the manifesto implies this either). I believe that they are both very relevant in the consulting-ware world. I think that if you establish an open, collaborative relationship with your client that thrives on honest communication, then contract negotiation (especially change management) can be relatively painless. If your client truly understands the agile process and feels well informed and confident about scope changes, they can become a champion for these changes with their contracting agent. They will be able to communicate in clear terms why the changes need to be affected and how these changes provide increased value and quality to their end-product. This could create an easier path to official change orders for you and your client.

I also believe that over time, your client may come to really appreciate the success of agile practices and possibly “sell” their contracting office on the virtues of fully agile contracts. If you and your team work to consistently deliver value and quality using agile practices, maybe you can start to help organizations change the way the way they view software development contracts in the future. Nothing sells better than success!