It is already a while ago since I left the best project I have ever worked on. Retrospectively looking back there were a lot of good things we did. One of the factors for success was definitely the company culture that enabled everything we did. But the team itself with an external Agile coach came up with so many things and approaches too.
I wanted to know more about why the project was so much fun and in the end successful. So I wrote a mail to the Project Manager respectively Product Owner of my old team.
His answer did not really surprise me but also was not what I had expected. Honesty!
It was all about honesty and transparency.
How was the project initially set up?
The project was a time & materials project with a fixed budget and somewhat of a belief that there was a fixed scope. There’s usually a statement of work that contains the user stories that will be delivered, some ‘conditions of satisfaction’ and then some made up calculation of estimates and velocity to give a prediction of timelines and cost.
What was the problem?
When the project started we had a roadmap of stories to do but after a few iterations we realised that we can not meet the goal. There were two ways to handle this situation. Firstly we could have continued without saying anything to the client and scrumble around with deadlines etc. Secondly, and that was the way we dealt with it, we told the client about the situation we were in. We told them that the estimates do not work out as planned. The client was absolutely surprised. They did not expect us to tell them that we are in trouble.
What were the next steps?
The next steps were to discuss a possible solution. Having agreed to time and material we switched to time and money and the client took the ownership about the stories to be delivered. What is the best solution to get with the given time and given money.
Why did it work?
The project went well because after sprints 1, 2 & 3 we knew we weren’t delivering to the story point predictions and told the client. The client found this unusual (many vendors will hide it until the end and try and scramble) and welcomed us putting levers in their hand to control what happens. They decided that their budget was fixed so the only real lever was to be create and reduce scope. We just gave them enough transparency that these levers were meaningful.
A lot of people saw the statement of work as a fixed scope, time & budget contract, but it wasn’t. It’s comforting for customers to believe it is though. Fixing everything upfront, also requires fixing of requirements, so you would need long and detailed requirements spec and you’d also need to build a lot of contingency into your budget and time (50-100% extra).
12. September 2013