Blog: Keeping Agile Non-Denominational
As a consultant one of the things that I enjoy most is speaking at conferences to help people gain knowledge about various topics that they can take back to their workplaces and implement. Often, after a session, people will ask for tips about how they can become better speakers. So, I thought I’d use this blog to give some of the tips I often give them…
Over the past several weeks I have encountered multiple people from completely different companies that are implementing scrum. Some have been trying this for a few weeks. Some have been doing it for a couple of years. Others are somewhere in between. Some received formal training. Some read books. Others supplemented with You Tube videos.Everyone I spoke to had a different reason for meeting with me, an agile coach. Some were people I was interviewing for clients to hire onto their full time staff. Some were clients and potential clients. Others were people in the agile community that asked for mentoring.They all had something in common – doing it alone. In each case, they got information about scrum and tried to implement change. In each case they are struggling. Half of the struggles they are facing are around simply understanding how to implement the scrum framework properly. This stems from brain overload and trying to cram too much understanding into their minds from a two day class or a book and attempting to remember it with no context to their real world. Then, trying to implement the things they learned in their own environment while not forgetting anything. Yeah, right.
I have heard people say all my life, “Failure is not an option,” and today, I would like to challenge this belief and say that in order to succeed, failure must be an option.One of the things you learn when training to be a coach is the art of deep listening. When practicing this art with a team, the coach is listening to people and hearing what they are saying. You also listen to things like tone of voice because much information can be heard in what is not said. Changes in tone, pace and volume when they speak and the inflection in their voice can give clues to what the speaker is thinking and feeling.The coach is listening for things like passion and energy when people speak, they are listening for things that reveal the teams core values, strengths and areas of weakness or greatness where probing questions can begin to push them to new levels or wider areas of thinking.
Earlier this week I met with a group of coaches of various experience levels from different backgrounds to talk about coaching teams. We discussed together our successes and failures in attempts to learn from one another. What follows is a list of the results of what we discovered together.
Earlier this week I attended a retrospective with team I am coaching and watched as a growing scrum master stood up and started the retrospective saying, “Ok guys, I’m going to step completely out of my comfort zone again today. You didn’t like the activity that we started the retrospective with last time so I’m not going to make you do that again. Instead, I came up with something else that I hope you will like a little bit better…”
How can I keep the daily scrum from becoming a daily status meeting? But if we are all answering three questions then who is supposed to be asking the questions? If we are gathering to give our updates on these three questions every day on what we are doing then that sounds like a status meeting to me – what am I doing wrong?These are all questions that I have heard new scrum masters ask. The daily scrum seems like it should be the simplest thing we do, right? The team self organizes daily for a time box of no more than 15 minutes and talks about three things: What I did yesterday, what I am going to do today, and what is standing in my way.So, why is it so hard? In my experience … mindset. Often, scrum masters learn a process to implement but they don’t recognize the mindset that must change in order for the process to have any value. Being self organizing and collaborative, like being agile, is a mindset. It’s not just something you do – it’s something you are. It’s something you become. It’s about individuals and interactions over process and tools. What I’m finding is that when teams are struggling with the daily scrum it’s about them putting the process and tools over the individuals and interactions.
The appreciation languages aren’t just about saying thank you to people for things they have done. The language of appreciation is actually the language of value. It is how we communicate our value to others, it is how we know others view us as valuable, and it is how we know that others desire the value that we have to contribute.
I’m a consultant. Working with one of my current clients as an enterprise agile coach I’ve been thinking a lot about the impact that appreciation has on an organization’s success. As an enterprise coach I am responsible for, on average, 40 teams. (Read my last post on “Scaling the Agile Coach” to find out how I’ve been able to successfully scale this role to be able to coach this many teams.)
I hear companies who have adopted scrum and realized how powerful the framework is soon have conversations around, “How do we scale scrum so that we can use it across the enterprise?” These questions are fair and valid and each company must determine the right answers that will bring success — probably through a series of learning experiments where they will finally settle …. somewhere.
As an agile coach, one of the first things I do when launching new teams is help them to create a Team Values Statement.Traditional working agreements are a declarative agreement by a team regarding how they will work together to bring cohesion and enable collaboration. They set the ground rules, so to speak, so that everyone knows what field they are playing on.
The Agile Manifesto talks about uncovering better ways of developing software by doing it and helping others do it. It goes on to state that through this work and helping others, four consist values have developed. To me, these values go far beyond software development and set a platform for making decisions and forming thought processes.