Skip to main content

Underlying Mechanisms of Team Based Scrum

Mike Cottmeyer
Reading: Underlying Mechanisms of Team Based Scrum

It’s getting all too common to walk into an organization that thinks they are doing Scrum, but isn’t seeing any real benefit from their efforts.  They’ll think they’re doing Scrum because everyone attends a daily standup, they plan every two weeks, have someone called a Product Owner, and another called a ScrumMaster. They know the ceremonies. They know the roles. They know the artifacts. But something isn’t working.

The reason Scrum isn’t working for them is that it isn’t the daily standup, or the roles, or the artifacts that make Scrum work. It’s the shared understanding that comes from the backlog, the visibility that happens as a result of the artifacts, the accountability that comes from having complete cross-functional teams, and the ability to measure an increment of working tested backlog every couple of weeks so you know how you are progressing.

Good Scrum teams have all the artifacts, roles, and ceremonies… but so do many of the bad ones. So, let’s break it down a little and see what’s the difference between when Scrum works well and when Scrum goes bad.

The Backlog

There are lot’s of ways to successfully create a product backlog. I’ve seen Product Owners create the backlog with the team, I’ve also seen them do it solo. I’ve seen teams make the backlog up every two weeks based on real-time customer feedback. I’ve had small teams of experts create well articulated roadmaps supported by a rolling three month, risk adjusted, and estimated set of user stories. All these approaches work.

I’ve personally coached teams to use the ‘As a user, I want a feature, so that I can get some business value formula’.  I’ve also coached teams to use a short, high-level description of the need and that was enough. I’ve also worked with teams that have created such comprehensive user stories that they started looking like formal use cases than user stories.  It all depends on what it takes for the team to understand what’s being asked of them.

And that really get’s to the heart of the issue with the backlog.  The backlog has to be clear enough to the team that they can come out of the sprint planning meeting with a pretty darn good idea of what it takes to build the software.  The two most common anti-patterns are when the stories are too large and ambiguous the team isn’t clear on what’s being asked, followed closely by a backlog full of technical tasks that the developers made up themselves.

Without shared understanding of where we are going, a Scrum team is going to fail.

The Team

Teams come in all shapes and sizes. I’ve seen teams made up of 2 developers and a tester. I’ve seem teams made up of 5 developers and 5 testers. I’ve also seen… but do not recommend… teams made up of 20 developers, 5 testers, and some analysts. Some teams have everyone necessary to deliver a working tested increment of product, some teams have folks from outside they depend on, some have to coordinate with other teams.

The common guidance is that a Scrum team has to be organized around a feature or a product so that there can be end-to-end accountability for delivery of the user story. In large organizations that pattern will break and you’ll have to consider using component teams or capability teams and coordinate and integrate the output of these teams in a more complex delivery framework… definitely not something covered by Scrum.

What really matters… is that whatever you have the team assigned to build… whatever part of the product they are responsible for… the team has everything necessary to build a working tested increment every several weeks. The team is fundamentally an accountability structure. If the team does not have everything necessary to deliver a working tested increment of the their backlog… they cannot be held accountable and the whole thing will begin to erode.

The Product Increment

This is probably the most important part of the Scrum process. If you are working on a team that can’t produce a working tested increment of the product at the end of the sprint… you really are not doing Scrum. That said, just like teams come in all shapes and sizes… product increments can come on lots of shapes and sizes. Not every Scrum team is delivering something to an end-user every two weeks.

Some teams are responsible for putting software into production each and every sprint… sometimes even more often. Some teams can’t release that fast and have to batch up sprint outcomes and ship at the end of a quarterly release. Some teams… some products… can’t even release to customers on quarterly boundaries and have to batch up several internal releases into a year release (think tax software and ERP systems).

What matters about the product increment is that you have a measurable chunk of product that allows you to unambiguously measure how much you’ve achieved against your goal.  The increment shouldn’t have technical debt. It shouldn’t have defects. It shouldn’t be waiting on someone outside the team to do their part before it has value. Anything you defer to a later sprint creates a hidden indeterminate amount of work on the backside of the project.

In Summary

Scrum is an easy process to do… but not so easy to do well. You can have Product Owners, ScrumMasters, daily stand up meetings, sprint planning, sprint reviews, and sprint retrospectives. You can have backlogs and burndown charts and still have no idea where you are going.

To do Scrum well you have to have shared understanding… you have to have a backlog that is broken into small chunks, can be understood by the team, and meets Bill Wake’s INVEST criteria.  NOTE: Remember this when I start talking about scaling the backlog… the reason many backlogs suck is because they don’t meet the E criteria.

To do Scrum well, you have to have a team you can hold accountable. The team has to have everything necessary to produce a working tested increment of software.  If they don’t, they should have very easy access to the people they need when they need them. If that’s not possible it is impossible to commit and hold themselves accountable for delivery.

To do Scrum well, you have to be able to actually produce a working tested increment of product every couple of weeks. Teams that can’t do this have no idea what they’ve built, how fast they are going, or how much work is piling up behind them for the end of the project. Teams that can’t do this, can’t get feedback to make sure what they are building is on the right track.

I’d suggest that if you have shared understanding, complete teams, and the ability to create a working tested increment of product every couple of weeks… you are probably doing okay. If you have that and all the roles, ceremonies, and artifacts of Scrum… you are probably a very disciplined Scrum team.

If you don’t have shared understanding, complete teams, and the ability to create a working tested increment of product every couple of weeks… then that’s the problem, and that’s what you’ve got to go get fixed.

Check out the previous post, Fundamentals of Agile Transformation.

Next The Theory of Constraints and Brooks’ Law

LeadingAgile CEO and Founder, Mike Cottmeyer is passionate about solving the challenges associated with agile in larger, more complex enterprises. To that end, he and his team are dedicated to providing large-scale agile transformation services to help pragmatically, incrementally, and safely introduce Agile methods.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

What is the Worth of a Good Product Owner? w/ Tim Wise

This week, on SoundNotes, we’re featuring another question from a student in one of our Certified Scrum classes. The question came from someone who’s working in an organization that doesn’t see value in the role of Product Owner and isn’t convinced that it’s needed as part of the Scrum Team. The question: What is the […]

How Do I Use Scrum on Data Warehouse Projects? w/ Dave Nicolette

In one of my recent Certified Scrum Master classes, I had a number of students who were working on projects involving migrating from a legacy data warehouse to new data warehouses. Figuring out how to apply Scrum to the work they were doing presented a number of challenges and left some open questions.  Here are […]

Maximizing the Amount of Work Not Done

One of the principles of the Agile Manifesto reads: “Simplicity – the art of maximizing the amount of work not done – is essential.” Okay. What does that mean? Does it mean we should avoid doing our work to the extent possible? Well, not exactly. Consistency Between Lean and Agile Principles Without coming at the […]

Prioritizing the Work to Maximize Return w/ Dennis Stevens

This week, on SoundNotes, we’ve got Part 3 of a trio of interviews with LeadingAgile Chief Methodologist and Co-Founder Dennis Stevens. The series focuses on how to build an organization that can embrace change. In the final episode of the series, Dennis and Dave cover how to prioritize work being done to maximize return. During […]