One of my most memorable music videos from the 80s is Peter Gabriel’s “Big Time” recorded in 1986.
The song tells the story of a person who has had enough of a small town where people think small and use small words. So, he leaves to make his way to the big, big city to make it big. A place where he can stretch his mouth to let big words come right out.
For me, the song is a metaphor for organizations that are stuck on a big batch, big bang mindset. Not seeing the worth of incremental small batches delivered in small ways iteratively over and over again over small durations of time.
Multi-year projects that push nothing into production, preferring to wait until the very end of the project.
Stakeholders see nothing until then expecting to see it all during the big reveal in the end.
The management thinking being:
“What value would there be in showing small, half-baked incremental pieces when what they really want to see is the final big masterpiece?”
In the meantime, the project work proceeds on scope, on time and on cost. The project deliverables stealthily complete and accumulate over the years into a single big batch.
Finally, on the project plan’s committed ‘Go-live’ launch date, the big batch of deliverables is released all at once in a single big bang deployment.
That’s the way I felt recently during a senior leadership program planning review session. We were nine months into a three-year project and reviewing a set of draft program increment objectives targeted at the next three months.
The draft objectives were in a word, nondescript at best and horrible at worst. Most of the half dozen objectives started with:
- “Continue doing <stuff>” or
- “Investigate <stuff>” or
- “Design <stuff>”
They were boring, ho-hum, and lacking any SMARTs.
So, I couldn’t resist the opportunity to challenge the objectives. I asked,
“Those objectives aren’t very SMART. How might we make them more interesting and inspiring so that people will take notice?”
An uneasy silence filled the room. It felt like I blurted out what most people were thinking and now, were waiting with bated breath to hear the answer themselves. Finally, the Lead Product Manager spoke up:
“The objectives are just a high-level draft right now. We’re waiting for each individual product manager to share their detailed plans before we update with more specifics.”
I thought about this answer.
The first thing it conjured in my mind was a picture of the proverbial “Cart before the horse”. Instead of the horse (Lead Product Manager) pulling and leading the cart (Product Managers), the cart was expected to pull and lead the horse?!
The second thing it brought to mind was JFK’s 1961 goal of “landing a man on the moon and returning him safely to the earth” before the end of that decade.
He didn’t know the details of how he was going to do it. But he knew why it was important for the nation to achieve it.
It’s debatable how SMART his goal was, but it clearly inspired and moved a nation.
In this case, the horse was clearly before the cart.
Not satisfied with the Lead Product Manager’s answer, I hazarded another challenge. The program was about to deploy its first external release at the end of year one.
So, I asked,
“Frequent releases are a hallmark of Agile ways of working.
How many more external releases will we be deploying before the program launch at the end of year three?”
This time, there was no silent pause. This time, the answer came in unison from almost everyone:
“None. Next external release will be when we officially launch at the end of year three”
I was dumbfounded.
I said “Really?! Why not?”
This was followed with a barrage of reasons why not.
- “The final release is the only release that matters”
- “External releases are expensive”
- “I fail to see how more releases would help my bottom line; what return would that give us”
- “We don’t have time for more releases; we have to spend time now to complete the whole design first to have any hope of launching at the end of year three”
- “Well, I can release an ‘arm’ or a ‘leg’ but what would anyone do with that?”
The responses told me there was much work to do. Especially when it came to letting go of the classical software development lifecycle / ways of working and embracing a more modern software development lifecycle / ways of working.
I had so many more questions and saw so many coaching opportunities.
With tongue-in-cheek, I started in the moment by challenging reason #5.
“Instead of releasing an arm or a leg, what if we were to release a baby, then a toddler followed by a teenager?”
The good news is that some in the room were getting it. Starting with more frequent, small, and growing releases. Maybe not to the extreme of companies like Amazon who deploy to production ~125,000 times a day!
I’d be happy if we just start with releasing more than twice in 3 years!
Next Chapter Consulting 