Tuesday, December 20, 2011


Earlier in December, I had the incredible opportunity of attending a seminar on Coaching Agile Teams, presented by Lyssa Adkins and Michael Spayd. I learned quite a bit, not only from the presenters, but from the other attendees. Days later, I gave a presentation on agile coaching to many of my Sogeti colleagues in Colorado (hurrah for Saturday seminars!), where I learned even more.

A short sampling:
  1. Move – Whenever you try to learn something, use your whole body to help you understand. We had many exercises where movement was involved – either trying to talk to as many of the 28 participants as possible, or identifying our opinions through proximity to a “base” – the statement.
  2. Listen – There are several levels of listening. When I am creating my witty or thoughtful response or wondering what I’m going to make for dinner, I’m not listening to you. When I can stay focused on what you are talking about and how it affects YOU, I’m listening to you.
  3. Ask questions – and not just any kind of question. We learned about powerful questions. These promote inspection and reflection. They help open you up to possibilities that may not have even been on your radar before. What was motivating you? What else? What would happen if ----?
  4. Everyone’s right, partially – One of my favorite working agreements from the group. You may not see eye-to-eye with someone, but if you remember that they may have some element of “rightness” in their statement, you can start to work on the problem/issue faster, rather than arguing over particulars.
  5. Have fun – Life’s more fun when you’re able to see the humor in situations. Laugh at your own mistakes frequently. They won't seem so bad.
  6. Learn from everyone – We all have pretty amazing journeys that got us where we are now. We have all gained knowledge along the way.
  7. Learn from yourself – Hmm, Lyssa and Mike gave instructions this way; I can try that too. Hrumph, it didn’t work as planned, but I can try it again, with this modification.
  8. Get help – Practicing agile can be tough, and finding your way in the company of others makes the journey that much more enjoyable.
  9. Celebrate! We all know about celebrating successes, but did you know you can celebrate failures as well? Try it. Yippee! I just broke the build!

Thursday, December 15, 2011

Mistakes and High-Performing Teams

“Take Chances! Make Mistakes! Get Messy!” If you’re familiar with the Magic School Bus books and videos, you know this is the rally cry of Ms. Frizzle (science teacher extraordinaire) as she takes her class on incredible field trips – outer space, the Brazilian rainforest, even inside one of the students. No matter where the class journeys, the students face challenges, learn new information (about science and themselves), and return safely home, despite the mistakes and mishaps they face. When a teacher like “The Frizz” can provide a safe environment, where mistakes are okay, students learn faster and to a greater depth than in an environment where mistakes aren’t acceptable.
Similarly, an agile team environment where mistakes and learning are supported provides a safe place for the team to learn and gain knowledge, allowing them to move into the realm of high-performance. In fact, I would argue that a team must face bumps, bruises, and setbacks caused by mistakes and failure before it can become high-performing.
I hope most of you are familiar with Bruce Tuckman’s four stages of team development:
  • Forming: Everything’s new; everyone on the team wants to fit in, so conflict and risk are avoided.
  • Storming: The team starts to focus on the problems they need to solve; things don’t flow well; frustration abounds.
  • Norming: The team has addressed most of the rough spots identified in the storming phase; routines and ceremonies are established.
  • (High) Performing: High motivation and knowledge levels result in high performance; consensus is reached quickly; dissent is recognized by the team as useful.
We all aim to be at the performing stage, but we have to go through the other phases in order to reach that goal. It’s rare (if not impossible) for a team to move directly from forming to performing; that would be like running before you learned to crawl. In order to become a high-performing team, members need work through mistakes and failure, experiencing bumps and bruises. And team members must accept and support each other – even in failure. This supportive environment is the fertile ground from which the high-performing element can take off. Talk about team-building!
So, try something new with your team – take chances, make mistakes, get messy! With team support, you’ll be on your way to high-performance!

-- originally posted in Sogeti's regional newsletter, Life@Sogeti, December 9, 2011

Thursday, August 4, 2011

Hummingbird or Helicopter

Now for a little bit of the "mom" part of Agile Mom. I just attended a college fair with my older son, the soon to be high school senior. One of the presenters talked about the types of parents that colleges are seeing these days. There is the "helicopter parent" - those who hover at close distances, then swoop in to rescue their child. There is the "Black Hawk parent" - a slightly more destructive and obvious form of the helicopter parent. And, more recently, the term "velcro® parent" has appeared, to describe the parent that won't let their child fail, or even try something new that may allow for the potential of failure.

The admissions representative talking tonight introduced another term, new to me. "Hummingbird parents" stay nearby, but don't dart in unless there is a life-threatening issue. She went on to describe how hummingbirds will push their children out of the nest, and not allow them back in. When the parent is done parenting, they have a child who can take care of itself.

The hummingbird allows their offspring room for failure. As we in the agile community know, failures provide us with chances to learn, and therefore grow. The small bird also encourages their children to be responsible. If only all team members and product owners could take responsibility for their actions.

What describes you as a parent, and as a scrum master? Do you encourage responsibility? Do you keep the team safe, yet allow for the small failures that provide for growth?

Wednesday, August 3, 2011

Elevator definition and value

I recently chatted with a scrum coach, and he gave me a challenge: Say you were introducing scrum to an organization, and you had just finished a great discussion on the basics of scrum. You're feeling pretty good, and heading out for the day, when the executive who's spearheading the move to scrum catches up with you. "Great meeting," she says. "But I'm still a little confused about story points. Can you clarify that for me as we get to the parking lot?" So, you've got about a minute to re-define and establish the value behind this scrum term. What do you do?

Yikes. I had no reasonable answer. I've realized with that discussion that it's important to have quick soundbites available. What are some catchy ways to describe these items and behaviours that we in the agile world live and breath?