In this issue:
Dan, a product owner felt as if he was stuck between the proverbial rock and the hard place. His managers wanted “everything” in the next release.He knew the team couldn’t possibly deliver all of it. He hoped to get most of the features.
He met with Polly, the agile project manager, and asked how much she thought the team could deliver. She suspected fewer than half the features Dan wanted.
He asked, “What can we possibly do? My managers think we need all of it and now.”
Polly smiled, and said, “Let’s see if we can’t get them to change their thinking from how-much to how-little.”
Tip 1: Talk about feature sets, not epics or themes.
When we use words such as “epic” or “theme,” our managers might not realize how large or complex the work is. I like to use the term “feature set,” not epic or theme. When we use the word “set,” people realize there is more than one piece of work in the set.
You might think that changing words doesn’t make much difference. When Dan changed his words from “epic” to “feature set,” his manager asked, “How many stories do you think there are in this epic?”
Dan said, “At least 40, from the way you described it to me.” He paused. “And all of it will take several months.”
“That’s a lot more than I expected. Is there something that’s half of that or less, that would be valuable?”
Dan and Polly knew that the team needed to learn something specific: how to hook new payments processing into the old financial system.
Tip 2: What’s the first thing we want to learn?
Teams might need to learn something specific to reduce risks. Polly said, “We also need to learn how to keep some parts of the transaction transparent to the customer.”
They discussed why some part of the transaction needed to be transparent and others didn’t. The manager surprised both Dan and Polly when he said he thought the entire transaction should be transparent.
Dan said, “Well, okay. Then we have to explain what we’re doing, so we don’t freak people out.”
They all chuckled at that.
Teams learn at various points in the project, not just at the beginning.
Tip 3: What’s the first thing we can deliver?
We might want to deliver something to cement a customer relationship. Or, as some sort of interim value to attract new customers.
Polly said, “I want us to roll out the various reports separately. We can do this first one,” she pointed to one of them, “and then sequence them. We don’t need all of them when we release the first.”
The manager frowned, and asked why not.
Dan said, “This first report will allow us to see what happens inside the product. And, it shows our customers where we’re headed. We give them that one, and we’ve solved most of the problems with reports. That eases the pressure on us.
I hope you find these ideas useful: using the words feature set, thinking about the first thing to learn or deliver, as you move from “how much” to “how little” thinking. That will help you use rolling wave planning, and deliver more frequently. Let me know if you try this and how it works for you.
If the agile promise seems elusive in your organization, please join Gil Broza and me at the Influential Agile Leader workshop. You still have time to join us April 24-25, 2019 in Toronto. I hope to see you there. (Have questions? Email me.)
My new book (with Mark Kilby), From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver is done! If you have a distributed or dispersed team, do yourself a favor and read it.
Are you new to the Pragmatic Manager newsletter? See previous issues.
Here are links you might find useful:
- My Books
- Online Workshops
- Managing Product Development Blog
- Create an Adaptable Life
- Johanna's Fiction
Till next time,
© 2019 Johanna Rothman
Tags: agile, product owner, replan, rolling wave planning, transition to agile