Friday, June 12, 2009

my favorite lines from Derby/Larsen's Agile Retrospectives

A retrospective needs to happen in several phases:
  • setting the stage (why are we here, time line, and check-in)
  • data collection (put all the facts in front of the whole team)
  • interpretation (as a group, look for patterns)
  • decisions (propose options, then decide on what can be done by whom, when, and define acceptance criteria for the work)
  • closure (ensure tasks have been assigned, thank participants)
The authors have lots of hints on how to facilitate group discussion (now we'll see if I can do all this in French):
  • ask the group to build working agreements, and then just remind them to follow their own rules when necessary
  • at every meeting, get every person to speak in the first 5 minutes
  • check your assumptions... ask people what they think! pose clarifying questions to make sure you understand!
  • to help everyone have a voice, incorporate small group work in the meeting
  • retrospectives are for creative thinking--so do use innovative meeting formats
  • when the facilitator speaks, this often stops group discussion
  • when the group is stuck, ask them questions, e.g. about when they saw a similar problem in the past
  • when things get heated, try asking "what is going on?/what just happened?"
  • use a change in venue when the team bombs an iteration
They also present lots of group exercises, that I won't repeat here... I keep the book handy for retrospective preparation. These are a few general hints for leading group activities:
  • most people can't absorb multi-step instructions
  • debrief every activity
  • after giving instructions, ask for questions
  • shuffle time--it takes a few minutes every time we switch tasks in a meeting to get everyone on board with the next meeting--it could be 15 percent of the time!

Tuesday, June 9, 2009

tour de témis (taay-mees)

To promote shared vision in a team, to anticipate or ease over problems, and to help individuals deal with stress, I set a goal to spend at least 10 minutes in conversation with each team member every week. In practice, sometimes I only average 5 minutes, but I start out with something like the following.

Hey, Joe, wanna take a tour de témis? Joe may not be available, but if so, we step out of the team room and find somewhere quiet--outside or inside depending on the weather and mood. Then I'll ask one of the following questions, and record responses on an index card:

What are the strong points/weak points in the team?
What do you think about how we've been using timeboxing for meetings this week?
What will you do next week to help us finish the iteration by Thursday afternoon (instead of our normal Friday)? Do you think it's a good idea to finish early?

Then I use Appreciative Inquiry to dig deeper into what is going on with each team member.

story observer

The "story observer" role is something new to me--maybe only exists in my current team--but anyway, at least once a day this person walks around the room to remind pairs to consider whether they're blocked, ensures they're clear about the goal of the end-user, and asks whether they're still in scope of the story card. This observer, I suspect, is not necessary in a gelled/disciplined team, but in the early stages of forming, I think it can be helpful.

fixed-cost vs fixed-scope stories

When I first joined my current team, the team culture was that a story card's scope was non-negotiable. In accordance with the classic tradeoff triangle (scope-time-cost), that means they were constantly exceeding the story card estimates. I slowly distinguished between two types of ways of looking at a card, and I learned something in the process.

Fixed-scope: We understand the end-user's need, and we'll spend however much time it takes to meet that need. In this case, we value a well thought-out solution over feedback--so we should choose this only when end-user needs are well understood. The end-result of this process is a story card that is done-done, and the subject will likely not be revisited.

Fixed-cost: We understand the end-user's need, but the schedule is more important than functionality. We'll cut out features, robustness, or complexity so that we can deliver something that at least partially satisfies the end-user's need. As a by-product of this process, we'll write new story cards for everything that we temporarily cast aside. In this case, we value timely feedback from the timebox over completeness--so we should choose this option when we're unsure of the best solution or when doing research.

Pomodoro your way through Tuckman's FSNP model

As I mentioned previously, Agile can't be done without a performing team (Tuckman's Forming, Storming, Norming and Performing model), and I think this explains why I've been having so much difficulty getting our team to be more productive. We're more a loosely-coupled group of two-and-three person teams, each with different work styles and objectives. I've been working on bringing us together for 8 months now, and I've tried a few things. To clarify, when I say I, it really does mean we. That is, usually when I see something I don't understand, I go to another team member to find out if I'm the only one who saw it or not, and to find out if it's a problem. Often I work directly with my manager (Olivier) to get a feeling of the value/impact of the problem. Other times I work through the team, by asking the group a question during stand-up or a retrospective, or by speaking to people individually. Through this process, my original take on the situation is inevitably enhanced, and ultimately we build a new vision on how some of our work will be done.
The first thing I tried was to use retrospectives to find real pain points in the team... but not everyone agreed on what the highest priority items were. Then I tried using positive reinforcement of goals that I'd chosen. I wish I could say we chose these goals but there was no common consensus, so these goals were usually the collaborative output of Olivier and I, or the output of several team members... but for simplicity's sake I'm saying that I worked for the following. Please note that most of these changes were introduced to the team one at a time, and allowed to become habitual before moving on to the next item:

None of this really created a gelled team, in fact much of it was probably just a distraction from our real problem (at least from my current perspective). It probably wasn't a waste, since these changes have become a valued part of our daily work, and have also helped to establish a level of trust in the work I'm doing. Still, this more effective group work didn't translate into a performing team. Why?
I felt like if I could get everyone to see and focus on one single problem simultaneously, that would become the shared vision that defines a performing team. I concluded that I needed to construct an unambiguous definition of success... which, again, I pushed for. I believe it would have been more effective to have the team define this success, but I couldn't get the group to agree on one goal. So, I said that an iteration was not a success if we hadn't moved all the story cards over to the DONE column by the end of the iteration. I shared this vision consistently and regularly at stand-ups, my turn as story-observer, at retrospectives, and with my pair. Slowly the team adopted this vision... slowly means it took 10 weeks! Since then, however, there's been clear consensus on whether an iteration is done or not... yet that didn't make a gelled, performing team! Now what?
I needed more information, more ideas. So I started doing one-on-one interviews with every person (12 total) in the team, every week. That's been effective at understanding how people feel, and in making other types of changes (like finishing our iteration before 8pm Friday nights... now we're done Thursday afternoon or Friday morning). So with these interviews, I discovered I wasn't alone in feeling like we weren't a gelled team... people wanted closer cooperation, stronger teamwork, but we just didn't know how to get there.
As I said before, XP Day France was a great opportunity for me. I now know we need to get through forming, and I figured that if I shorten the cadence, we'd learn quicker, we'd have more pressure, and communicate more... all setting up fertile ground for team forming and agile growth. So I suggested we try the Pomodoro technique (as a team) last Thursday. Afterwards, we decided that the practice was too complicated to evaluate in just one day, and Olivier decided we should try it for an iteration. Well, that iteration began this Monday, and few people actually read the free 40-page book (hooray--some people are giving it an honest shot), but for the rest I've been using the first long pause of the day to explain the practice in more detail.
Everyone uses the same, 25 minute timebox. After each pomodoro, we pause, then have a mini-standup, where the sole objective is to find out how the team is going to attack the remaining story cards. If someone is blocked, we might send help to that pair; if someone has something interesting to share, they do; otherwise, we may resume the task we were on before. The object is to efficiently select the most important tasks that remain.

The breaks are ad-hoc, and may involve a team-building game, drawing on the white board, or a walk outside. This has become self-organizing already--different people propose games or set up the timers. Just to note, we play games that stimulate the creative, left-brain, so that when people go to sit back down they're more likely to see creative alternatives in the new pomodoro.

On a larger scale, the objective is to add so much discipline that we start to storm.

I'm hoping that before this month is over, our team will just be able to sense when a pair goes dark, will know when to swap pairs, will know how to focus on the core need inside a story, and will hum like a hive, producing a continuous flow of honey (err, business value).

Friday, June 5, 2009

Alan Cooper's Keynote speech at Agile 2008

I've just been reading Cooper's keynote address from Agile 2008, and have found several interesting insights. First, he argues that we shouldn't be iterative in the implementation stages of software development... we should be only incremental. I see the waste of being iterative at the implementation level, but I don't know how to validate software reliably without deploying to the customer... but that is where he says Interaction Designers come in. They know how to reliably define the customer needs, how to interpret discussions, and then to translate them into what the developers can understand. Hmmm...



Then he starts talking about some of their training, training I know I don't have. Interaction Designers learn about common reasoning flaws, like (the following is paraphrased from Cooper's slides 82 and 83):


  • Loss Aversion

  • Value Attribution (initial perception counts more than contradictory evidence later)

  • Commitment Bias

  • Pygmalion Effect (self-fulfilling prophecies)

  • Tyranny of small decisions (too much choice is paralyzing)

  • Evolutionary Psychology (we're not machines, and don't always act logically)

  • Abilene Syndrome (groups make choices that no one in the group even wanted)

  • Memory Distortion (bad things are easier to recall)

  • Hawthorn effect (just paying attention to people improves their performance)

  • Stockholm syndrome (hostages fall in love with captors)

Interaction designers are designed to distill "requirements" into a clear definition of business need. I can identify with this idea, as I've heard of teams that thrash from one set of whimsical story cards to the next. When I worked in Philly, we had a product owner who was also visionary, who strongly defended the vision against customer requests that were inconsistent with this vision. At my current position we've been saying that we need that vision to be more effective, but no one is playing the role.


Next he argues strongly for prototyping. He says a prototype is necessary for validating the design... and it should be built in a very agile, lean fashion. Then once it's done, rebuild the whole thing from the ground up... I thought that refactoring was supposed to avoid rebuilding to such a large extent. There's a lot to think about here.

before you can do Agile

Before you can do agile with a team, you need a team! At XP Day France last week, a colleague and I started talking shop with Yves Hanouille, who re-introduced Tuckman's model of team growth to us. I've been frustrated for a while, trying to figure out how to get us to follow our own rules, and even suggested throwing out all the rules and starting over. Now I think we need to get through Storming before any of these rules have meaning... You can probably find better info online, but these notes will help me remember the key goals of each phase :

Forming: agree on goals/vision as described by leader (team lead is directive at this stage). Members hold back their own opinions in order to be polite, they mostly work independently on tasks.

Storming: (directive leader) there's a lot of competition for ideas, the team begins to select a leadership model, and roles are clarified

Norming: (collaborative leader) members compensate for each other, agree on rules/standards, and hold each other accountable

Performing: (collaborative leader) interdependent individuals with established conflict resolution mechanisms.

A group in N or P will fall back to S under stress, in which case the team lead will need to be directive again.


So I think a team needs to be at either N or P to do agile. It's possible that at F or S the directive leader of the group will impose an agile process... but it won't be self-organizing!