In June 2010 I took over a project with a reasonable amount of trepidation. There were a couple of reasons for my reservations. Not the least of which was my search for what I wanted to be doing and taking this on would be a commitment that I wasn’t sure I wanted to make. I made the commitment and over a year later I’m incredibly happy with what we have achieved.
When I took over the project several other project managers with far more experience had not succeeded in making a real success of the project. Technically it wasn’t beautiful. After having taken on a large client performance issues had arisen which had taken several months to fully bed down. I was taking it over at the tail end of this. And there were other issues that had led to the client being at a low point in the trust of the team. Though they had great faith in certain individuals but that was part of the problem.
The first thing we started doing was introducing Scrum. This exposed a couple of problems:
- The team “knew how to do it all” already. (They didn’t)
- Some individuals couldn’t break anything down beyond 3 days – and objected to questions around this.
- It was almost impossible to lock down scope for a week – let alone 2 weeks so sprints were difficult. There was a lot of smoke but few real fires to put out.
- It wasn’t clear what exactly needed doing to deliver a quality release.
- We couldn’t deliver a quality release due to lingering quality issues from an earlier period.
- We had no PO.
- The client had experienced working with me on another Scrum project and initially assumed that it was me that was important – not the process. They were impatient for success.
Our first big release after the performance issues were fixed was a disaster. 1 month of work to “finish” the last parts of a module generated 2 months of work to get it really done. This was largely due to those who in theory knew what needed to be done didn’t actually know what needed to be done – both in the team and at the client.
Jump forward 6 months. Some things changed. Some people changed. I took on the role of SM and PO in order to force the backlog generation and to get a handle on the chaos. We made a quality release. The team was much more enthusiastic and fired up. And for the rest of the year we’ve gone from strength to strength.
How was this possible?
a. My management supported me. I beat the PO drum over and over and over again. We needed one. I would do it in order to achieve a manageable backlog, but we needed one from the client. In February – after this first quality release – we had our PO and this has taken us from strength to strength and proven the value of having a known backlog to groom and work on.
b. We focused on what we knew we had to do and made sure the client knew what we had to do. We embraced change, but made sure that the client understood change wasn’t free, dates or other scope could be affected. We were completely transparent with this.
c. The new team became a real team and the team started to deliver greater than the sum of the individuals.
d. We removed the ambiguity. Initially this was by going a bit more big design up front in order to force the client to stop randomly changing direction and blaming the lack of delivery on the team. This is something we’re now looking at changing in order to remove some of the waste around this.
e. The team had quality issues that they worked hard at resolving – through bug analysis and retrospecting every time there was a problem.
Moving forward we started unit testing properly. We haven’t conquered everything in the system to be unit testable, but we’ve made a good start and keep on opening up new things to try or fix. But the team is positive. They have tackled quality in deployments and come up with solutions to ensure we don’t miss things. They have been proactive and keen to get better. The team takes pride in solving the issues that are raised up in retrospectives.
We have been able to move to 2 week sprints. We have been able to manage support in an effective way and reduce it to a minimum as much as possible. We have a full time PO and we can plan reliable deliverables with known scope given enough detail and time. We have become solidly predictable with high quality.
Fast forward to last week. I’ve just come out of a client visit. They are keen to keep pushing the envelope – to become better, faster, more agile, more productive. They are keen to try more frequent deployments and to force the team to think about how to achieve that. They want the flexibility and the ability to get software live faster safely if needed. They are keen for the problems with deploying more often to rise up so that we can confront them. They trust that we want to do better. And they want to not limit us from getting better. And they know that if we get better we’ll get faster, once we’ve learnt how do to some of these things – like being able to deploy every month. Hence maybe needing a full test suite and investing in that. That trade-off will be interesting to see how it comes to a head.
We’re also looking at making ourselves more effective by embracing change more – not worrying as much about specs and sign off which were all needed to rebuild the trust – but to start being more agile in requirements generation together as a team with the PO. Of course with embracing more ambiguity comes less rigid date based plans but deploying often will help us not need that at all.
This is all quite a step from where we started over a year ago. We now have a client encouraging and supporting the team to look at how better to be agile – to solve some of their real world problems that they are seeing. They trust that we can achieve more than we’ve already achieved.
There are interesting times ahead for this team. It is a pity I won’t be around to see this next year. But I’ll be watching from the side-lines cheering them on to be more agile and to push the envelope of their capabilities.