Remember that song, "There Was an Old Lady Who Swallowed a Fly?" I remember hearing this song when I was a kid and I looked it up the other day to sing it to my own children. Part of it goes,
She swallowed the cow to catch the goat,
She swallowed the goat to catch the dog,
She swallowed the dog to catch the cat,
She swallowed the cat to catch the bird,
She swallowed the bird to catch the spider;
That wriggled and jiggled and tickled inside her!
She swallowed the spider to catch the fly;
I don't know why she swallowed a fly
(Source: Wikipedia)
While I was looking at these lyrics, seemingly an innocent children's song, I realized this is eerily familiar! The ghost of software past tapped me on the shoulder. I thought, this is real! I've experienced this pattern at past jobs.
I tweaked the lyrics slightly, and I think you'll see what I mean:
They deployed the container to ship the build,
They shipped the build since it was tested,
They tested the build since the code was implemented,
They implemented the code since there was a story,
They finished the story since it was in the sprint,
I don't know why it was in the sprint . . . (or what need it meets)
Software by Ceremony
Let's talk about sprints, stories, and story points. If some software team has these tools and ceremonies, do we know they're going to delight their customers?
The answer is, no! There's no direct line between customer value and story points. I don't care to hear what tools and processes the software team is using. What I want to know is what they achieve by those tools and processes. How happy are their customers? And how happy are they?
We can't know if any software team is successful without knowing what the customer experience is like.
So let me back up to those tweaked lyrics I mentioned above. By the time the code shipped, the customer value was all but lost:
- Stories are in the backlog by request of (or put their directly by) someone outside the team
- The team never followed Alistair Cockburn's edict that "stories are a promise for a conversation"
- The team is a bunch of software people trained to think about how to implement some customer behavior given the existing system, so they immediately get distracted by how they're going to do it
- At no point does someone say, "wait...why are we doing this? what is the true underlying customer need this will meet? What value does it have?"
- Once the team figures out how they're going to do it, they attach story points and pull it in the sprint
- Still no one ever follows up on how it helps the customer--no one has any idea and no one shows any interest in that
The takeaway: have a customer value mindset
"Make sure you build the right it before you build it right"
~ Alberto Savoia
We don't have to make software by ceremony. We don't have to care so much about "doing Agile" (if that's what we're doing) or even "being Agile." We just have to slow down, remember that customer value is our purpose, and think! It's not a process. It's not a tool. It's a philosophy. It's a mindset!
And that's really all there is!
Now that I've said all that, I hope you can get that song out of your head. Try "the song that never ends" if you need a different ear worm . . . devilish grin
Top comments (2)
Great article. I've spent a great deal of my time advocating for customers in dev teams lately. I may just sing this song to drive the point home next time.
That last sentence was a little too effective. I may never forgive you 😠.
This is the bug that doesn't end
Yes it goes on and on my friend
Some people started patching it
Not knowing what it was
And they'll continue patching it
Forever just because...