thekua.com@work

The Agile Coach, from A-Z released on InfoQ today.

Comments(0)

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.

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.

Comments(0)

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.

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.

Comments(0)

Definitely a post well overdue (think end of March), although I thought I’d still put it out. Four years at Thoughtworks for me has:

• Taken me to four countries (Australia, United Kingdom, India, Canada). Even more if you take into account conferences and other invites (Finland, Sweden, Norway, Italy, USA)
• Let me see eight different client organisations (from small to extremely large)
• Worked on seven different delivery projects

Picture taken from BFick’s photo stream under the Creative Commons Licence.

• Advised on two pure consulting engagements
• Presented and participated at five different global conferences
• Participated in five different internal conferences
• Seen me focus on two main programming languages and platforms (Java and .Net)
• Broaden my experience as a developer, technical lead, analyst, agile coach, full time trainer, and facilitator.

There’s been plenty of happy moments, sad moments, lots of learning, lots of growth, and plenty of insight balanced with plenty of humility (in that there is still so much to learn).

Comments(4)

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:

• Posters 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 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).

Comments(0)

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.
• User 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?”

Comments(0)

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.

Comments(0)

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.

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.

Comments(0)

One of the things that constantly surprises me about facilitating retrospectives is about the energy that a well run session can result in. For most heartbeat retrospectives, I feel it’s not normally that useful to write up a comprehensive report, as the team should feel ownership of the action items.

An important aspect to the role of the facilitator, is to do as much as they can to sustain the energy of the group and to tap into everyone’s capacity for embracing and dealing with change. Helping people contribute their story to the retrospective helps. Letting people tell their story in full helps. Facilitating difficult conversations towards a non destructive outcome helps. Moving the team towards specific, tangible actions or concrete lessons learns helps.

After the retrospective, I’ve always wondered what responsibility the facilitator has for ensuring change. My conclusion is that, in reality if they are truly independent, it’s none. Of course, the facilitator may care (and I can assure you I do) about following through on the change, yet all the systemic forces that push for and against change tend to be out of the influence of a truly independent facilitator.

In short, retrospectives are agents for change, yet ultimately it comes down to the empowered team to make sure the changes really happen. My advice to managers is to give teams responsibility and, with that, the decision making authority, to help them make the changes they need to.

Comments(7)

On Wednesday, a whole bunch of IT people descended on McNally Robinson’s bookstore in downtown Calgary to attend the signing of the Thoughtworks Anthology. On a usual week, we’re lucky enough to have two of the contributors in town and unfortunately, one of them, Ian Robinson ended up on a flight from the UK that could have almost taken him all the way to Australia (at least time wise). More fortunately, the other author, Stelios Pantazopoulos (my favourite picture of the night below) made it with plenty of time.

Although I regret being too busy to submit an article, at the time the book was being assembled, it makes me proud to look at the book now and see the breadth and depth of the ideas it contains, and to know that many of my other colleagues share the same level of passion and enthusiasm for really finding more effective ways for IT to work with the business to deliver greater results. It’s wonderful that they can also share this wisdom with the rest of the industry and everyone else benefits from it as well.

Comments(2)