Viewing entries tagged
risk taking

Just a little…Forgiveness

Comment

Just a little…Forgiveness

I was attending the STPCon conference in Washington, DC last week (week of September 25). As always, there were quite a lot of old friends there. Folks I usually only meet on the conference circuit.

The conference committee tried a Lightning Talk format for the first time. They invited 7-8 speakers on stage to give 5-minute, focused talks. Dot Graham gave one that is still sticking with me.

She focused on creating (fostering, inviting, inspiring, allowing) a mistake culture. One where everyone focused on two aspects of their mistakes:

  • Learning from them, and
  • Forgiving themselves for them.

I’ve heard the learning part many times before. But this is the first time that I’ve heard “forgiveness” mentioned as part of creating a learning culture and it struck me.

In a team environment mistakes always happen. Sometimes they’re small things. And other time, they’re large ones which have an impact on the entire team.

I have a saying that I often share in my coaching and teaching. I amplify that agile teams (all teams really) succeed and fail as a team. That is, we don’t throw anyone under the bus, but we deal with everything from the solidarity of a WHOLE TEAM perspective.

I now want to add other attributes to that description:

  • We reflect as a team;
  • We learn as a team;
  • We make mistakes as a team;
  • And we forgive ourselves as a team.

I love the Norm Kerth sentiments regarding the Prime Directive for retrospectives where he sets the stage for the “intentions” of all attendees.

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

I think this sentiment helps us in our view towards mistakes and our forgiving each other (including ourselves) for making those mistakes.

I know that I for one can be really hard on myself when confronting the things I’ve done wrong.

As Dot reminded me, I want to encourage all of you in your agile journeys to be kind and forgiving of one another. Remember, they are ONLY mistakes and we all make them!

Stay agile my friends,

Bob.

Comment

Fail NOW as a Strategy

Fail NOW as a Strategy

I was at a conference not that long ago speaking and sharing on various agile topics. As often happens, a young man stopped me to ask a few questions after one of my presentations. We struck up a nice conversation that eventually slipped out into the hotel corridors.

We started talking about sprint dynamics within Scrum teams and I happened to mention that I usually coach teams towards declaring their sprints a success…or (pause for meaningful effect) …a failure. That we do this as part of the teams’ Sprint Review, with the Product Owner being the final determinant based on whether the team achieved their Sprint Goal(s).

Comment

The Agile Project Manager—Fostering Controlled Chaos

As you may or may not know, I’m an active agile coach. I often get asked to enter new teams and jump-start them or assess their overall level of agile-ness. One of the ‘smells’ that I look for in a strong and healthy agile team is what I’ll call controlled chaos or perhaps a better phrase would be guided chaos.

You see, the atmosphere in these teams isn’t safe nor predicted too far in advance. The teams don’t have a false sense of security. They’re working on a short list of features in close collaboration with their Product Owner. They know that challenges will rise up to meet them. Risks will fire. Team members will get sick or get married or tend to ill parents. And the design approaches and code won’t always work as advertised.

Comment

Comment

The Agile Project Manager—Getting out of Jail Free

I was teaching a class just a few weeks ago. It was focused on agile basics, user story writing & backlogs, sprint planning and all of the basic operations to kick-off a set of Scrum teams. It was going quite well on the first day and I was fielding the myriad of questions that typically come your way in an initial class of this sort.

Then I got hit with a question that I struggled to effectively communicate a succinct and direct answer to. The question was simple on the surface:

If within a sprint the team can’t seem to get the work they planned done, don’t you simply put it back on the backlog for execution in the next sprint?

Comment