The intersection of technology and leadership

Category: Coaching (Page 7 of 11)

When Retrospectives Go Wrong: Poorly Formed Action Items

How you facilitate a retrospective impacts the success for a retrospective. Inexperienced facilitators often don’t know how best to achieve the Decide What to Do part of a retrospective, often resulting in action items too broad, or too difficult to actually achieve. Revisiting them next time results in frustration as the team hasn’t made any progress on them.

Failed Pottery

Photo taken from Opheliates Flickr stream under the Creative Commons Licence

What you can do about it?
Sumeet writes about using SMART (Specific, Measureable, Achievable, Relevant and Timeboxed) to help focus forming better action items. He also writes about giving them an owner and a time frame. I will often use this to guide the discussion – “Is this achievable in two weeks time? How can we break this down to ensure we make some progress? Does everyone understand what you need to do to call this item complete?”

I also like Bas’ Plan of Action approach, linking short term actions with long term goals – allowing people to break down large changes into more achievable ones, or to help align short term tasks with longer, more strategic goals.

As a facilitator, be aware that how you deal with the last part of the retrospective will influence the result, for better or worse. Learn how to facilitate the group towards something more likely to result in an observable change.

When Retrospectives Go Wrong: The Faciliator Did Not Prepare

Ever been in a meeting where the organiser doesn’t really know why they brought everyone together, or even have an agenda to start with? It devalues your time and you feel pretty frustrated. I’ve seen the same happen when facilitators don’t prepare for their retrospective. Preparing well demonstrates to participants respect for their time. Conversely a clear lack of preparation shows disrespect. Even though it doesn’t guarantee it, proper preparation ensures a better chance participants will be more willing to engage.

Surprise

Image taken from Meredith Farmer’s Flickr photo stream under the Creative Commons licence.

What to do about it?
In preparing for the retrospective, I like to go through this list of questions:

  • Who is the sponsor for the retrospective? – Sponsors may have extremely different agenda. Some of it may be about spreading lessons learned, others just want to understand the root cause of some major problem. You want to be clear about who the sponsor is and why you’re even running a retrospective. Is there just one person, or are there more of them?
  • What are their goals, and what are you going to end up by the end of it? – Looking for ways to improve client relationships will have a completely different focus than understanding what new technical innovations came out of the project. The goals will heavily influence what exercises you plan for.
  • Do you know how long the retrospective will be looking back? – Planning to look back over 1 week will be different from 3 months and different again from 1 year.
  • Do you have an idea about what topics might come up? – A retrospective for a project where significant negative events dragged the team at certain stages will be different from a retrospective for a project that had less troublesome issues.
  • Have you planned for enough time to cover everything? – You want to have enough time for people to tell their stories, unload any emotional baggage and get to understand what lessons are worth sharing.
  • Do you have a good representation from team members? – Just having development members in a retrospective will skew what you talk about, perhaps missing important elements all the way from the sale, client relations, etc.

Just before starting the retrospective, also ensure that you have all the materials prepared – this may includes markers, pens, paper, sticky notes, handouts. Also ensure you have the room prepared with any posters or whiteboards you plan on using.

Agile Principles Applied to Training: Transparency and Information Radiation

One thing I’ve noticed agile projects tend to do is to push relevant information out to people, and be extremely honest about how things are going. Here are my attempts at doing so:

  • Training PosterPosters Around the Workplace – Finding time to showcase progress to my stakeholders is like trying to hold a wriggling eel in water, so I thought of hanging some eye catching posters on the noticeboards. I decided they’d be good for two purposes – the first to help give stakeholders an idea of what I’ve been doing with training since we met about a month ago without the need of scheduling another meeting, and the second, to market towards potential people who’d have an interest in attending. In about an hour, I ended up with a poster (see the photo) that included what topics I have material for (and what I have planned), photos of outputs from the training including snippets of real feedback, and contact information for more information. I purposely left two spaces to update the colour poster with two pieces of information, just the right size for sticky notes. I’m currently filling one indicating the number of people who’ve participated so far, and the other, the number of classes I’ve run.
  • Mini Card WallMini Card Wall – Keeping track of all the tasks associated with material development, scheduling training, meeting with people is becoming difficult so I’ve put up a mini card wall using the desktop PC I have next to my monitor. People around me can take a look at the things that I need to do, and as new requests pop up, I can quickly add it to the list of items still open using the pen and pad of sticky notes I have nearby. As you can see from the picture, all I really care about is whether or not something is open (needs my attention eventually), in progress (reminds me of what I’m working on) and done (I remove these at the end of the day).

Agile Principles Applied to Training: Building in Quality and Continuous Improvement

In my experience, achieving high quality is a key part to being adaptive and nimble. Continuous improvement and responding to the feedback allows you to achieve high quality. Here’s what I’ve applied to training so far:

  • Set design and collaborating ideas – One approach I could have taken to developing the material included simply writing the content, trainer’s guide, handouts, etc and run it with a single class before trying to change anything. Instead, I came up with a few options, bouncing ideas off someone else who’d run training before and asked them, “I’m thinking of trying something like like …, I imagine it would work like … and we’d achieve … What do you think? What discussion would this generate? Would people find it engaging?” It stopped me detailing things too early and putting in too much effort that would need rework.
  • Worksheet EvolutionUser Centred Design – For some of the worksheets, I applied some principles from Don’t Make Me Think, testing them out with some users to make sure they needed as little instructions as possible. It’s important for students to have a good experience with everything to do with the course. You can see the evolution by looking at the picture above – it’s a worksheet for introducing the concept of velocity for the XP Lego Game.
  • Finding the right metrics to use – I’ve already changed my feedback forms since running the pilot programs, looking at what information I actually consume and how people use it. I used to have a two-page feedback form, the first including instructions and a focus on multiple choice answers, with the second page using a more free form format. Since I hand them out in class, I give verbal instructions and removed the detail blurb I had at the top. I also condensed the form into a single page, and focused on three key questions I am more interested in – “What did you like best about the session? What constructive changes would you suggest to make the session more effective? What else do you want to know about?”

Agile Principles Applied to Training: Building in Feedback Cycles

I’ve been leveraging my experience with agile in teams and development and applying it to what I’ve been doing in training. Here’s what it looks like:

  • Review material before class – Executing the material with an audience is the slowest part of my feedback loop. Instead, I’ve had a few people review different parts of the material during and after I’d developed the material, constantly seeking people who might give a different perspective about the content, delivery techniques, etc. Some of them involved a detailed walk through, others a brief, what do you think response?
  • Gathering feedback from classes – I’ve had a chance to run some pilot classes, gathering effective feedback to consider changes. I also try to set some time aside after class, capturing notes around how effective I thought some of the classes ran, looking at ways of improving them.
  • Eating my own dog food – The trainer’s guide is meant for someone else, and as difficult as I find it is, following a guide you wrote, I try using it to plan out the classes I run to see how well documented it is.

Behaviours of a Tech Lead

In the spirit of Goldratt’s understanding of metrics, “Tell me how you are going to measure me and I will tell you how I will behave,” here are some questions I ask myself when I play the role of a Technical Lead.

Einstein

Picture of Einstein figurine taken from Dunechaser’s Flickr stream under the Creative Commons Licence.

  • Have I fostered a learning environment? Do people feel safe to make mistakes, and more importantly, learn from them and share them with the rest of the team?
  • Have I fostered an attitude of continuous improvement? Can people talk openly about what they see on the project, determine what impact it has or how people feel about it, and encourage more of it (if it’s a good thing) or try something different (if it’s less than ideal). Do people feel empowered to do things without feeling like they need authorisation every step of the way.
  • Does the development team collaborate well with the other parts? Do they talk to other people with respect, and do they try to involve them as much as possible where it makes sense?
  • Does the development team balance the needs of the business with the demands of the technology and toolset? Are they doing what’s right for the business in the long term? Do they share the same vision?
  • Do I act as I say? Even though this sounds obvious, I’ve seen many people fail at this and, as a result, the non-verbal cues that conflict with verbal cues and confuse the team.

And of course, this resource is a useful one too.

When Retrospectives Go Wrong: Controlling the conversation

One of the most important points that Kerth, Larsen and Derby emphasise in their books is that the facilitator should not have an interest in the conversation. As I heard someone once say most succinctly, “If you have a point of view to share, you should not be facilitating”. This particular bad smell typically happens when this rule is violated. I’ve first hand seen this the most when a person in a naturally authoritative position (think project manager, technical or team lead) facilitates.

I remember sitting in one retrospective where the facilitator (a project manager) ran the retrospective pointing at people asking them for a single item (what went well/less well). They would often literally drill the person, asking for more details, and often commenting on their input, saying things like “that’s a pretty stupid idea”, or “you really should’ve done … instead of …” before turning around and writing it up on a flip chart. When they had finished, they decided which topics they wanted to talk about further, then returning to the group without even involving them in the decision making process. I sat, aghast, silently observing as people uncomfortably shifted in their seats wanting to get their stories out in the open yet afraid it wouldn’t go anywhere productive, and worse, be judged for it.

The result… an empty ritual, empowering a single individual, and the only outcome of no beneficial change.

Crowd Control

The above image comes from Misschelle’s Flickr stream under the Creative Common’s licence

What to do about it?
The first step is to get an independent Retrospective Facilitator. Try really hard to get one. I know that finding facilitators are easy, and finding a retrospective facilitator may be more difficult though I’m sure you’ll find the results will be much better.

If you can’t find one and you’re the one facilitating, focus on the process, and less about the content. Your goal should be to ensure everyone has an opportunity to build the shared story, everyone has an opportunity to add their insights and everyone has input into the final solution. Do not push for the solution you think is best, and do not ignore people when they have something to say. Make it clear when you are expressing an opinion as a person-with-a-stake. Empower the group with a mechanism that gives you feedback when they feel you are directing the conversation too much. Believe me, it’s hard but it’s definitely worth it.

And what about the previous situation? Continue reading

When Retrospectives Go Wrong: Conflict of Interests

I heard one story recently from a colleague where a technical lead facilitated the retrospective. They’d collected sticky notes from everyone, placed them around an exercise at the front and began reading them out. The strange thing is that they read only the ones they wanted to read out, blatantly skipping many of the others.

Why the lead would only read out the ones they did, I don’t know. Perhaps they thought they were the most important (based on their point of view), perhaps they were a random selection. I’m not sure. It’s clear what impact it had on the participants. People became frustrated that they weren’t being listened to, didn’t feel appreciated for their input, and I’m sure many of them felt the activity a waste of time. Apparently it broke down to the point where they started shouting out for the lead to read out the notes.

Tug of War

Image taken from TimmyGUNZ’s Flickr photo stream under the Creative Commons licence.

What to do about it?
Kerth emphasises getting an independent facilitator (though versed in the industry) to run your retrospective. From experience I know this to be difficult for heartbeat retrospectives. If so, people who have direct significant influence (i.e. typically project managers, technical or team leads) either shouldn’t facilitate, or be extremely aware of this conflict of interests and do something about it.

I’ve learned it’s important to be clear which, of your roles, you represent when you say something. Something like, “With my technical lead hat on, I’m wary of this suggestion because of …” Another technique is to accept you will be biased and ask the group to raise a flag you when they don’t feel you’re being neutral. If you see the flag, you must do something about it.

Concluding Thoughts
Facilitation is not for everyone. Participants and facilitators should understand where conflicts of interest lie and how it may affect some of the conversations. Mitigate for this by planning to have an independent facilitator or by putting another system in place to prevent these biases creeping in.

Why XP is the most popular agile methodology

XP, like many of its waterfall breathen makes it easy to follow. It caters to those people in the Shu phase of learning. It’s easy to follow and it’s easy to get wrong without guidance. It provides a set of values and principles as well as a set of practices to help you achieve them. It’s probably less useful for people in the Ha or the Ri phases of learning.

I don’t want to criticise XP since there’s plenty of material already out there about for that. Rather, I want people to understand where it fits in. I thank the XP community for showing us how practices help to bridge the gap between principles and values as well as showing us that simply focusing on practices (or one approach) proves limiting. I also want to emphasise that XP’s practices aren’t the only way of doing this. The fact that XP works for beginners is both its strength and weakness.

As an agile coach, I often use different sets of practices to help bridge people into the other phases that brings more awareness and thought into everday processes. After all, part of respecting people is understanding each of their specific needs.

The Extended Agile Reading List

Update (20 Feb): I probably want to add the same disclaimer that I did on the previous post. I highly recommend doing reading on these things and I do want to emphasis that reading will only get you so far, so try to find someone who’s worked with in this way before (i.e. an agile coach) to help you apply all these concepts appropriately.

Building upon the Essential Agile Reading List, here’s the extended one that includes either books that I’ve not read (and have been recommended) or those that help facilitate further understanding or more advanced practices.

Methodologies and principles

Additional context

Teamwork

Continuous Improvement

Project Management

Requirements and planning

Development practices

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders NorenUp ↑