Want to add a caption to this image? Click the Settings icon.
One common challenge from Scrum Masters I get as an Agile Coach is to create techniques for psychological safety on their teams. This is a very common request in toxic environments driven by fear where doers are blamed for their actions from unfavorable results.
I even had a Scrum Master approach me saying that he was going to “keep (his) head low” and not facilitate the team when management was demanding results outside team commitments. In response my powerful question to him was, “Are you still a Scrum Master?”
The key point I want to emphasize in this post is the sentence about the toxic environment, and also that as a Scrum Master one of your main responsibilities is to facilitate the development team’s ability to self organize and create that safety. The day that you stop that is the day you stop being a Scrum Master.
Being resilient in general means to be knocked down by life and come back stronger than ever. As Stephanie Ockerman claims in her blog post, agility IS resilience . That cannot be more true! Creating a safe, experimental environment means that you have to expect failure, learn from the failure, come back stronger and do better. It’s not easy at first, but building that resilience gets easier over time.
In my developer days, I built my resilience with a test-first mindset. If you develop to achieve a result, you’re doing it wrong. If you are testing first, failing, and continuing to develop to make the failure pass, then anything is possible. Try it — it really works!
There are many factors that make someone resilient, among them a positive attitude, and optimism. Here are ways that I coach people to build resilience and create that positive attitude:
- Recognize the ability to see failure as a form of helpful feedback: I see this constantly when I am training kids who are interested in computer careers as developers. Failure is the First Attempt In Learning. Start with what happened (the outcome), what you wanted to happen (the intention), the conditions that caused this to happen, and steps to try again with modified conditions. Do this process until you get the desired result. “Conditions” can be anything from a simple “if” statement in a line of code to a key conversation not happening. An error message provides valuable feedback. A statement like, “This proposed solution does not work for me” is valuable also.
- Give immediate feedback if something is not possible. Giving an undesirable result is difficult to hear and to deliver. Honesty can be hard on everyone all around. A good friend reminded me, “Don’t boil the ocean”. If something is not possible simply say “That’s not going to happen”. Don’t promise something you know you can’t deliver just so that someone over you wants to hear about delivering a good result. Perhaps saying something like “instead of this whole thing you want, I can promise this smaller important part”. You can be upset now with honesty, or be upset later with a lie. Your choice.
- Look at outcomes, not results. I look for certain words in vernacular when I want to know if an organization is looking at results vs outcomes. When I hear “requirements” used continuously I see vast needs for improvement. “The requirement is that…, and the result was undesirable because…” Focus on intended behaviors. Have a purpose in mind, and try to achieve that purpose. “Our intended behavior is to…The outcome of this was that…, so for the next go-round we will try…” If you don’t see a difference, simply change “requirement” to “expected behavior” in your vocabulary, and you will see a big difference.
- Consider the conditions of an outcome first, not the people. People make thousands of decisions a day, so there is no way to know all those conditions one of those misjudgments. People are basically good, so they intend to make the best possible judgement. If people know they are getting blamed for a mistake then they will not admit to the reasons surrounding a judgement. People are going to feel much safer if they are questioned on the conditions of their decisions rather than being blamed and shamed for making a judgment. Everyone learns from the misjudgment by letting all the conditions be transparent.
- Build trust, form partnerships. Many times a healthy partnership is more important than the outcomes it produces. With a healthy, trusting partnership, anything is possible. If you think software is your most valuable asset, think again. The relationship with your customers and employees is much more valuable. Since I formed this company I have seen the value from a partnership built on honesty. I would much rather see communication rather than empty promises. I am much more valuable as a customer, supplier, coach, mentor, learner, apprentice, friend than a training class, document, certification or block of pristine code.
