By Roderick Cain, S&S Associate
As Sean Reilly, S&S Associate said: “Nail it, then scale it”.
There was a recent poll on LinkedIn, “How many teams can a Scrum Master serve? 1, 2, 3 or 4+”, which promoted discussion. A standout being “A good SM can serve two teams, a great SM serves only one.” Which sounds like a quote from Geoff Watts’s “Scrum Mastery: From Good To Great Servant-Leadership“.
Everyone involved in agile should read this book, it is right at the top of my ”Kitbag” and one I regularly refer to.
It also introduced the term “Jira Jockey” which reminded me of a concern a potential scrum master had, who saw the role as JIRA admin. This is obviously far from the truth but without an understanding of the role and how it is there to serve the team, you will never be able to scale up.
With this in mind, here are the additional things (a follow on from part one) that you should be looking out for in your existing practices.
Whatevs: Product Owners are not interested in seeing what has been built for them.
AWOL Customers: Missing customer involvement and feedback, is anyone really using what is delivered? What does the customer think of what is delivered? Can we A/B test functionality?
Not just for the hell of it: The Product Owner is not engaged and does not appreciate that this is for them and their customers.
How are you? Good and you: The view that everything is fine and we are doing it all 100% correct. There is always time to take stock, be curious, learn and look for improvements.
Health and SAFety / LeSS is NOT more: You need to slog the path to agility first, you cannot just jump on the “release” train to Enterprise Agile.
Change is Good / Transformers – evil robots in disguise: What tier of change are you looking at – Team/Tribe/Enterprise? Does the word Transformation scare people? Is continued incremental change better?
Show me the money value: Teams do not understand the “value” that they are delivering, they are just working on features.
MVP: Maximum Variable Product: When everything is a high priority then nothing is. Look at that new shiny thing. JFDI leadership requirements. Amazon does it so we need to!
More swimlanes than an Olympic pool: The boards are sliced and diced by multiple Epics that are being used for grouping features.
There is no ‘I’ in Team: Epics are being worked on by individuals, so lots of specialisation. If a team member is away then work on that Epic becomes blocked. There is a lack of shared knowledge, leading to a lack of collaboration.
You want to Bet: Due to a slow and procrastinated “ideation to release” process not enough experimentation takes place.
JIRAs: When stories start getting called JIRAs you know you are in trouble.
Useless Archaic Tedium (UAT): User Acceptance Testing is predominantly manual and takes weeks, causing releases to be batched up, product debt and delay in measuring and realising customer value.
“How much scrum would a Scrum Master master,
If a Scrum Master could master scrum?
He would master, he would, as much as he could,
And master as much as a Scrum Master would.
If a Scrum Master could master scrum.”
Cindy Bloomer – Transformation Leader and Agile Coach.
With more ground to be covered by Rod, stay tuned for part three of Agile at Source. In the meantime, missed part one? Check it out.
If you’re interested in bringing the true power of agile to life for your business, click here to book in a chat.