Skip to main content

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.


Popular posts from this blog

My first time speaking at a conference

Since time immemorial we humans have valued the art of public speaking. Today, I want to share with you my experiences in speaking at conferences for the first time. Recently, I spoke at both DDD Melbourne and DDD Perth. Both of which were positive experiences that I learnt a lot in.

Have You Ever Produced Negative Value in a System!?

As developers we encourage our product owners to order the priority of their backlog in order of value. However, every time a new feature is implemented by a development team, there is a certain degree of risk associated with the introduction of that new code. Namely, risk of breaking another part of the product and maintenance cost. When a development team pulls in a new feature to implement there is a certain acceptance of this risk. In many cases, the risks that arise due to additional code complexity doesn't justify the value added by the new feature itself, so the development team can start implementing it.

Are there scenarios where the value added to a software product can be negative though?