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.