thekua.com@work

Read the article from InfoQ here. It’s a great read and has inputs from many of the passionate community members in this area.

Comments(0)

I’m back from holidays, having been disconnected for the last ten days or so. I’ve finished uploading my holiday snaps (check them out here if you like) and checking all my emails so it’s time I got around to reflecting back on last year and what this new year may hold (even if it’s just that little bit late). I don’t do the whole New Year resolution thing although I try to revisit what goals I have.

In terms of conferences…

• I attended the Retrospective Facilitator’s Gathering held in Phoenix this year that continued to fuel my existing passion for one of, what I consider, one of the most effective agile practices. It’s helped me communicate even more with people about my passion for the tool, continued to refine my approach and understanding of the tool and helped others to see the value they add. It’s also put me in touch with a whole heap of other people that share this similar passion. I’m sometimes referred to as *the* retrospective guy in the UK office and even though I don’t agree with that statement (I don’t know everything there is to know about retrospectives, and I’m certainly not perfect at running them - I’m just passionate about them). I’ve even helped to organise this year’s gathering.
• I helped Tom Sulston out with his workshop, The Daily CI and I ran my Reface Your Team Space session at XP2007 in Como, Italy. Though I enjoyed the two sessions, I thought last year’s conference ran much smoother and had much better content than this year’s.

In terms of writing…

• I published my first article on InfoQ after writing a series of blog entries on Onboarding Strategies. I want to continue to add and refine these as I still think there’s important lessons here that I hear teams fail to do everyday.

In terms of opensource…

• Even though I’d contributed patches and bug fixes to some projects, last year I released my first real open source project, an API for printing to Zebra-branded printers written in .Net called Sharpzebra. I’ve hosted this project on Codeplex and I hope it eases someone else’s problems printing to this proprietary language.

In terms of growth and lessons learned…

• I’ve read much more on Lean and Theory of Constraints this year, and starting to feel like I have a better grasp of the concepts. Applying them in a practical fashion in terms of noticeably different practices is the much more difficult step I need to take next. For other people’s reference, read books like “The Goal”, “The Elegant Solution”, “The Toyota Way”, “Lean Thinking”, and “Toyota Talent”. I’m sure there’s much more to read as well.
• Only eight months after a disappointing situation, I finally made it to India to help conduct some training, giving me a full time focus on coaching, training and facilitation techniques. I also have to thank one of my fellow trainers, Rixt who’s been fantastic at helping me to be more aware of many other techniques and approaches that I then could practice and apply during the training sessions. I feel that the delivery methods for the course improved significantly over the three months the whole training team worked together on.
• This year I also first officially lead (at least from a technical point of view) an all TW team, and under fixed bid conditions, high expectations from the client and a very complicated domain with a few new people, delivered a very successful project to a very happy client. Reflecting on the experience, I extracted out many of the onboarding strategies I wrote about, and then applied it as the team almost doubled in size for the next release.
• I’m also very proud of the way, as a team, we handed the leadership over seamlessly to another person as I prepared to head to training. Transitioning the tech lead role is often executed haphazardly, leading to inconsistent visioning, confusion amongst the team and general chaos. I’m pleased that when I left the team, it was like they could work without me (which is a good place to be!)
• I stayed at the same client for most of the year, although ended up on two different projects - one of which I worked on the year before. Seeing the same project, or introducing new people to the same project months later taught me so many lessons about what decisions or approached work or don’t work taking a long term view of a project. I can’t recommend it enough to anyone to make sure they understand the consequences of the choices they make beyond their own time on the project.
• Tim Bacon (an alumni Thoughtworker and fellow agilist) introduced me to the Amplify Your Effectiveness crowd that seems to align strongly with members of the agile community. That, and the Getting Things Done crowd.
• I created two new retrospective exercises, one that I’ve blogged about called The Three Word Starter, and another I’m yet to blog about though I tried with a couple of teams in India.
• It’s not about what models you use, it’s about how you use them. This year, I’ve learned so many different models from so many different people, and although they appear trivial, watching people who really harness their energy constantly amazes me. I need to remind myself, it’s not about whether or not a tool is good - it’s how it’s used and how it’s applied.
• Doing the things you say is much more powerful than simply saying things. It demonstrates commitment, and belief in the things that you value and is often an effective way of leading change in teams. I’ve seen people say things and then do something completely else, confusing people to no end. Others simply say things and don’t do anything about it, making it less likely to occur.
• Effective feedback earlier is better than no feedback at all. It’s better than feedback too late to do anything to do with it. Of course, this takes energy yet it’s a very powerful thing if people respond to the feedback (it’s not always guaranteed). You can do at least your part by ensuring the feedback is timely, and well constructed.

Comments(0)

I’ve been looking for alternatives to the standard Create Safety (1-5) Exercise. I’ve found this sometimes fails me when you have new people to a team you’re facilitating a retrospective for. It’s hard to distinguish between “I’ll just smile, nod and agree everything is okay” because they have nothing to add, or they feel very uncomfortable because of things going on in the environment. I adapted this exercise from a coaching technique that a fellow trainer (JJ) suggested. I feel this exercise helps set the scene and mood of the group and gives the facilitator additional qualitative insights. I call it the Three Word Starter.

What it is: A way of gauging the general mood of the group using a qualitative technique.

Time needed: 10 minutes

What you need:

• 3 sticky notes per person
• A marker pen
• A place you can put them up

How to run it:

1. Ask each person to take 3 sticky notes each
2. Ask the group to consider how they’re feeling about the retrospective
3. Ask each person to write down a single word per sticky note. Remind them to avoid pictures or phrases if possible.
4. Collect them and post them up on the wall/chart/board (you have the option of doing this anonymously or asking them to do so)
5. Group words together (exact/common ones) and talk through general themes.

Tips for facilitating the 3-Word Starter

• Ensure everyone is made aware of the overall mood of the group. Depending on the size of the group, get everyone to read each other’s feelings or read them out to the group.
• If you see large themes of concern or indicators of low safety, address them directly by asking them to Check-In. Say something like “We recognise that the group is feeling a little bit [insert word or theme here]. I’d like to ask you to “check in” these feelings and be open to this discussion that aims to strengthen confidence and improves effective. It is an exercise for celebration and improvement. It’s not about blame or criticism. At the end of the session you are welcome to “check out” these feelings again”.

Variants
As the group size diminishes think about increasing the number of words per person. For a group of 15 people, I used a 3 word starter. For a group of 8 people, I used a 5-word starter. The aim is to get enough words to draw common themes, but not so many that it’s overwhelming.

Summarising
Group together words that are exactly the same, or have the same meaning. When I report back the results of the retrospective, I use a Text/Tag Cloud generator to help put common words together so you get a good feel of how the group is going. I’ve been very happy with the ones TagCrowd produces.

Comments(5)

Its Purpose?
Allows new team members an opportunity to express their discomforts, concerns and puzzles about the project in a constructive environment. This strategy focuses on explaining the circumstances or reasoning of decisions and to come up with new approaches and suggestions for improving any identified problems.

Image taken from AZAdam’s flickr stream under the Creative Commons Licence.

How Did We Execute It?
I ran this session with the entire technical team. I asked them to think about things that they had questions about, or things that had been troubling them on the project. I asked for them to write each of those items on a sticky note and let them put them all over a whiteboard.

We talked about each item, trying to understand what problem they caused. We talked around some of the drivers and decisions that might have lead to each of these items and alternatives that had been tried or considered. We also highlighted some as known problems and where to find more about what we’d acknowledged about them. I asked everyone to use three votes to help prioritise which items we should talk about.

For each of those items, we talked around the current circumstance and to help understand current forces at play. We also talked around attempts that we’d made to help address them (if any) and where we’d failed and learned from them.

As the final step, we brainstormed on a number of activities we could try out to improve them (attempting to be as specific as possible). Our final board looked like the following:

Why Is It Important?
The newest people to the project have the freshest eyes to see things that aren’t obvious enough. They lack prior context and don’t necessarily understand why the team made certain decisions or design choices. It’s a bad sign if they can’t work it out for themselves very quickly as it implies code is not well refactored enough or they cannot access the right information.

After being on a project long enough, new people who can’t understand these strange peculiarities assume the existing team made foolish or unwise decisions. These assumptions sometimes manifest themselves very strongly in the way they act, and the way they say things. I’ve found they range from something like “Why would you even consider that?” to “What idiot made this decision?” Understandably, the incumbent team no longer wants to listen to the important message behind the new person’s concerns and they no longer attempt to improve the situation.

Creating a safe environment to “air grievances” allows new people to highlight potentially problematic issues, or demonstrate the lack of clarity without focusing on who caused it, or whether or not it was the correct decision. What’s done is done. Instead the team now works together to improve the situation instead of focusing on blame.

I feel it’s still very important during these sessions to cover why decisions were made as some of those factors might still be in play and influence the direction of any solutions developed during this session.

What I Might Try Next Time
If I had lots of people joining incrementally, running this session continuously might not be as beneficial for the entire group, so I might run it individually with new participants. I would also use this strategy even out of the context of on boarding, as I ran it semi-intentionally as a technical retrospective (without calling it as such).

Comments(1)

One of the benefits of working in our Bangalore office the unique concentration of people in one location on a daily basis, resulting with some very interesting conversations. On Tuesday I hosted a retrospective facilitators meetup with a pretty open agenda. We had people from all parts of the organisation. I was asked by one person who couldn’t attend to write up the things we covered and some of the topics.

I felt we had some nice discussions, and thankfully not all of it coming from one direction (i.e. me). Here’s a quick recap of some of the topics and things we covered. I’m sure I’ve missed plenty of other side conversations (it was only an hour too!), so if you were there and you’re reading this, remind me via email or a comment here. Next time I’ll try to write the topics down so we capture some of the discussions. Here’s at least what my (terrible) memory holds:

Is it okay to give feedback to individuals during a retrospective?
Asked from the context of trying to give people feedback that strengthens confidence, I think many people in the room felt it would be appropriate. Others gave examples of these comments coming in from things that went well as well as describing the Offer Appreciations exercise (see the Project Retrospectives or Agile Retrospectives book). I’ve also seen these work quiet well.

What goes into a retrospective
We covered this pretty quickly since the room was a mix of experienced and inexperienced participants/facilitators. I quickly ran through a format that is most used:
1. Set the scene - Make it clear to participants why they’re there and what you’re trying to do.
2. Create safety - Ensure that all participants are going to participate
3. Gather feedback - Use some activity to generate some data and insights.
4. Actions - As a group, decide upon results or things to action upon

What happens if the same things keep coming up?
Part of it indicates to me a process smell that I’ve written about before. Some useful techniques to address this include Bas’ Plan of Action pattern. I encourage everyone to also focus on creating actions that fit the SMART (Specific, Measurable, Achievable, Relevant, Time boxed) criteria and ensure that you celebrate small successes so everyone feels like progress is occurring. I also tried emphasising that at least retrospectives are still bringing visibility to the issues, and that it sounds like the actions or things happening around it need to be addressed, not to stop running tools that give you feedback.

Alternative Exercises
A common exercise people in Thoughtworks use is What Went Well/What Went Less Well/Puzzles. I’ve had conversations with some people (not in this particular meeting) who believe that unless you’re doing this one, then you’re not doing Retrospectives. I showed a couple of alternative exercise ones including the Retrospective Starfish, the Art Gallery one, the Forcefield one (with its speedboat/air balloon variations).

What’s the perfect size of a retrospective
I honestly didn’t have an answer for this one other than “it depends”. The group talked about as you increase the number of people, the more time you need and individuals end up participating. We also side lined for a while on what happens if you keep Prioritising with Dots and not really getting the smaller issues out. Others came up with sometimes not running Prioritising with Dots and getting everyone to brainstorm action items that the team simply just took on automatically. Quick wins become reality in a flash this way.

Retrospectives are a process smell
I can’t remember who, but someone talked about having retrospectives themselves are a smell, in that an “ideal” team should be self healing and fixing problems continuously without needing them. In one way, I agreed with him as did several other people. On the other hand, in my experience sometimes even a well performing team needs that separate time to reflect on things independently of the other things they’re focused on doing day-to-day. One person chimed in saying that in a way, the issues coming out the retrospectives gave them confidence that they were already dealing with the issues (as in, there wasn’t any surprises). I also tried to explain several other side benefits such as a common place to share a story that might be missed, a place where people are safer giving some feedback, and a place where everyone has input into agreeing to a solution.

Comments(3)

As a facilitator and a participant of teams leveraging agile practices, regular, heartbeat retrospectives become an essential part of the team’s toolkit. Doing retrospectives so continuously inevitably leads to some repetition, and on some occasions team members seem to find it boring. I’m sure there’s plenty of reasons why someone might find it boring. I believe one of those reasons is that perhaps no important issues are being brought up, to which I would respond by scaling back the frequency of the retrospective - so say, holding one every two weeks instead of every one.

On the other hand, some people find the standard format of What Went Well, What Didn’t Go So Well (and sometimes Puzzles) too monotonous for their tastes. Even as a facilitator, I admittedly find repeating the same exercise slightly boring.

Luckily the Agile Retrospectives book offers a plenty of options you can implement and still achieve the same outcomes. I think it’s important to ask different questions, and also use different formats. Sometimes asking a different question exposes a set of very different answers from what you’d expect. Using different formats, especially those that are highly visual (symbols, graphics, colours, charts, etc) is enough of a subtle change to keep people interested and excited.

Comments(1)

This is the corollary to the previous “All Talk and No Action” post.

I remember talking to two different facilitators about the way they run retrospectives. Facilitator A said “I don’t care too much about getting to action items”, implying that they wanted the people to discuss their problems. In contrast, Facilitator B said, “Why would you run a retrospective without any actions?”. I saw both sides of the argument, but also saw danger in both extremes. In the last post, I wrote about what happens if you only ever run retrospectives without ever changing it.

What would happen if you ran retrospectives only focused on action items?

Context is never shared
Running a retrospective gives some people a forum to be heard. Sometimes people need to get things off their chest, and need to be fully heard by all parties (keeping in mind it’s under the Retrospective Prime Directive). Regardless of whether an action item is created or not, some people may feel resentful if they don’t get a chance to tell their side of the story. By sharing a story, the team is also more likely to relate to the other person’s problem.

The wrong problem is solved
Often I hear people propose solutions in retrospectives without explaining what it’s trying to solve. Only by drilling into the issue further, do you sometimes uncover a very different problem. To this root problem, others may propose a better solution that is more effective, or works better for the entire team. Jumping to actions without discussing what you’re trying to fix often results in a poor solution, and often one to the wrong problem.

Teams lose a shared understanding
I’ve been in one retrospective where a team member only saw the result of the action items and never heard the discussions around it. They felt very resentful over a number of the action items, both because they felt left out and couldn’t see why they were needed. After the retrospective, we revisited the items and the reasons they came about to give them a better context but I don’t think it had the same impact if they had been there during the discussions.

What you can do about it.

Understand the the retrospective is simply a tool, so truly understand what you’re trying to achieve with it and facilitate it accordingly. Use a different set of activities to achieve your specific goals, and ensure you balance the needs of the group to make progress and the needs of the group to talk about the issues at hand.

Comments(0)

You miss the valuable things that other people have to say. Listen, reflect, and then comment. Not before.

Comments(0)

I’ve talked with a number of people who dislike retrospectives, and I feel a common reason they dislike them is that they feel that things don’t change. It’s all very well talking about problems, like what occurred and why, however when they come up with solutions, they still keep finding the same things coming up over and over again.

I, and several facilitators I’ve talked to, have many good reasons for holding retrospectives without being excessively focused on action items as it can be a useful place for different members of the team to better relate to each other’s problems and understand each other’s situations. On the other hand, you want to avoid creating situations where they feel they can’t work on their problems or they are not making progress.

Regardless of whether or not problems persist, I feel retrospectives still serve as a useful tool for highlighting these problems. Like Information Radiators, they are simply showing you where pain points lie. They don’t automatically make them go away.

The question I ask people about these situations is “What did the team do to make the problems go away?”, and “How did they approach fixing their own problems?”. I’ve seen a few retrospectives where the actions involve people outside of the retrospective, and committing them to changing external environments.

Some useful techniques for dealing with this include Bas’s Planning for Action, or by creating and ensuring that better action items are created. Perhaps they’re too big and they never get done, or perhaps action items are too general for them to be really executable. Creating action items that the team have no control over, and involve people not present in the retrospective are generally never realised. Focusing on smaller, more specific action items that the team actually has an ability to influence ensures that at least incremental progress is made and sometimes that’s enough.

Comments(2)

I participated in one retrospective run by a contract Project Manager whose style was to stand in front of the group, and ask individuals one by one for a single idea for a “What Went Well”, “What Went Less Well” wall. I felt horrified as I saw each person uncomfortably offer a very brief statement, or in general, skip their turn and all with little discussion around it.

I look back at that situation and guess that it wouldn’t have been so bad if the team already had trust and confidence in the facilitator, but it was obvious from my perspective, based on the lack of interaction and productive conversations, this retrospective offered little value.

Strategies that I would employ (and some that I did) to improve the situation include using an independent facilitator (with no vested interest) to run the retrospective, collate input using sticky-notes to improve anonymity and efficiency, and to spend more time, drawing out the story behind the items to identify any common root causes.

Comments(0)