Recently I have been approached by a few people that agree with all my previous posts on agile, however, at the same time they question how it can work when it comes to building infrastructure. I get asked this because many will say, “surely at RTGS.global
you're not following agile to build out the underlying infrastructure?”
Now when I say infrastructure, this can mean both physical or virtual, or software. My response to this typically is, “how do you think Microsoft builds Azure?”
There are two main drivers for this lack of faith in agile:
- How can you follow agile when you need to be able to bring together various moving parts at the same time?
- You need to know exactly what is available on what day
Both points come down to what I call “predictability”, which I have covered off a few times in previous agile series blogs. Now in agile, you should value delivery over predictability, that’s your primary focus. But how do you reconcile the need for fixed
dates with true agile?
When you can predict
The issue of predictability is largely down to “when” you try to predict something. Now I always value delivery over the ability to predict the future, and because of that, there is a stage when you become comfortable at predicting something. A trade secret,
that’s pretty much because essentially you have delivered already – your unknowns are all known.
Now, if you have several moving parts, the best option is to focus on the delivery of each moving part. Sure, if it makes you feel more informed/comfortable, have a good old-fashioned timeline to frame things, but don’t for one moment believe its correct,
nor track your trending to that timeline. Use it as a mere guide at this point. At this stage, I call this a “barn door prediction”.
As your unknowns become known, as you start to see incremental delivery, incremental completion points, you start to see you are moving closer and closer to ultimate delivery. This means you can start to make more accurate predictions. Your barn door is
shrinking. Then, once all your unknowns are known, your ability to predict is pretty much spot on. This is possible because you value delivery above predictability.
Let me provide you with a real-world example, and this is a physical infrastructure example. When building ClearBank we had to have physical telecommunications in place for communication with the payment systems. Now we drew up a detailed timeline of all
the moving parts and the impact on when we could carry out real-world testing. Sadly, we were not as focussed on delivery in some respects as we were in others. The result was that our so-called accurate plan was overnight some 9 months out! Yes 9 months out,
totally down to third party suppliers of physical infrastructure. That’s my point, our prediction was so far out because it was made with so many variable unknowns. Ultimately, these unknowns became knowns, and we were able to work around them, we followed
agile, focussed on delivery and gradually timelines came into focus and became a lot more accurate.
Lesson learned.
Deliver, then iterate
When we talk infrastructure, I often hear, “we need to know exactly what is in place on a given date.” This is followed by “if we don’t this is a risk…” So, the answer is to have a set specification of the infrastructure or system for a given date. Though
this sounds logical, it is a massive misconception. I say this because what most of us will do is, pick the date first.
What you need to know is what you have, then track what is delivered. This may read oddly, but it’s a subtle mindset. Again, lets provide an example.
Often people will talk of a minimum viable product, or MVP. The concept here is the minimum you could have in production to launch or make that service available. I hate this, not the concept of an MVP rather what it seems to do to people’s mindsets. Immediately,
MVP becomes a set specification which then maps to a set date. With infrastructure, be that software or physical infrastructure that always seems to happen. This is a problem, but it gets compounded because often the executive have in their mind when they
want to launch and when they can start to see revenues BEFORE they know what they are launching… Let’s change that….
A modern roadmap will help here, it shows the points where you are focussed. You can start to define what you need in production, but a modern roadmap doesn’t provide dates, no it provides focus points and priority. So, at best you will see, we are working
on this, we will deliver it and then we work on that…Working in this way you can define your MVP as in what features, functions, components must be in place, delivered and working before you can “launch”. You don’t have a set date as yet, but you’re working
on understanding that. Now, here is the subtle difference, track your delivery of these features. By tracking them you can start to refine your timeline, you can start to get more comfortable at predicting a launch date. As more and more areas of the infrastructure
/ solution become delivered, the more accurate you become.
Typically, I am happy to commit to timelines for launch only once everything that is within that MVP has made its way into a production environment. That doesn’t mean we don’t have further testing, refinement to complete, but it means I am happy with the
pipeline of delivery we have in place. We can now get a set date, shout it to the world and go…The reality is however, even following this method, we never had a set specification of what is there at launch. Why you may ask. Well simply because if your engineering
efforts are focussed on delivery, while you are working on marketing, speaking to the marketplace, final testing etc etc your engineering team has delivered the next focussed area of work into production. So come launch, you may well have more than your MVP,
but does that matter? As I say, track to what is delivered…
Conclusion
Agile can be used for anything that needs to be delivered. Value delivery over predictability, track what’s been delivered, and think of timelines / predictions as something that also needs to be iteratively re-defined and refined. If you think of a timeline
itself as a deliverable, then you are on the right path…