We can chose which 3rd parties we work with, however we can’t often choose how they work.
This can lead to friction between our ways of working & theirs. We need alignment between all parties to facilitate a smooth delivery of value for our customers.
This situation occured at a previous customer of mine. We were striving for agility with iterative delivery, whilst our 3rd party was opting for a more traditional, staged delivery.
This post shares some concepts we used to tackle the differential of traditional delivery flowing into iterative cycles.
The Challenge
The organisation is moving towards agility, intent on iterative delivery.
One of the teams gained enough traction to warrant spinning up a full, cross-discipline team consisting of both development & FS stakeholders.
This team would be working closely with a 3rd party to deliver an FS product.
As you can probably gather, our team was iterative, the 3rd party was working to a more staged delivery cycle (Waterfall).
The big question in the team was how can we remain iterative when our 3rd party isn’t?
What’s in a Value Stream Anyway?
Although the 3rd party was working with a staged delivery cycle, they were doing it well. We had a clear understanding of what could be delivered when, with the priority order being agreed between the 2 parties.
Their software deliverables only made up part of the value stream.
It’s important to reiterate that value streams contain more than the flow of software (materials) - they also contain the flow of information.
Yes, the 3rd party was delivering software in large chunks, but the information between the 2 teams was frequent & regular.
This rapid sharing of information still enabled questions to be quickly answered & mis-assumptions corrected in a timely manner.
With seemingly conflicting delivery cycles, we could still benefit from short feedback cycles of information.
For example, we could challenge ideas, correct requirements & manage expectations before the code gets written.
Rocks in the River
Whilst working with a previous customer helping their large enterprise adopt Agile at scale, I was introduced to the concept of “rocks in the river“.
The idea being that rivers contain large rocks that don’t move - water has to flow around them.
The 3rd party software deliverables were our “rocks in the river”. We knew where they were, so we could plan how to flow around them (otherwise we’d hit those rocks head on, which isn’t a good place to be).
Rocks in the Jar
There’s also the time management story of the professor asking if a jar is full of rocks or not. The professor then adds gradually smaller rocks, stones & sand to show how the jar was not actually full of rocks.
The metaphor highlights the different size tasks we need to accomplish, with the rocks, stones & sand being the tasks & the jar being our capacity to complete those tasks.
As with the “rocks” from the 3rd party, the rocks in the jar do take up a lot of our time, but there are other smaller tasks that can be accomplished in shorter timeframes.
In fact, some of these smaller tasks would need to be completed before we could actully take delivery of the software from the 3rd party!
Summary
To round it up then, value streams contain material & information flows. Both of which come in different shapes & sizes (think different sizes & types of rock)
Even if the 3rd party material flows are staged (& therefore probably larger), your team can still break down their own work into smaller work items & work iteratively to deliver them.
You can then plan your work around the large deliverable from the 3rd party.
Information is often easier to deliver in small chunks. I’ve found that people are often keen for more frequent but shorter meetings after they experience the benefits of fast feedback loops.
Over time, you & your 3rd party will likely discover ways in which the staged deliveries can be broken down so that they become more frequent.
You’ll be surprised at how work decomposition improves with trust & rapport!
Have you had to work with a 3rd party delivering value to a different cadence than yourself? How did it go? How did you go about tackling the challenge? I’d love to hear it!
Thanks for stopping by,
Duncs