Just as I thought I've mastered truly agile approach to product management, I noticed myself slipping back to old bad practices: not delivering user value that can be validated by the end user at the end of the sprint.
My scrum team has recently delivered a large epic over several sprints. While I helped the team to break down the original large story (epic) into smaller stories that could fit into each sprint, I could not convince myself to demonstrate what the team has developed at the end of the first sprints to our customers. I doubted our team's work, while instrumental in laying the foundation for the ultimately delivered value, would generate enough interest or even appreciation among our end users.
On one hand, the ground work delivered at the early stages is just too low level (think of plumbing) for many end users, often lacking visible end user facing benefits. On the other hand, I was wondering if prematurely exposing incomplete value package would expose flaws in existing products customers may be unaware of and cause them to doubt what they have instead of appreciate what's coming.
I also noticed I am not alone facing the pressure to concel my yteam's progress, and skip the end of sprint demo. Other Product Owners sometimes tend to avoid showing incomplete features, hoping instead to delight customers and get rave reviews for well thought out, polished features shown to customers at the end of several sprints worth of effort.
Doesn't this push us back to the old dark age of waterfall?
What do you do to avoid falling into the same trap?
My scrum team has recently delivered a large epic over several sprints. While I helped the team to break down the original large story (epic) into smaller stories that could fit into each sprint, I could not convince myself to demonstrate what the team has developed at the end of the first sprints to our customers. I doubted our team's work, while instrumental in laying the foundation for the ultimately delivered value, would generate enough interest or even appreciation among our end users.
On one hand, the ground work delivered at the early stages is just too low level (think of plumbing) for many end users, often lacking visible end user facing benefits. On the other hand, I was wondering if prematurely exposing incomplete value package would expose flaws in existing products customers may be unaware of and cause them to doubt what they have instead of appreciate what's coming.
I also noticed I am not alone facing the pressure to concel my yteam's progress, and skip the end of sprint demo. Other Product Owners sometimes tend to avoid showing incomplete features, hoping instead to delight customers and get rave reviews for well thought out, polished features shown to customers at the end of several sprints worth of effort.
Doesn't this push us back to the old dark age of waterfall?
What do you do to avoid falling into the same trap?
I think that "we should have added more features" situation is often a symptom of the PM not actually solving any customer problem with what was built. It sounds like the big question here is whether the story/epic was worth doing in the first place. I think that the true litmus test of this is not whether you would want to demo it, but whether you can measure it's impact in at least a semi-scientific way. Whether that is with qualitative user discussions or hard-numbers from analytics, I think there has to be some way to know whether the feature is driving the desired results. With that goal and process in mind, the PM prioritization process would also be affected in a big way, I have seen this quite vividly in my current startup.
ReplyDeleteHey Oleg,
ReplyDeleteI have faced the same situation on my previous project. I have refrained from demoing at the end of a couple Sprints because the Epic was what I considered still too early in development to generate any customer interest.
Considering how participating in our Agile process is demanding for our customers, and there is such a thing as customer fatigue, I prefer skipping a couple EOS demos than boring my customers.
There's one thing about Agile that's not written in the Manifesto, but that's how I interpret it anyhow. Agile is the exact opposite of a process set in stone. It's all about being flexible and adapting. The moment you feel imprisoned by some written or unwritten rules is the moment you forgot what Agile was all about.
So I actually believe that bending the usual rules once in a while is actually a big part of what Agile is supposed to be.
=> I think on occasion, not demoing an unfinished feature to customers is entirely acceptable, and I would probably not hesitate to do it again.
That being said, since there are usually several features being worked on in parrallel, there are usually still a few other ones that you can show, I think that keeping a regular cadence for meeting with your customers is important, since if they don't see your EOS demo invites every N weeks, they might start wondering what's going on. Or you may occasionnally cancel the EOS demo and notify them in advance, explaining why I guess?