As a software team lead one of the common things I’m asked is “how is everything going?”, “will project x be ready by date y?” and it’s something I’ve always struggled with. Everyone who has worked in software delivery will understand that it is difficult to estimate this type of work. It is especially true though of teams working in a new area, where there is no prior experience of the task. This is often where my current team sits.
Over my career, this question has manifested in a number of different ways. In the time before Agile was widely adopted it was the project manager who thought that asking more often would increase the chance of a different answer. Currently, at Sky Betting & Gaming this question is turned around and instead of being pestered for an answer I report a status of Red, Amber or Green for the work the team is doing and include a short summary of completed work and next steps. This is absolutely an improvement but still felt very wrong to me. At the start of a piece of work, it’s easy to go along with the new energy and report Green, when it might be better to report Amber or Red since there are potentially a lot of unknown risks.
Recently with the help of Sean from Optimise Agility we’ve been working through some of the pain points at SB&G and I spoke to him about this interface between the leadership team and their need for assurance that the work was in hand and the delivery team and their need to do the work.
The traffic light strategy didn’t contain the information we wanted to give. I wanted to show that our iterative delivery approach didn’t match up with the Gantt chart style product roadmaps.
We decided to try an experiment with the delivery team, asking them a simple question of “Based on a release at the end of May, what confidence do you have that the following will be in production ready to be used.” Giving ten options ranging from “0 – No Chance”, to “10 – Dead Cert!”
This gave us a quick, data-driven and cohesive expression of the remaining work. This felt right, but having this wasn’t enough; we needed to show other people that we were thinking about this and tell them. This became another quick experiment with this data being show at the edge of our team space on some spare wall.