Agile development is all about collaboration. The writers of the Agile Manifesto value customer collaboration over contract negotiation. There was definitely a sense that we had gone off the rails - that software development had become too much about contracts and too little about common-sense, face-to-face negotiations.
But if you think about contracts, they’re really just a tool to reinforce trust. I think of the Scrum process as a series of micro-contracts. In exchange for a promise to deliver a working piece of software in two weeks, a team is given great latitude to work the way they want to work. Each time a team delivers on their sprint goal, they reinforce the trust that the business has placed in them. A track record of 25 successful sprints over a year or so goes a long way to showing that a team can be trusted.
Step up a level to the product owner, though. In a larger enterprise, many product owners are prioritizing backlogs for many teams. A product owner working with two scrum teams is responsible for a $2M annual investment. That’s significant. What’s the right way for a business to protect itself from the risk?
An agile portfolio contract is a lightweight thing. It’s less than a hundred words long. It defines an initiative that is meant to take 3-6 months to complete, with one or a couple of teams. It includes a hypothesis about value (“if users can get instant credit decisioning more small business loans applications will complete”) a list of 3-5 measurable success criteria (“completion rate is doubled among users who get to step 4 of the loan”) and a list of assumptions to be validated (“we can get responses from the decisioning engine in less than 2 seconds on average”). It includes a cost (1 team for 3 months).
What it doesn’t include is a detailed, locked-in feature list. The PO needs to retain discretion on the features in order to be able to negotiate scope to meet the planned end date.
There are 2 ways a PO can come out as a winner in this contract:
- Deliver the succcess criteria before the planned end date
- Raise risks within the first month and renegotiate the contract
On the other hand, a PO who plans badly, defers risky work until late in the initiative, and doesn’t let stakeholders know until a month before the end (or worse, after the end), weakens the trust the organization has put in them.
In your organization, do your POs have specific, measurable goals they’re trying to achieve? Or have you just given them a blank check? It seems like the blank check approach is more agile, but in a large organization, it’s impossible to ensure that all of your POs are making good calls all of the time. You need a basic framework to negotiate with them, and to build up that trust. PO fails to deliver on a 6-month initiative? Maybe next time they get 2 months to build their credibility back up.
At Rally, one of our core values is cultivating trust and respect. Trust is something that is continually built and rebuilt. Is your portfolio helping your POs to build trust, or are you setting them up to be less and less trustworthy?