The top 3 complaints that I hear about from my students and have seen with teams I have supported:
Dependencies
Pressure from stakeholders to take on work regardless of capacity
Unclear requirements
Do these sound familiar to you? We are going to focus in on Dependencies.
For Scrum teams, dependencies are a holdover from traditional project management, where work flows through teams of specialists who perform specific work: Analyze, Design, Build, Test, Deploy. The project moves forward slowly from one phase to the next. To “efficiently use the resources,” we have those team members work on multiple projects to ensure they are not sitting idle. From an accounting perspective, it maximizes headcount ROI, rotating experts like cogs in a machine so idle time vanishes from spreadsheets. However, the focus becomes staying busy rather than producing work we can get feedback on or deliver value from.
Scrum teams still tackle this same work, but the big change is that we are going to do all of it in a single Sprint. We are focused on turning an idea, or hypothesis of value, into reality by updating our product. My students respond, “Ummmm… ok… that sounds interesting, but how?”
The first thing we have to do is face reality. You are not going to be able to change the way your entire organization works based on an idea alone; you need evidence. An interesting pattern I have seen is teams wanting case studies from similar companies that have successfully done this. That often ends up creating more opportunities for excuses (“we don’t have their funding,” “we don’t have their tech stack,” etc.) instead of empowering movement forward.
My recommendation is to focus your efforts on creating an experiment. Get buy-in to bring all the right people together for a single Sprint, with no other distractions, and see what they can do when they are allowed to work together. The goal is to turn at least one idea into done work that can be used to get feedback, and maybe even deliver greater value for your customer.
This is the first domino to fall in creating larger change. Demonstrate that a team working together, without external dependencies or distractions, can turn one idea into a real product update that invites stakeholders to provide feedback or, even better, gives the team validation from customers. Then the question becomes, “Are we good to do another Sprint like this?” If your stakeholders have seen a desirable change, it can create a hunger for more of it. This can be the pivot that turns skeptics into advocates, because they have seen it work for them in their own context.
If you're ready to test this in your next Sprint but need help getting that initial buy-in, or support in getting your team focused on collaboration, reach out to us at Improving. We have experience helping teams deliver their first great Sprint. Let's chat and make your first domino fall.
