Most of us now have some experience with Agile Scrum practices. Many of us have had years of practice on multiple processes. As a consultant, I have the opportunity to see many differences in how organizations implement and practice the most popular development process methodologies.
While the prescription for good practices is well-documented, many of us have lost our “mojo” at least once and seen many of the benefits of using the process decline.
In this blog, I will indicate some key points required to return to optimal agile performance. I will highlight three common pitfalls, some common causes of those problems, and reminders of how to get back to a high-performance Scrum implementation. Let’s dive in.
Pitfall 1 – Stories never really get done in one sprint.
Do you find yourself working on the same story across multiple sprints? One common complaint I hear is that the only way we can call “it” done, is to get a plethora of features all completed and tested as one unit.
For instance, a customer wants to place an order and see a confirmation that the order is shipped. The goal is that they can be assured all the processing for the order has been completed, and the order is actually shipped.
Ok, so maybe this is an exaggeration, but wow! How great would that be?
However, think of all the steps that might need to be accomplished; order fillers must pull inventory, the order must be packed, the package must be addressed, then picked up, then an order confirmation must be captured and returned to the actual user that placed the order.
Assuming you can automate this story and that you have not yet implemented any of the steps, this story will probably be 40 or 100 points. Shouldn’t we make this an epic and create smaller stories? The product owner insists that doing part of the story will not represent work that is ready for production.
Common Cause – Large tasks not approached in an iterative manner.
It may seem like common sense that all the work that happens from one button press, like “Process Order” is one story–especially from the user’s or product owner’s perspective. But trying to cram multiple sprints worth of work into a single story is not the answer.
Solution – Effective story decomposition.
The key to making Scrum work is to build the system incrementally. You should always decompose your user stories into small enough stories that within one sprint the feature you are building can be fully coded, tested, and signed off by the production owner.
In the scenario above, having an initial story that stops with inventory fulfillment is a much more reasonable division of features that could be addressed in a single sprint. Maybe you find that this initial story in the epic can be done-done, (entirely implemented, tested and signed off) in only half a sprint.
Then perhaps the next part can be started in the same sprint. Alternatively, you may find that the first story takes a complete sprint by itself.
Decomposing epics into small stories that may only provide partial functionality can allow the team to focus on a specific set of scenarios. They can avoid rushing to get just the happy path done and working so that the next feature set can be started.
Pitfall 2 – Product owner decisions are not being captured.
Imagine a simple user story that said: “As a sales rep, I want to give my customers one dollar off for every three widgets that they order so that customers are encouraged to increase the number of items ordered.”
As you are implementing this story, you see that in the inventory, a widget bundle–an offering that packages four widgets together for a discount— is counted as four items. So, you pass the product owner in the hallway and ask him whether the widget bundles should count as one item or four? The product owner responds to count them as one item. Where do you record this decision?
Many times the developer will get the answer and include it in the code. But, three sprints later, a tester asks why he only got a three dollar discount when he bought 12 widgets. Is that correct? It’s supposed to be a dollar discount for every widget. Where do you find proof of the product owner’s decision?
Common Cause – Product decisions are only communicated through conversation.
One of the first things you probably learned when you first were taught about user stories was:
“A user story is a placeholder for a conversation” and “Collaboration over Documentation”
So, does that mean you don’t document these decisions?
Solution – Don’t Document, Automate!
Agile Scrum encourages collaboration over documentation. This does not mean no documentation, but to only document when the documentation value outweighs the cost of doing so.
One might argue that including all in-story decisions in say, JIRA, or even on a notecard, gives you a place to go back to and verify the discussion. However, if the first time the information is wrong because a decision was captured in a document and then reversed, but that decision was not documented, you lose faith in the documentation. Documentation only provides value when it is trusted to be accurate and up-to-date.
A better solution is to write automated tests. Use a business-driven test framework, like Cucumber. It allows you to capture scenarios that product testers and even product owners can read and understand. But, even more importantly, are run against the actual codebase to ensure the product actual implements the scenario.
For instance, consider adding a cucumber test that says:
Given 3 widget bundles placed in the shopping cart
When my order is placed
Then 12 widgets are shipped
And $3 discount is applied to the order
It is actual, verifiable documentation of what should happen when three bundles are ordered as relative to discounting. If the decision changes and the code is changed without changing the test, the test breaks. The automated tests are always accurate and are runnable proof of the decisions that have been made and implemented.
Pitfall 3 – Post standup, the development manager wants to meet with the team to get the status of the sprint.
So, it is the middle of the sprint and there are seven stories in progress. A couple of severe bugs are holding up progress. The development manager wants to know where we are with completing the stories in the sprint.
For those of you effectively using Scrum methodology, this seems silly. However, I have seen it more than once.
A team starts going through the motion with stand-ups. There are stories and bugs on the scrum board, but no tasks. Every day “Bob” says, “I am working on story 1234 and I think I’m almost done,” but nothing on the board moves. Testers have communicated bugs on stories, but nothing is added to the board for the bugs. They are treated as separate stories and not tied back to the in-progress stories.
Common Cause – Not effectively using the Scrum Board.
The way that an Agile scrum board is intended to be used is done that way for a reason. Misunderstanding what goes where, why there are swim lanes, and why there is a difference between stories and tasks can easily lead to a hodge-podge of MIS-understanding.
Solution – Make your Scrum Board radiate information!
An effective scrum board is intended to be an information radiator. If you stand up close to it and read the story numbers, descriptions, points, task descriptions, hours and initials of who is working on the task, you can get a lot of detail about what is going on. An effective scrum board also allows you to stand way back and get a quick view of how the sprint is going.
If most tasks are in ‘To Do’ or ‘In Progress’ gathered to the left side of the board with only a few stragglers to the right, then you know not much progress has been made; hopefully, it’s the first couple days of the sprint.
As the bulk of the tasks move toward the right, you can see progress being made. Outliers, tasks lagging behind all the others, indicate stories where help may be needed with development. 80% of tasks sitting in verification can be an indicator that your developers are not getting stories or parts of stories to the testers quickly enough.
Most of what your development manager needs to know is right there in front of them. Most questions are easily answered by the scrum master. No status meeting with the team is necessary. Your information radiator is working.
Final Thoughts
When Agile Scrum is used effectively, it allows you and your team to make progress and produce high-quality features– without unnecessary tasks and annoying, useless meetings.
Take the time to go back and freshen up on what the purpose of all the agile techniques you are using are meant to accomplish. Remove shortcuts and avoid omissions. Any process can become a drag if you don’t put effort into keeping it fresh.
