from zero to production in eighty days

When I mean zero, I literally mean zero. A brand new project, a PO that’s new to IT, no existing processes in place and a small team of four including myself and the PO.

The departmental organisation we were working for doesn’t have any developers, scrum masters, product owners working for them. Everything they did was either done by another department or outsourced completely.

This is a story how we went from zero to production in eighty days.

Bolt winning at the 2008 Olympics (source: WikiCommons)

The business was new to all this software stuff, they wanted everything and rightly so. This is human nature, we want everything and we want it now. If the team could’ve given them everything within the time frame we had, we probably would’ve, but we couldn’t. It became clear earlier on that the business had to do some brutal de-scoping with the backlog. This wasn’t fun, it never is. To say you want to delay getting a feature until a yet-to-be determined date is hard. Not only from a software perspective but generally as well.

Outside of software delivery we do this quite regularly, we don’t buy the Porsche we end up buying the Toyota (Toyota’s are great cars BTW I’ve never owned anything else), because our priority is buying an apartment to live in. Here we were lucky, the business learnt to prioritise earlier on. It was a bitter-sweet experience for the business, as it meant they didn’t get what they wanted, but taught them how to order priority early. In the long run though this helped the delivery team greatly because as the project further progressed the PO was able to make decisions about priority promptly and urgently for other things.

The team included members who were quite experienced with software, so we attempted to help the business prioritise, this included the suggestion of federation with IDPs as not being important. This however, proved to be false, the business really want SSO federation as the majority of their users would be using this feature. Here, IT learnt that we can make suggestions about prioritisation based on past experience but in the end it is the business that knows their market best not us. So it’s important to trust and empower them. Yes, make suggestions as clear as possible, but also trust the business because that’s the only way to empower them to order priority properly.

One of the things that helped the business is having the team on-site. Luckily the team was quite experienced with agile, so we were able to be a good example to them. This in adition too using retros as a vehicle to teaching agile was a great way to help the business understand how software is delivered.

Further on in the project, one of the comments that the PO had told me was “Agile isn’t for perfectionists”, when I heard this I was very happy. Agile isn’t about perfection, it’s about delivering an increment on the software product with the most desirable features first. It was at this point in the project, that I came to realise that the PO is understanding agile delivery a bit more thoughroughly.

Another area of learning was the different moving parts in IT. The business learnt this simply by hearing us in stand-up; bringing external accessibility and security consultants on-site and highlighting impediements from third parties daily. The complexity and web of dependency in any enterprise IT system was able to been seen by the business first hand, whereas previously it had all been abstracted away.

This engagement wasn’t a big. However I had a good time by seeing business grow, being lucky with working with a very good developer from my employer Readify, learnt many things myself in areas of leadership and communication.

The hard work by the team enabled us to go from zero to production in less than eighty days was a very rewarding experience for me and I hope for other who were involved.