Contracts and Vendors – The Agile Impact

As you many have read in my prior post about The Agile Impact regarding “Telework and Modified Schedules”, there are some variations on how moving to being Agile has impacts on the government agencies that are different than those seen in private industry.  In this blog, I will highlight some of the impacts that contracts and vendors have on the Agile transition in government agencies and outline some things to watch out for.

To set the stage, I first want to point out that we are not examining the contracting styles or types, but we are looking at how having most of the team members being outside of the agency, working for a vendor which is based on a contract, changes the landscape of how Agile is seen and implemented.

Before we get too far into the impact to the agencies, let’s set the stage a bit on what an Agile team really is: dedicated!  You can read more about the definition of an Agile team by reading another post: “The Reality of T.E.A.M”.  In short, an Agile team is formed with the intent of being dedicated to the team and to the solution they are delivering.  The team is intended to be created so that they remain a team, even after the release happens.  An Agile team is not created around their specialties, but more by pulling specialties together and having them work together to accomplish a goal.

Now that I’ve set the stage on what an Agile team is, let’s dive into the impact agile has on contracts and vendors…

In many government agencies, the teams that do the work building the solution are typically not government employees, but rather they are employees or contractors of a vendor that has won the contract.  These teams will sometimes be allowed to sit at the agency, but more often I’ve seen that they will be offsite, either at the vendor’s office or at their home.  This style of team poses a few issues when comparing to the definition of what an Agile team is.  Any ideas on what some may be?

When a contract is awarded to a vendor to build a solution, they usually go form a team to complete the contract.  In most cases, the vendor will assemble a team that has the skillset they need to complete the solution.  This team, which probably will not be sitting within the agency, needs to be able to communicate and collaborate with people within the agency on a daily basis.  This poses a number of issues since they are not co-located and most likely not on the same network.  It becomes a challenge for the team to be as effective as they can be; the team needs to work much harder to communicate and collaborate.  When this happens, communication and collaboration have a tendency to fall away and take a back seat to ‘just get it done’.

Also, when a vendor has their own team, which is not affiliated with any particular agency, the team in all likelihood has their own way of doing things and their own ‘set of rules’.  The team’s way of doing things may not align with the way that the agency does things, but they will need to find a way to work together.  If they don’t figure out how to work together, they will never really deliver the value requested.

Another hiccup in the vendor-agency relationship when moving toward Agile is the constant need for the agency to evaluate the team according to the contract.  While the vendor may understand the shift from a ‘contract-based’ relationship to one that is more ‘collaboration-based’ (see value 3 of the Agile Manifesto), they are still responsible for delivering the contract.  This puts the team, based at the vendor, in a bit of an interesting position: do they collaborate and deliver based on the communication/collaboration OR do they follow the letter of the contract and deliver based on that?  I’ve seen a couple instances, not many however, that manage to have both, but it really depends on how the contract is written and how the vendor’s relationship is maintained.

In most instances, the agency’s relationship with the vendor relies heavily on the contract and ensuring the things outlined in the contract are what are delivered.  However, the vendor and the agency can find ways to accomplish both – an Agile transition AND delivering to the contracted agreement.  The biggest thing they both need to keep in mind is that they need to communicate and collaborate in order to ensure both the value and contract are the drivers.

One of the easiest ways to ensure that both the transition and contract are met, is to have a vendor that understands and supports being Agile.  When a vendor is already aligned with the Agile values, it makes things much easier to ensure the communication and collaboration are the basis for the delivery.