5 Scaled Scrum Simple Mistakes

Stop Feeding the Engineering Beast

Author

Shane Drumm
April 18, 2024

Hey therešŸ™‚

Agile aka Scrum in most cases gets a bit harder once you have more than one team working collaboratively on same product.

It gets even harder when you have multiple teams working on different products or platforms in the same company, which is common in large organizations who are heavily invested in digital.

In todays edition:

  • Why I hate scrum showcases šŸ˜”

  • The war of chapters: Heads vs Heads

  • Stop Feeding the Engineering Beast

Thanks for opening this email today, hope you find it useful

Shane Drumm, newsletter editor

Have a colleague in your life who obsesses about outcomes, delivering features, business books, product jargon, ways of working? Fire this off to them. Forwarded from a friend? Sign-up for free.

PROBLEM DISCOVERY

When not writing or consulting Iā€™m trying to gather a list of 100 problems that people like me have and see can I solve one or two with AI so I can learn about it at the same time.

Shanes Problem: Iā€™m trying to start calorie counting and increase protein to lose some weight before Port Macquarie 70.3 in 3 weeks time but its really hard to plan ahead. There are some really cool recipes on instagram but I never remember when it comes to food prep.

Would be amazing if you could have a think about it and share your problems with meā€¦

CONTINUOUS LEARNING

5 Scaled Agile Lessons Learned

These are the 5 issues that I think adds to the complexity and should be simplified for success and setup for consistent delivering of outcomes.

Have a Shared Vision

Getting all the teams working on a shared vision is so important. You want teams to be all working towards the same goal.

This gets hard when you have technical platform teams, product teams, integration teams all working on different things.

I argue though it should be clear how what they are working on fits into the bigger picture.

If they donā€™t????

How about segmenting it around users. Keep it simple.

Use Rewards to Drive Right Behaviour

Rewards are a fantastic way to drive behaviour. People love food and free stuff. Two reward/punishment systems jump out in memory.

  1. End of sprint burndown chart award.

  2. A donut tax when teams went over the 7min showcase timeslot.

The resultsā€¦

People refrained from adding items to sprints as it ruined the burndown chart.

People wouldnā€™t show everything they have worked on. Funny enough it was introduced because one session not all teams had time to present in the 90minutes.

It never happened again.

I think I might have some PTSD from that showcase cause next lesson learned is also related to the showcase

Showcases are for Customers

I still havenā€™t seen end of sprint showcases done effectively. My ideal worldā€¦

  1. Room full of users / stakeholders

  2. Teams present their work that is relevant to the groups.

  3. Meaningful questions and feedback gathered

In reality what I have seen isā€¦

  1. Room full of developers / product people

  2. Teams use it as a status update to management

  3. Tech people love talking about tech stuff

Not saying this isnā€™t important. Some developers are proud to present the work they did and share some learnings

BUTā€¦.

this should be a community of practice.

Most of the information being shared the audience donā€™t care and switch off their camera after their team has presented.

Engineering vs Product Chapters

When organisations grow you have lots of people doing lots of things.

Its common to find groups of heads of heads.

Head of Product

Head of Engineering

Head of Data

Head of Marketing

Head of Design

The result is silos. Each of these heads naturally have different priorities. This naturally creates confusion and tension amongst teams and I think the biggest mistake of agile at scale.

Then when you want to align priorities you are creating decision by committee which is even worst again.

In my opinion, these heads are just chapter leads. They should ensure best practices and do people management.

If you want to create silos - create them around end users segments.

If you create them around products - you can have same users using multiple of your products that are misaligned and confusing communications. They donā€™t care about your internal silos.

Priorities should role up to a company direction and how they want to continue serving these users.

Stop Feeding the Beast

One of my pet hates is when people just do what users ask for.

This is exactly how feature factories are creating.

It is lazy product management.

Why are you doing this?

Oh the user asked for it!

The users donā€™t care how other users might be using it or how it fits into the strategic context for the business or product.

User input is vital but just an input.

It is easily in large agile teams to get into a bad habit if getting caught up in ensuring you have a backlog full of user stories for next estimation or refinement session.

You end up creating work to fit the teams needs not whatā€™s right for the product or the business.

Stephaine speaks about the issues her team were having being pulled in various directions with this exact problem.

ACTIONABLE ADVICE

Try to focus on business outcomes or the impacts on the user when you do the next piece of work regardless if it is a feature/initiatives/user story/tech debt. What are you expecting to learn when you complete this.

PIVOT OF THE WEEK

Shifting from a Feature Factory to Continuous Discovery at Doodle was the mission of Stephaine who had seen product discovery done well in er old role but it wasnā€™t as easy as just interviewing customers to solve the problem

AGILE PRODUCT TOOLBOX

šŸ’¼ Want to work in a product driven organization?

NEWSLETTER RETRO

If you want to support The Pivot Newsletter, please consider forwarding this to a friend. If someone you know forwarded this to you, you can sign up here.

Reply

or to participate.