Before the Scrum Guide changed “roles” to “accountabilities,” I made a critical mistake. I tried to improve Scrum by introducing a fourth role for Project Managers.
It seemed like a logical move at the time. I believed it would improve throughput, time to market, customer satisfaction, employee satisfaction, and even cash flow.
Boy, I was wrong. Let me tell you why.
A Simple Question That Changed Everything
While helping a client adopt Scrum, a Project Manager challenged me:
“You said you don’t want to be the Scrum Police and that you would be flexible. Then why don’t we create a role for Project Managers?”
That question caught me off guard.
"Crap!" That's what I thought to myself but didn't say it.
I was inexperienced. It did not feel right but I went with it.
The Costly Experiment
We invested thousands of dollars designing a new Software Development Life Cycle (SDLC) built around Scrum but with a formalized role for Project Managers.
- We took the Scrum Guide as a foundation.
- We defined the accountabilities and responsibilities of Project Managers.
- We mapped how they fit into Scrum’s artifacts and events.
- Then we hired a new Scrum Master and introduced the framework.
It didn’t take long for confusion to set in and for his brain to explode. The Scrum Master struggled to make sense of what we had created.
After all that time and money, the CIO decided to abandon the initiative. The return on investment (ROI) wasn’t there.
Instead of focusing on delivering value to customers, we spent months redesigning the SDLC and turning scrum into something it was never meant to be.
The Real Impact of My Mistake
Looking back, this effort likely led to:
- Decreased throughput
- Longer time to market
- Lower customer and user satisfaction
- Reduced cash flow
- Declining employee morale
- Frustrated stakeholders
Saying no to the effort to build a new SDLC freed up time to say yes to build values for customers, users, and stakeholders.
Instead of reinventing the process, Project Managers took on responsibilities within Scrum teams as Developers, contributing wherever they could. The focus shifted back to delivering real value, and as a result, cycle time dropped from 164 days to just 8 days.
What I Learned From My Failure
This experience taught me an important lesson about setting clear boundaries and non-negotiables. Moving forward, I committed to the following principles:
- I will not support initiatives that waste human potential, customer time, or money.
- I will not contribute to building products that don’t need to exist.
- I will not encourage clients to pay for things they can access for free.
- I will be transparent about my non-negotiables. If my approach doesn’t align with a client’s needs, I will walk away.
The Real Takeaway
This story isn’t about Scrum. It’s about focusing on what truly matters and reminding practitioners like me to value customer time, money, and outcomes above all else.
What do you think?
Get in touch with us today to enjoy a complimentary 30-minute consultation!
Comments