Does Scrum cover Market-to-go strategies
Hi together,
there was a topic raised in one of our meetings. We have some employees who build a customer team, which is exclusively working with customer, presenting features to them or new products. And one of the customer team members raised a concern/problem which sounded something about this:
"I have to present the products to the user/customer, but often I have nothing to present to them, because there is for example a new bug raised and the feature is not done, or whatever. I wonder if there is a go-to-market strategy in scrum. I have a problem with scrum that we don't see date x will product y be released. So I can tell the customer on that date it will be released. In a projectplan I can tell you right away how the production looks like and on what date the customer has something to expect. But know when I am talking with the customer I feel uncomfortable, because everything is so vague. What does Scrum tell about it?"
Nobody had a real answer. Maybe you have a response and maybe also something official from scrum like a doucmentation.
Thx
The Scrum Team is accountable to create a usable done increment at least once a sprint, so that the PO can decide if they wish to release said increment or not.
Evidence based management has four key value areas, one of which being Time-to-Market, which allows the PO to use a number of key value measures to determine when the best time to release could be.
I wonder if there is a go-to-market strategy in scrum. I have a problem with scrum that we don't see date x will product y be released. So I can tell the customer on that date it will be released
In Scrum, something finished and usable will be available for release no later than the end of each Sprint. That gives the customer hard dates to work with, and the opportunity to collaborate with the Product Owner so value will be incrementally maximized.
In a projectplan I can tell you right away how the production looks like and on what date the customer has something to expect.
A project plan allows certainty to be faked in a complex and uncertain world. Scrum, on the other hand, takes an evidence-based approach towards achieving predictability. What historical evidence are you capturing about delivery, so useful and informative forecasts can be made?
often I have nothing to present to them, because there is for example a new bug raised and the feature is not done, or whatever.
How would a project plan change this? How often in waterfall projects are bugs found or issues discovered that requires a date to slip? And how often are those discovered last minute?
This problem doesn't seem to be an issue with Scrum as much as your organization's/team's understanding of the Scrum framework. As @Ian Mitchell and @Scott Anthony Keatinge point out, each Sprint should produce something usable of value. It may not be the whole feature but it should be enough to show stakeholders/users in order to gain feedback that can be used to change direction if needed. Your Customer Team Members should have something that can be shared every time a Sprint ends. If your Developers are struggling to deliver usable value in each Sprint, there is an opportunity to inspect and adapt based on what they can discover as the reason.
As a Scrum Master you have an opportunity to explain the Customer Team how iterative development and delivery works. You don't want for the feature to be done, you act upon a valuable increment being done. I'd ask the individual that posed that subject if they had ever had to postpone a demo because an issue was found that prevented the feature from working properly when they had a plan to use? Ask them if they had ever presented a feature to the users after months of development work to have the user say it wasn't satisfactory or it didn't solve the problem they are having?
I also ask you who is representing the customers in the Sprint Reviews? Since the whole purpose of the Sprint Review is for the Developers, Product Owner, and stakeholders to discuss the results of the Sprint and plan the future direction it doesn't seem like you are making the best use of this. In my opinion, your Customer Team seem logical as a possible stakeholder. Do they see the progression and provide input as the team works?
In my opinion, the delimma you are facing is because of a misunderstanding of incremental delivery, agile practices and the Scrum framework.
Was the person asking that question a Project Manager or hold a PMP? Those are usually the folks who don't understand product development and product management best practices (where Scrum originates from). If the customer is worried about delivery timelines, somebody has failed in delivering value to them early and often.
Let me explain in simple term:
In Azure Devops we are using this level : Epic -> Feature -> Requirements/CHR -> Tasks
So, In a sprint backlog, we are taking Requirements/CHR , not Feature or EPIC
as you know Features = collection of some requirements/chr
SO, here we are using the concept of "Verticle Slicing". Here we can taking those items in sprint backlog that can be deliver at the end of sprint. if there is a bug then we are not showing that particular requirements to our client.
Thus, after some sprints (called sprint release ), client will be able to see done feature (MVP).
Finally, if you will take the entire feature in sprint backlog (insted of requirements) then you may face mentioned problem every time.
and Scrum Master has to take care about how the team is doing verticle slicing in PBR meeting.