Category: Agile

Take a break and read all about it

Agile

Signal to Noise Ratio / Bottom Lining

A Few weeks ago while attending a Coaching Agile Teams class I heard one of the instructors (Lyssa Adkins) make a reference in passing to “signal to noise” ratio in reference to our ability to communicate with others. Her comment intrigued me because I’d never heard that phrase before, so I started to do some investigation.

Signal-to-noise ratio (abbreviated SNR or S/N) is a measure used in science and engineering that compares the level of a desired signal to the level of background noise.

Signal-to-noise ratio is sometimes used informally to refer to the ratio of useful information to false or irrelevant information in a conversation or exchange. For example, in online communities, off-topic posts and spam are regarded as “noise” that interferes with the “signal” of appropriate discussion.

Agile

Are Your Stories Ready?

This week I was particularly impressed with a method used by a Scrum Master to help his team understand which stories on the backlog were “ready” and which were not. It’s amazing how such a simple technique can bring the transparency needed to help a team prepare for a successful sprint. His technique is to use colored stickers as markers on the ordered product backlog hanging on the wall next to the team’s scrum board to indicate the state of the story. If the story is not ready it gets a red sticker.

Agile

Coaching – It’s more than just asking questions

A common belief is that the difference between coaching and managing is simply asking questions rather than giving orders. I used to believe this. Instead of making decisions for my teams and telling them what to do I would ask them questions and get them to derive their own solutions. I thought that meant I was coaching. But the more I got into coaching the more I really wanted to make sure I was doing it right and being effective. So, over the past two years I have invested in myself and in my craft. I have learned everything I can about professional coaching and gotten mentoring by master coaches.

Agile

An elephant and a monkey went for a walk last sprint …

This week I was walking past a conference room where a Scrum Master was preparing for the team’s retrospective. I had to stop and take a picture because I really loved what I saw. Here are a few of the things that really impressed me.

Agile

Agile 2015 Learning and Highlights

Sunday, as I got on a flight and headed to Washington, DC for Agile Alliance’s Agile 2015 conference, I was looking forward to spending a week with other like-minded people who believe in living the agile values and principles and who are investing in themselves and in others to grow in their craft. I anticipate this conference all year because I love the full saturation of agile. I love the networking and new ideas. I love the opportunity to see what others in the industry are up to and to learn from them. And I love meeting new people who teach me great things!

Allison Pollard and I were given the opportunity to present a coaching topic called “Change Your Questions ~ Change Your World” this year. It was exciting to see Allison again and partner with her on this great topic and it was an honor to invest in the agile community at large.

Agile

Scrum Mastering – It’s a hard job. But someone has to do it!

This is me. I’m an agile coach and I love being a scrum master whenever my path allows me to step into that role for a few months in order to start up new teams and develop scrum masters. I’ve been scrum mastering a few teams for the past couple of months and having the time of my life! But now comes the real test – mentoring a few brand new scrum masters.

Agile

Definition of Done – More Than a Checklist

This is Mark. He challenges me. He confronts me. He inspires me. I think he is amazing. Mark doesn’t do things because someone like me who claims to know a bit about agile says so. He looks at the world from every perspective. I love this about him because he forces me to think deeper than I’ve ever had to in many areas. He stretches me as a coach and forces me to keep growing.

Definition of Done was an area where Mark really inspired me to dig deep. This was his concern …

“I hear and see people teaching Definition of Done like it is a checklist of all the things a team has to do in order for a user story to be done. I think this undermines ownership of quality code by the team because the checklist becomes a crutch and an excuse to be mediocre. It causes people to say things like, ‘Well it meets the definition of done,’ when they know that the code still isn’t as good as it could be. It develops the attitude of, ‘Oh well, it wasn’t on the list so I don’t have to do it.’”

Agile

The Art of Creating Space for Growth in the Retrospective

At an open space event the other day a group of people were pondering the topic “Getting people to be engaged during meetings.” Inevitably the conversation turned to retrospectives. People described how some teams complained about being forced to have retrospectives and how others went without complaint but didn’t really participate. Some of the frustrations were that introverts never want to participate and have fun conversations with their teammates.

In short, some scrum masters were describing ways that they have been trying to pull their teams into a place of participating but weren’t being successful. Teams were feeling forced to do something they didn’t want to do and scrum masters were frustrated because no one wanted to play this very important game with them.

As I stepped back from the conversation I began to realize that what was missing was the understanding that there is an art to being able to facilitate an effective retrospective that starts long before the meeting. The scrum masters role in the retrospectives isn’t simply to facilitate while people to talk about what went well, what didn’t go well, and what will we do to improve in the next sprint. It is about creating new awareness. It isn’t about pulling people into the conversation. It’s about creating space for them to learn and grow and innovate in order to become higher performing.

Agile

Bridging the Gap Between Remote Locations

In my years as a consultant I have seen it time and time again. Companies with multiple sites all working together. It is hard to bridge the gap across the miles and inevitably it shows up – The Red Headed Step Child Syndrome. Perhaps you’ve seen it before? This phenomenon happens when the people in offices separated by miles can’t quite see one another as human.

This is usually how I see it portrayed:

I meet people in one site in Arkansas and they talk to me about how “Michigan” has a mindset that is way off base. They explain how “Michigan” really doesn’t understand how to get the work done properly so they need a lot of help. “Arkansas” holds a bit of bitterness because “we” are always getting treated like second class citizens. “Michigan” forgets us, doesn’t give us information timely, has a superior attitude, and doesn’t really care about “Arkansas.”

Then, I go to the Michigan office and meet people there who tell me how “Arkansas” doesn’t really get it. They describe “Arkansas” having a bit of an attitude, an incorrect mindset and lacking understanding of how to get the work done properly. They say that “Arkansas” needs lots of help to get better.

Agile

Psychological Safety – On Taking Chances

Okay, so the truth is that this picture is not me. It’s not even Vermont – where I happen to be working and freezing right now! It’s my cousin Theresa and it’s in Illinois. She is standing on her Dad’s frozen pond and loving it! When I saw her post this picture on Facebook all I could say was, “That is so cool!” But other people who viewed the picture were saying things to her like, “Get off there!” and “Are you nuts!” and “OMG you are scaring me!

Experiencing great things in life sometimes means taking risks. Without risk we will never be as innovative as we could be because we’ll always be playing it safe. Some people are afraid of taking risks because with risk comes the possibility of failure. But, mature agile leaders and teams will recognize that failure doesn’t have to be bad. We learn things through failure that we would never know if we hadn’t tried and flopped. We learn what we never want to do again and what changes we can make to create a better team or product in the future.