If you’ve learned Scrum and tried to implement it in any large organization you’ve likely run into a few issues. Getting dedicated people on your team is hard. Building cross-functional teams is really hard. Breaking your work down into small problems your customers care to have solved is probably the hardest. I'd like to talk a little about what I see as the most common three things Scrum teams get wrong.If you’re struggling with the above you’ll see the symptoms immediately. As a matter of fact, when I’m first working with new Scrum teams, these are the first things I look for.
#1 - Your backlog is a list of hamburger orders
Take a look at your backlog. Does every item on it have a technical title and little else to describe it? If so, you have a backlog of hamburger orders. Hamburger orders don’t get questioned. The customer usually knows they want two patties, grilled onions, ketchup and mustard. It's not your job as a short order cook to ask the customer how many people they’re trying to feed or if they have a cholesterol problem.
In knowledge work, it is your job to know what problem you’re solving, so it can be solved. So often my clients will start from a 'requirements' document, break it down to a list of must-haves, and the team blindly builds them.
What’s the problem?
Teams can’t be creative if told exactly what to do. Sadly, this is how many developers are used to working. It doesn’t have to be this way. If you treat developers like hamburger order takers you will increase total delivery times, increase time-to-first-value, reduce quality, and discourage innovation.
What can I do?
Present business problems to Scrum teams. Better yet, provide them in order of importance. Work with your technical teams to represent the value needed on a product in terms of problems to solve and document it... then let the technical teams figure out how to solve the problems. Ensure that anyone who reads the backlog can understand the problems to improve communication between the stakeholders and development teams and reduce the need to translate. You did hire smart people, right? Then enable them to be brilliant and empower them to creatively the tackle problems they were trained to solve.
#2 - Your development team isn’t a team at all.
Well, your team is more like a football team that has a subteam of quarterbacks, another subteam of linebackers, and another for kickers that gather every Sunday to play, but your team doesn't always get the same players.
What’s the problem?
Your teams aren’t thinking like teams, not working like teams, and not succeeding like teams. They have different and competing goals. Those goals rarely align to solve business problems effectively.
One of the key benefits to building a cross-functional product-aligned team is to give the team all the skills needed to deliver value, and keep them focused on the same goals. Another problem might stem from having people collected as teams, but they’re working on initiatives that have nothing to do with one another.
What can I do?
Take a temperature of the team. Do they have the same goals? Do they really act like a team? Do they work like a team? If they don’t have the same goals, fix that first. Forget Scrum, Forget agile, good teams solve problems. Reduce the amount of work in progress your team is handling by properly filtering all the requests coming into the team into a single ordered backlog. This is where a strong Product Owner is key.
Work to build and grow your team from the inside... this is a people problem. Start with understanding Tuckman’s stages of group formation (Forming, Storming, Norming and Performing) and help guide the team through that journey. A strong Scrum Master would be a key individual I’d look to for this difficult job.
#3 - Your team has no way to know if they’re on track to finish a large release
What’s the problem?
When a team doesn’t properly refine a backlog during a Sprint you’ll have only a few Sprints worth of estimates. This makes it very difficult to know if the team is on track toward hitting important milestones. If you don’t know, you’re back to guessing and I’m confident there are people in your org that want to know how you're progressing. A common thing i hear is “we’re doing Scrum, so we don’t do dates.” Well that's just unacceptable to anyone writing your checks. Unless you want to keep having status report meetings, lets find another way.
What can I do?
You can release plan if you regularly refine your backlog. Aim to build domain knowledge, create clear description, and track your teams velocity. A good place to start is by writing your backlog items in the form of a user story. Then write good acceptance criteria and apply the INVEST model (see my references):
When your team has a good understanding of the problems they’re solving, they can estimate them and deliver the solutions in order of most important. It’s common in agile circles to use story points as a means by which to estimate. If you do so, they give you a number on the Y-Axis and time in units of Sprints on the X-axis. (see below graph)
A release plan graph (like the above) will give your organization visibility into your progress over time. If stakeholders don't like what they see, they can make a business decision sooner. Show this release burndown in every Sprint review and highlight the updates as your ‘Actual’ line changes over time.
Conclusion
If you’re on a team suffering the 3 things scrum teams get wrong, know that it's common. But also know you don’t have to suffer. Take these ideas and improve your team today. Did i miss ways your teams are solving these problems? Any questions left unanswered? Message me!
References
https://en.wikipedia.org/wiki/INVEST_(mnemonic)
https://en.wikipedia.org/wiki/User_story
https://www.mountaingoatsoftware.com/agile/user-stories
https://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development
Originally posted at www.responsiveadvisors.com