The problem manifests in different facets, such as: A story was improperly groomed, new information became available which invalidated old information, a hypothesis about the product was disproved, etc.
Let's ignore for a minute the fact that "if we had known better, we would not have accepted this story into the sprint". We didn't and so we did. It's there. Now what?
The easy (and wrong) answer
Following the strict Scrum rules, the question is easy to answer: Continue the Sprint, deliver, use the Retro to elaborate what went wrong and do it better next time.That's obviously wrong
We're not in business to "do Scrum". We're in business to deliver working, useful software. If we're not doing that, we're losing our reputation, credibility and - consequently, our customers - in turn: our jobs.
The correct answer
Common sense dictates the correct answer: Do what is right. Now, what is right? We deliver working, useful software.Rather than referring to Scrum, we need to refer to the Agile Manifesto in answering this question:
Let's start with the often-ignored first sentence: "We are uncovering better ways of developing software by doing it and helping others do it." Is it "better" to build something useless? Obviously not. Being agile indicates that we're doing the best we can and from there, we look for even better ways. By simply doing what we're told, we neither do the first, nor the second.
Now, let's screen the Agile Values:
People and Interactions over Processes and Tools - you don't want to follow "the Scrum process" when a face-to-face communication can solve a problem that only exists because of a process.
Customer Collaboration over Contract Negotiation - when your "sprint contract" says to build and deliver X, yet X doesn't make sense to the customer/user, collaborate to find the Y which does.
Responding to Change over Following a Plan - when new information reveals that the Sprint Plan is no longer valid, respond to this change.
Scrum or Agile?
Scrum is an agile framework. The Agile Manifesto is the basis of Scrum. Without it, Scrum is a hollow, lifeless shell that will fail to deliver value. It would merely be a cargo cult, a "scrum-but" of the worst kind.Scrum thrives by living the Agile Manifesto.
Refer back to the Agile Manifesto before clobbering someone with the Scrum Guide or Scrum Primer.
Summary
When you discover mid-sprint that your initial sprint plan (or, even a part thereof) does not make sense - grab your team, including the Product Owner and find a solution.
Never follow an invalid sprint plan: Change the plan, but do it in an agile fashion!
I agree that too many organisations are so focused on "doing Scrum" that they miss the point of using Scrum and they simply don't think in an Agile enough way. However, changing a Sprint or cancelling a Sprint happens more often than not because someone didn't get the user requirements right or simply failed to plan ahead.
ReplyDeleteThe effect on both the Team and the budget should be considered. Also if an organisation thinks it's okay to change or cancel if they think there's an "emergency" they will and continue to work that way.
Responding to change is indeed necessary but is hyper responsiveness more important to than working software and respect for the Team?
Jana, the question is: "Who should do what?" - it is one thing if the Product Owner just changes their mind on a whim.
DeleteIt's a completely different thing when someone on the team - and that includes developers, testers and product owners alike - uncover new information which indicates that a story or some acceptance criteria will not deliver the intended value.
Coming back to your question:
Yes, "hyper responsiveness" is - indeed - needed. Because otherwise, we will deliver dead code that will not only cost us time in this sprint, but also in the next sprint. It would be better to respond by ditching the story than implementing something without value.
Next: how can software be "working" when it doesn't do what it is supposed to do? From a user perspective, "it does not work". Ignoring the user during development yields the classic "works as designed" product which gives IT specialists a bad name.
Third, "respect for the team" - this boils down to opinion. I, personally, would consider it highly disrepectful from the team member who discovered that we are doing something useless or even counterproductive to not speak up.
How exactly we deal with a story that is invalidated is a different issue. But just continuing to implement something users will dislike is highly dis-respectful towards the customer. How would you, being the customer, feel - if someone *knew* they were going to serve you trash and still proceeded to do it?
I agree that if the Sprint goal becomes obselete it should be cancelled. But you are describing a situation where the Team discover some new information. What do you mean by that exactly?
ReplyDeleteIf it is just a matter of the team thinking that they can deliver something better or more relevant to the customer then why not just finish the Sprint, deliver something that works and improve on it in a subsequent Sprint? Perhaps more time should have been spent talking to the customer and in the planning stages, in so doing really respecting the customer and their needs and so avoid such situations.
Customers value predictability and reliability. You can either deliver what you committed to delivering or not delivering anything because someone on the team had a better idea.
True Agility comes from understanding its principles
not slavishly following the "rules" of Scrum. But Scrum is a framework. Rather like an elastic band it can be stretched and adapted to suit your purpose but, if you stretch it too far it breaks and it isn't fit for its purpose.
Jana, situations where the team discovers new information can happen any time.
DeleteYou assume that "more time should have been spent talking to the customer" - that may help in a simple or complicated environment, which is usually not the case.
This does not help in general, because the world is anywhere between complex and chaotic, see more here: http://failfastmoveon.blogspot.de/2015/01/agile-process-models-six-sigma-and.html
Let's take, for example, the delivery of a "Dislike" functionality for a Social Media Platform.
Assume this feature will be delivered in 2 increments.
Our first increment would be the button itself, our second increment would be a "Features who disliked this also dislike ..." function.
Now, we bring the button live and discover that users don't accept the feature at all.
We couldn't know that, because we didn't have real market data until we delivered the first increment.
In this situation, it does not make sense to build and deliver the second increment - it would be better to remove the dead code than to build on it and *then* remove everything again!
We could not know whether users would accept this function, because the first iteration simply served the purpose of testing this hypothesis. You couldn't know the result until you had the function in place.
Now, would you rather wait (i.e. lose Time-to-Market) for at least one sprint before building the increment or plan to react quickly (early and continuous delivery)?
But that's a simple case.
Here is a more complicated case:
Every day, new products are released on the Web. Some are so simple to use that it simply does not make sense to build a similar feature in your product.
If you're mid-development and something is released that replaces (part of) your product, it may be a good idea to just stop what you're doing, because it will be obsolete by launch.
We can't expect your customer to have a crystal ball that's better than ours, but once we see the frontpage news, we simply need to respond.
This second problem only gets excarberated by spending more time on discussions, because the longer the planning phase becomes, the more likely someone else somewhere else had the same - or better idea and simply did it without analysis paralysis.
Some of this depends on what your market is - but the same thing can happen anywhere.
I just recently had a conversation with a developer working in a government organization that tends to be veeeeeeeeeeery slow moving. But even there it happens that the customer is 100% certain of what they want and then for some odd reason, mid-sprint a new law was announced by the government which made the customer's requirement a legal infringement. Your choice - build it, then scrap it - or stop it?
How long do you want to wait until the government is finished announcing all future laws that may affect your customer? Can you plan for law proposals which were never publicly announced?
Again, this is not about "making a better plan" - but about acknowleding that nobody is omniscient, nobody can predict the future - and also, that people actually do make mistakes, regardless of how cautious you are.