If you have been following CLT’s recent blogs, you will see that we are on a crusade to end FAKE SCRUM. Here is a our next example:
The following is a real conversation at an Agile organization. Names have been redacted to protect the guilty.
Organizational Leader: “We need to optimize the use of our Scrum Masters. They should all work with at least 2 Scrum Teams”
One Sprint Later…
Sprint Review - Organizational Leader: “Scrum Master, why didn’t the Team “A” reach their Sprint Goal?”
Scrum Master: “I was too busy working with Team “B””
Follow up conversation with the Agile Coach (Q) and Organizational Leader (A):
(Q) What problem are we trying to solve?
(A) We need to keep our Scrum Masters 100% utilized.
(Q) What was the result of keeping our Scrum Masters 100% utilized?
(A) The Scrum Team missed their Sprint Goal
(Q) What is a higher organizational priority? Meet our Sprint Goals or keep our Scrum Masters 100% utilized?
(A) Meet our Sprint Goals
(Q) What change should we make for our next Sprint to give our Team the best chance to meet our Sprint Goal?
(A) enter your answer here...
Sound familiar? Why do we keep doing this to ourselves? We wanted to work using the Agile Values and Principles, but we decided to adjust them to make them fit our organization.
Did we change the rules of Waterfall to make them work for our organization? No way! We Gathered Requirements, Designed the solution, Implemented the solution, Tested the solution and then Maintained the solution. And we got it right ~33% of the time.
So why change the rules of Agile and Scrum and expect to get the full benefits?
Some favorite Fake Scrum Quotes from Organizational Leaders and what they really mean:
"We really love the Scrum concept, but our business is too complex" - Translation: "We (Leaders) don't understand our business." Can we agree that Netflix, Amazon, Microsoft and Spotify are complex businesses? How were they able to make this work?
"Developers don't want to talk to "the Business". They just want us to tell them what to code" - Translation: "We don't trust our Teams". Craig Larman reminded us in April's LeSS Class that the original software developers were required to gather their own requirements. This ensured the Developer understood the context and subtle nuances of the solution that the Business wants. Organizations then decided that any time the Developer was not coding was a waste of their time. Agile has proven that IT and Business working together on a daily basis will deliver a more valuable outcome (Agile Principle #4).
"Agile & Scrum Teams don't plan. They just start working" - Translation: "We don't understand Agile & Scrum". Agile and Scrum plan at five (5) different times: Vision; Roadmap: Release Planning; Sprint Planning; Daily Planning. Real Scrum Teams are planning every day! The way Agile plans differently than Traditional (Waterfall) is that the plan is allowed, and expected, to evolve and get better over time. Once the Waterfall plan was "signed off on" we spent the rest of our time trying to figure out how to reduce scope in order to make the timeline. In Agile, we find out quickly (at the end of each Sprint) if we have overestimated or underestimated our work, and then adjust. Would you rather know if you are on track after 6 weeks of work or 6 weeks before implementation?
Here is what we consistently tell our Clients why they should resist multitasking:
Dedicate a Team 100% to a Product. That means a 100% dedicated Product Owner, Scrum Master, and Development Team. Think of what that immediately does for the Team:
100% dedication removes all excuses. Too busy working on Team “B”’s problem to work with Team “A” - Gone. That literally cannot happen working in this way.
100% dedication removes all distractions. If they are being asked to work on something that does not immediately impact the product, they are empowered, and required, to say “no” to that work.
100% dedication allows the team to focus. Picture yourself focusing 80 solid hours over a 2-week Sprint to one feature or issue! Now picture a full Development Team of ~7 people doing that same exact thing. 560 hours on one feature or issue! The Team will make amazing progress.
THE RESULT: A Team delivering consistent business value and a Customer enjoying the benefits of that value
Gerald M. Weinberg has been telling us since the 1990s that multi-tasking is a myth We lose roughly 20% of our productivity for every project we are on. Have 5 or more projects on your plate? Congratulations, you are almost getting nothing done. Does it shock us that high percentage of employees quit on a daily basis, but keep showing up to work? This article is in today's USA Today.
I believe that people want to be successful and feel important at work. Organization Leaders are responsible for setting up the environment for their most important, and expensive, asset to be successful: the employees. Employees executing and implementing the vision of the organization will provide immediate, consistent business value. Ideas are great, but Teams that can deliver on that vision are more valuable than any individual idea.
Allowing Teams to multi-task is allowing them to be sub-optimal. If you are still not convinced, ask the Team. See if they are happy with the way work is being done.
