- The Pivot
- Posts
- 5 Scaled Scrum Simple Mistakes
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.
End of sprint burndown chart award.
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…
Room full of users / stakeholders
Teams present their work that is relevant to the groups.
Meaningful questions and feedback gathered
In reality what I have seen is…
Room full of developers / product people
Teams use it as a status update to management
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
⭐ North Star Framework Template ready made for workshops
📝 The Product Vision Board Checklist to win over the business
🛣️ Product Roadmap Kit to help deliver product outcomes
📇 Retrospective Templates Rolodex to keep teams engaged
💼 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