Wednesday, March 20, 2013

Inspection and Adaptation

The least understood and most ill used ceremony in the Scrum toolset has got to be the Retrospective. More teams request to be excused from this exercise than any other, and most coaches, and some practitioners are always happy to oblige. It turns out that the humble Retro is absolutely the most powerful tool in the Scrum toolset, and more than any other tool can take you from one level of performance to the next – if you let it.

Most groups I work with are not teams at first, some because they are just starting and don’t understand what it is to be a team, some because they learn the "agile" vocabulary and immediately hide behind it. These types of "teams" are usually the ones that ask to be excused from the retro, and the main reason is that a great retro requires transparency, trust and vulnerability. And if you are stuck with a group of people you never took the time to understand, or worse yet, a group of people who refuse to be led by you – then that makes this exercise terrifying. More on the latter on a later blog post! But retros do tend to bring out uncomfortable topics, surface work patterns and deficiencies, and if you are doing them right – make YOU ask questions of YOURSELF. That last part is where the retro can help out the most, and also where the team can really get to know each other.

I have just transitioned out of a project, and am starting my own personal retrospective. Some of it is simple enough – I always ask others I worked with to sit down with me and let me know how they thought I did, and if I could have done something different. I always make it a point to ask this of different people in the project, those that liked what I did, those that disliked what I was doing strongly, and those that may have been challenged but saw a benefit to what I was doing. This usually gives me a set of patterns I can work with in order to better myself as a coach and consultant. The HARD part is looking at the feedback, reviewing the situations, admitting there were errors that I committed, and then trying to figure out how I could have done it differently. I tend to not get hung up on “good” or “bad” results per se, because this prevents me from a solid analysis. But I do see that some decisions and some teams had bigger challenges, or required more attention than others. This helps me with the second part.

One thing that makes this difficult for me is that most of my work is, well, in my brain. The way I approach coaching is to analyze the environment and teams, and given what I have to work with, try to optimize the whole to ensure a best possible result. This has worked relatively well for me, but it requires a constant analysis and a refactoring of in flight equations and a cheerleading and enforcing and all sort of thought work you can imagine. My brain is always going – so that sometimes I have to stop and just breathe. This is why I practice yoga. But in a stressful situation, it makes me go harder than I should, and makes the analysis more difficult afterwards.

With a team, the retro should allow you to see small enough challenges that are work related, and help the individuals and the team assess what happened in a safe environment that is conducive to individual and group growth. By focusing on the work of development and the constraints of the goals of the sprint, we should be able to be honest with each other, and come up with a simple action plan to allow us to better meet our goals, through a better understanding of ourselves for the next sprint. Simple, right? Except that…

In most organizations I work with, the environment is anything BUT safe. I get asked to come in and “change the culture”, usually by well meaning executives or sponsors that have at best a surface understanding of “Agile” and they want their teams to be “better and faster”. Some even try to actively change the environment to at least one of trust. But those of us who do this know that it takes more than just a week of not blaming anyone to build trust. And depending on how long you have been building your “pearl of shame and culpability” it may not be possible to get to a place of trust within a project timeframe. So when people like me come to a team after a challenging sprint, and ask them to be transparent and trust each other, and help one another get better – if I am in a deeply fear driven culture, I can expect no meaningful participation from the team members.

I am a pretty good cheerleader, people like me because I protect them (and just maybe I am a little bit good looking). So I have seen some teams actually take the risk at a retro, and actually start to get better. But in almost EVERY stress driven environment, I always get the requests for the “notes from the retro” by the well-intended management team. If we are in the environment above, this is a major failure. As a coach, I do take notes at Retro, they are usually hand written and only for the team. We review these notes and see if we changed what we needed to, address what needed to be addressed, and if we missed anything big or small. We also throw them away – so that they cannot be held against the team. Some people I greatly respect feel that an effective retro is only one that has action items that are documented and actionable. When I deal with environments like these, I consider an effective retro one that the team is willing to participate in, take a risk and start talking about themselves. I find that the underlying culture is a massive block, and usually the cornerstone of “we don’t really need this meeting, do we?”

Fortunately for me, I have worked with a few mature teams as well. It is a good thing to have these teams look at their own performance, hold each other (and me) accountable and actually request a retrospective. So they can review items that they felt could have gone better, or things they feel they needed to talk through, or any other number of items. It is refreshing to see mature teams working to better themselves, and without a fault, these teams tend to demand a retrospective, even if (especially when) time is tight. None of the retros for these teams tend to be complaining sessions, even when fault is to be found. The focus is team centered, and the retro tends to focus on the sprint that just occurred. I have worked with a few teams like this, and absolutely love to help them out.

As for me, with the thought stuff that is mushy and hard to track. Time and stress have just rang my bell – in a BIG way. I now have to start to change the way I see, engage and perform my work. Because if I don’t, well bad things will happen. I am now faced with not just assessing my work, and being vulnerable and truthful with me – now I really need to look at this and make an actionable plan that I intend to follow in order to get healthy. And if I want to continue coaching teams, and having fun with friends and family, and do my yoga and my fishing – I better get good at tracking my progress…

1 comment:

  1. I've always thought that if you can't name at least one thing that you've changed based on the last retrospective, then you're not doing scrum. Having a good productive retrospective is the single most important part of scrum.

    It's also the hardest part, which is why people like to skip it. It requires a lot of skills that people don't like to exercise.