Maybe you got pointed to this page with a "don't be Joe" comment? Don't consider it an attack. Consider it a learning opportunity. We're all Joe on occasion. What matters is what we do about it. The less Joe we are, the more successful we will be.
Here comes Joe
I believe that Joe wants to do a good job. Unfortunately, Joe doesn't know what "doing a good job" in coaching means. And that spells trouble.
Joe is certified
On their very first Sprint Planning session, Joe's team asked why they had to do Planning Poker. Joe answered, "I am a CERTIFIED Scrum Master, and that's the way you have to do it in Scrum." The team couldn't trust their ears: Joe's CSM certificate made him an authority on Scrum? They shook their heads, but obliged. The next morning, when Joe entered the office, he was shocked.
The entire back wall of the office was plastered with certificates. Joe thus learned that two developers held a CSP, two had obtained PSM-II, and everyone had gone through Scrum training years before Joe. Above that list of certificates, the team printed a big banner, "We know what we're doing, and if anyone has doubts - we have the certificates to prove it."
Joe was humiliated, and he could never establish any form of credibility with his team. Within just a few months, Joe left - and the team clearly told management that they'll never accept a Scrum Master who borrows authority from a silly certificate.
Scrum training is really just something that gets us started on our learning journey. Joe should respect that others around him had their own learning journey, and it could be that they are much further than he himself.
Joe should be humble in order to build trust: "I am new here. I don't know who you are, how you work - or why you work this way. I would like to learn. How are you currently planning? How does that work for you?" These are simple, yet extremely effective ways to figure out where real problems are. We don't need to make changes "because Scrum says so." We'd like people to be successful, while reducing unnecessary pain.
If the team doesn't know about Planning Poker, and they have one of the problems it can address, Joe might start the conversation with, "I learned a technique in my training. Would you want to give it a try?"
And most of all - Scrum doesn't even mention Planning Poker. It's an optional, supportive practive. Joe should learn what makes or breaks Scrum before making bold claims.
Joe focuses
During a Retrospective, Joe went into great lengths to explain to the team that developers need to be "T-Shaped," or even better: "M-Shaped:" They should have a broader horizon, not only doing software development, but also learn how their business works, how to test, how to engineer requirements - everyone should be able to do everything.
One developer asked what Joe understands about software development. He answers, "I am a Scrum master. I don't need to understand. My focus is Scrum."
Another one inquired what Joe understands about the product. Again, "My focus is Scrum."
How about the company culture? Yet again, "My focus is Scrum."
Developers shook their head, then proceeded, "Isn't that hypocritical? You expect us to understand things you yourself don't understand, and you allegedly have a reason, but not us? How come?"
Joe reasoned how the Scrum Master's role is ensuring Scrum is done properly, and how challenging that is. The team wanted to have none of it, asking "Do you really believe that your stupid little 17-page guide is more complex than all of Software Development, our product, and the entire company around us?" - Joe countered, "The Scrum Master is a very special role, and if I'd get into those domains, I couldn't meet my own role properly."
The true value of a Scrum Master is their ability to lead meaningful change. The question, "but what is meaningful?" - requires the Scrum Master to know enough about the context to ask the questions that need to be asked. At a minimum, Joe should be curious about what the team is currently doing before proposing any changes.
While Joe doesn't need to be a senior developer, Joe should show some openness and try to learn just enough about development to determine whether any of his suggestions even make sense to someone who does. It's all right if Joe doesn't understand anything about development: sitting down with a developer and having them explain how they work is a fast and easy way to figure out what the team is currently doing. Quite often, when people explain things, they already realize that something "we've always done" just doesn't make sense.
Joe also won't need to understand the details of every single one of the product's features. Without ever having managed a product before, however, Joe's advice to the Product Owner will be of limited value. Joe could start their own pet project - for example, running a Kickstarter campaign. The learnings will be invaluable for Joe.
Joe also should do a reality check: Understanding the organizational context is Joe's job. Indeed, that's the most important thing Joe has to do in order to help the team become effective.
Finally, Joe should invite rather than impose. Instead of telling his team to change their ways of working, Joe could create a link between a pain that people have, and how a specific change could make their life better.
Joe highlights complexity
Joe has learned from coaching that "in complex, adaptive systems, you can't know the outcome until you after tried." Joe uses this line to discourage any form of plan-driven approach, as well as any prediction of outcomes.
When management asked for a delivery forecast, Joe suggested - "we don't know, it's done when it's done." When developers discussed an implementation, Joe suggested - "Why don't you just get started? You'll know later if it worked." Joe's team was unaware of good engineering practice. Joe took it easy - "In the Complex Domain, we don't even know until afterwards whether we needed them."
Eventually, Joe's team got into a real pickle: the low quality product irritated stakeholders. Joe argues, "That's uncertainty. We use Scrum because of uncertainty."
Joe never mentioned that neither complexity nor uncertainty are binary: Things can be more or less complex, and more or less certain. Joe pushed his team into Chaos by removing whatever certainty they had, and making things complex that could have been simple.
Joe's doesn't need to highlight the existence of complexity - success isn't knowing about complexity, it's simplifying until things become manageable.
"Complex" isn't an absolute. Planning, forecasting and good engineering practice could all help to make things simpler. It's just that we shouldn't bet on them.
When Joe's team has to make a forecast, Joe needs to learn what the forecast will be used for, and what the simplest way of providing the necessary information is. Clarifying margins of error and the tradeoff between accuracy and value reduces the complexity of forecasting.
When Joe's team wants to discuss implementation, Joe could probe where the team is uncertain, and what the consequences of a wrong choice are. Planning ahead just enough to avoid poor choices that could be hard to reverse is smart. If Joe was smart, he would even encourage the team to ask, "What will be the long-term consequence of this choice?" - and coming up with possible alternatives before implementing anything. That would reduce the impact of technical debt, which in and of itself causes complexity in other areas.
Equipping people to do the work they need to do can remove a whole layer of complexity in the "How."
Joe shows flexibility
Whenever someone addressed a question to Joe, he displayed his zen-like wisdom by always answering "it depends."
Joe's team eventually got fed up with this answer, because - of course: it depends. They knew that already. But: on what? Joe was missing that part.
During a Sprint Review, a senior developer proudly announced that they had fully automated Joe - the team presented a website with a free form field, and when you hit Enter - a text would appear: "It depends." Joe's manager rolled her eyes - it became Joe's last working day: his default answer wasn't earning him any respect - neither within, nor outside the team.
Yes, it's true that "it depends." The question is: on what does it depend? What are the important factors that we need to focus on? Where are the forks in the road? What makes A preferable to B - and why?
The answer, "it depends" avoids commitment to the inquiry. A conditional answer is only valuable when it reveals viable alternatives or relevant risks.
If Joe doesn't know an answer, the best option might be - "I don't know - let's find out together?"
If Joe knows only one answer, he might state, "The only thing I'm aware of is this. We could research alternatives."
If Joe has limited experience, he might answer something like, "I have experience with this. I know there are alternatives, but I have no experience with them."
Finally, a coach doesn't get paid to be a dictionary. Stating, "I don't know" is not a character flaw. Much rather, it would be a character flaw of Joe to make it look like he has an answer, when really - he doesn't.
Joe keeps the rules
Joe took his responsibility very serious to make sure that his team had a proper Scrum environment where the rules were followed.
Joe's Scrum Team had visitors from other teams during their Daily. As one developer mentioned that there was some issue with a component being worked on by another team, that person couldn't stay silent any more and stepped forward. Immediately, Joe stepped in, "The Daily is only for the team. Nobody except for them speaks." The silenced developer raised his hand and barely could open their mouth before Joe escorted him out of the room: "If you can't follow the rules, you're not welcome."
It later turned out that Joe's team was building incompatible features and their sprint's work could not be integrated without major rework: Joe had successfully stopped the only person who could have helped from speaking up.
Communicating the right things right at the right time is extremely difficult - even if we dedicate our entire life to this topic, we still get it wrong more often than not. The journey starts with a realization that communication tends to be pretty messy almost everywhere.
As a Scrum Master, Joe has to work on helping people communicate more effectively. When they don't know how to do this, Joe has to find out. Blocking necessary communication is never the right solution - someone will always end up with bruises.
Joe's first responsibility isn't simply to make sure that the rules are followed: Where team members lack essential information, or they aren't providing necessary information to others, that's a high-priority impediment that dramatically reduces their effectiveness - and Joe is accountable for the team's effectiveness.
Joe should try to discover where, how and why information flow between the team and outside actors is broken, and work on fixing that. Scrum has very little to say about information flow across team boundaries. When people outside the team are part of the same system as Joe's team, Joe has to find ways to help everyone communicate more effectively, not just the team amongst themselves.
If in the short term, this means breaking the rules of Scrum, Joe should accept this breach, point it out, and ask, "How should we deal with this next time?" Otherwise, Joe risks being called a Scrum Fanatic, who inists on rigorously following the rules, "without reason and against all reason."
Joe protects the team
During a Sprint Review, one of the stakeholders mentions that they're not happy with the outcomes of the Sprint. Immediately, Joe intervenes to point out that the team acted based on available information, and "if you don't give us the correct information - you need to work on that."
On another day, there was a full server outage. It turned out that someone entered data that corrupted the database. Again, Joe was ready: "You have to train users properly. It will take us days to clean this up. You can use that time to train your users properly, so this doesn't repeat."
Yet another day, finance needed some figures to calculate investments. Joe shot down the request, "If we'd help you with that, we're not going to meet the deadline for the trade fair."
Joe was slippery like an eel. Whatever problem stakeholders faced, Joe always found a way to flip it around and make sure that the problem landed somewhere else. This indeed protected his team both from overload and blame. One day, though, a sales executive mentioned to a board member, "They're not helping at all. Each time I meet them, I wish I hadn't wasted my time." - that was also the team's last Sprint.
"Protecting the team" is a responsibility that needs to be considered in context.
Sheltering the team is a short-term mechanism to stabilize the environment. By pushing the problem elsewhere without defusing the conflict, Joe sets the stage for drama that will make things worse for the team in the long term.
Joe needs to show courage by taking ownership of the conflict, and guide parties to resolve it.
Likewise, Joe needs to create an environment where everyone from his team feels confident to courageously say, "Yes, we didn't think of this. Let's work on this and find a solution that works for everyone."
Summary
Did you realize how I managed to sneak the five Scrum Values - Courage, Commitment, Focus, Openness and Respect - as well as the foundation of trust - into the article? Joe becomes a beacon of all that Scrum is, not so much by what he knows - but by being. Every day, Joe can take a few minutes off to reflect in silence, "Which of the things I did today reflect the Scrum Values, and which of my actions don't? What could I do tomorrow, so that I am a living example of what the Scrum Values mean?" Joe could also invite his team, his peers and his management to give him feedback on how they see the Scrum Values in what he does.
We make mistakes. We have setbacks. We act based on what we know today, and tomorrow we may cringe at what seemed like a good idea today. We progress not by trying to be perfect, but by dedicating ourselves to learning. If Joe keeps this in mind, then one day - Joe will be a Master of Scrum.
