The Living Room Architect

A couple of our longer term projects are coming to the end of a release and I'm finding it interesting to observe the people working on them. Each person is subconsciously deciding for themselves if their project is a success. Even outsiders have formed an opinion of the success or failure of the two projects and there's a real emphasis on delivery. What does it mean for a project to be delivered and have these projects done so?

Both of these projects started out with fixed time and fixed scope because the people commissioning them don't understand how Agile projects work. If you were to take a look at that original brief and think about it in a waterfall way we'd be saying that both of them have failed. They have both delivered less scope in a time that is longer than anticipated. However, there's that word again... delivered. In actual fact these project have both delivered a product that is extremely valuable to the company.

Where they succeeded was in winning the argument that the fixed scope and fixed time were impossible to deliver from the start. They then made the recommendation that an Agile approach should be adopted in order to deliver the most valuable features first. They were also able to get into a position quickly where they had a potentially shippable product and could go on adding new features until a decision was made to release the product.

What surprises me is that one of these projects is considered a complete success and the other is considered a bit of a failure. In actual fact the project that is viewed as a bit of a failure has, delivered more value to the organisation than the one that is seen to have succeeded.

This brings me to the conclusion that it doesn't matter how many tools or processes we put in place to measure a projects success. If there are normal people like you and I involved, a projects success or failure, at least in my department, is largely down to how we manage expectations.

The project that is accepted as being more of a success did a really good job of managing expectations and the release plan, in order to make sure that they could deliver what they had committed to. The other, even though it has delivered more value, got there by promising too much and mid-way through the project having to call crisis meetings in order to reduce the scope of remaining releases.

Part of their success was the fact that these teams could write good story cards, estimate them quickly relative to other story cards and had a good grasp of what their velocity was. However, none of that makes any difference if you don't use it to manage the expectations of the customer.