Web Development Business

Refreshing Your Scrum

Keith Shakib Agile, Consulting, Design, Dev Methodologies, Problem Solving, Soft Skills 3 Comments

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.

See Also:  Spring Boot and React: Happily Ever After

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.

See Also:  .NET Memory Management with dotMemory

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.

Comments 3

  1. A typical, informative blog from Keyhole. The biggest issue I’m seeing on a current project is in the code review stage. The client says it’s typical to have a 24+ hour review timeline before anyone even looks at the code. That potentially has a developer waiting for a Pull Request or a ‘needs work’ rejection. If in the meantime the developer starts another story branch, things get tangled pretty quickly. I’ve seen code bounce between review and back to development multiple times depending on the reviewers, which results in a story getting carried over multiple scrums. Some people review only pieces of code at a time, so those 24 hour gaps stretch out the tasks to do. Others review everything, then create many tasks. Some reviewers are picky about the placement of comments and logs, others picky about embedded spaces that may have been added when code is formatted. A lot of downtime is spent over days remedying small things that take away from actual coding. I’m thinking maybe have more junior, or new onboarders, assigned to these minor syntactical fixes and free up smes. What do you think?

    1. I see this problem a lot too. The best agile teams are the ones that are collaborative, that is, they meet and talk and discuss face-to-face (teleconferencing and texting counts for remote teams). But for some reason, some developers prefer there reviews to be slow and systematic and online. There can be advantages to that, but you’re not going to be able to move quickly. Here is what I prefer.
      1 – Have an online approach that the team is committed to using quickly and efficiently for the easy commits. Reviews must be done within, say, an hour of being posted.
      2 – Have an on-demand in-person code review process where the person committing code explains what they are doing with the expectation that you may have to go back to the drawing board to fix problems that are big.
      3 – Adopt an approach of “a little technical debt is OK for now” where smaller clean-up items are annotated as TO-DO’s in the code. BUT ONLY DO THIS IF YOU DEVOTE TIME TO CLEANING UP TECHNICAL DEBT ON A REGULAR BASIS. Regular hardening sprints are good for this.

      I like to use the approach #2 anytime a new pattern is being adopted or a pattern is being modified. Not only do you get face-to-face feedback, but the rest of the team gets to hear about it and learn about it.

      Every team has to decide what works best for them as well as being able to recognize when the current approach isn’t working, just like you’ve explained here.

What Do You Think?