patkua@work

The intersection of technology and leadership

Category: Coaching (Page 6 of 11)

Facilitation Tool – ORID

May 19, 2009 / / 2 Comments

Last year, Esther Derby and Jean Tabaka shared a model at the 2008 Retrospective Facilitator’s Gathering that I now think about all the time. Esther Derby and Diana Larsen used it as the base model to describe how to run retrospectives. It also got me thinking how it mirrored different models described by other facilitation approaches, negotiations strategies and advice on how to give effective feedback. Apparently this originated in the book, The Art of Focused Conversation.

The base model starts with the acronym ORID that means:

  • Objective – Focus on the facts, hard evidence data
  • Reflective – Focus on how that made people feel or other associations
  • Interpretive – Focus on the impact and significance
  • Decisive – Focus on next steps.

I thought it’d be useful to share this model with a wider audience, and I keep forgetting what the “I” specifically stood for, so I’m putting here so I can find it later.

More on how to apply this later.

Improving Collaboration Between Developers and Testers

April 30, 2009 / / 5 Comments

One of the biggest divides you need to cross, even on agile teams, is the chasm between testers and developers. By the nature of their different roles there will always be tension with developers focusing on creation, change, and construction, and testers focusing on breaking, destructive, and exposing questionable system behaviours. It’s essential that both organisations and, in particular, individuals realise what they can do to ensure this tension doesn’t dissolve into an exclusively confrontational relationship.

catdogfight

Photo taken from Sephiroty’s Flickr stream under the Creative Commons licence

Recently, a new QA person highlighted this very issue for me. I’d finished some functionality with my pair and the QA had been testing it after we declared it ready to test. They came along to my desk and said, “I’ve found some defects with your code.” Internally I winced as I noticed myself wanting to say, “There’s nothing wrong with my code.” It got me thinking about why.

Evaluating people puts them on the defensive
Just as giving effective feedback should focus on behaviour, poor feedback makes a person feel criticised. When the QA said that there are some “defects”, it implied a broken state that you had to fix it. Made worse is the way that they said it made it feel like they were blaming you, and it’s very hard not to feel defensive in a situation like this. A very natural outcome is to pretty much deny the “evaluation” which I’m sure anyone in our industry would have witnessed at least once.

Avoid terms like “defect”, “broken”, “bugs”
One of the biggest differences working with agile testers versus testers who come from traditional backgrounds is the terms that they use. Traditional testers constantly use the words above. Agile testers focus on discussing the behaviour of the system and what expected behaviour they would see. They only use the words above once they have agreement on both of the both the current and expected behaviours. I definitely recommend you do not start a conversation with the words above as they all carry some connotation of “evaluation” and I’m yet to meet someone who truly feels comfortable being “evaluated”

Focus on Effective Feedback
Effective feedback follows a neat and simple pattern:

  1. What behaviour did you see?
  2. What impact did it have?
  3. What do we want to change?

Testers should use a similar series of questions (in order):

  1. What behaviour did you see?
  2. What behaviours did you expect to see?
  3. What are the consequences of the current system behaviour?
  4. Is that desired or undesired?
  5. Do we need to change it?

Apply the guideline above and watch the collaboration improve!

A guide for receiving feedback

April 21, 2009 / / 6 Comments

I recently gave some advice on how to give feedback effectively and was asked to give some advice about receiving feedback. My guidelines for receiving feedback are pretty much based on understanding how to give effective feedback. Ola recently also shared his experiences with this.

Before I understanding how to receive feedback, it’s useful to recap some guidelines on how to give feedback:

  • Feedback should be specific. Talk about specific observations and impact of the behaviours exhibited during those observations.
  • Believe that someone was doing what they thought was correct at the time. (Akin to the Retrospective Prime Directive)
  • Feedback should be timely. Give it early and often as you see fit.
  • Feedback should be about both strengthening confidence and improving effectiveness. It shouldn’t be about making someone feel bad about themselves.
  • The focus of feedback should be about behaviours, not perceived values or attitudes.

When you receive feedback, be prepared not to receive feedback in an ideal manner. For many different reasons, most people find it difficult to give effective feedback, often requiring plenty of practice to get almost incrementally better at it.

Gift

Photo taken the Powerhouse Museum’s Flickr Stream under the Creative Commons licence

Listen candidly
When I receive feedback, I try to listen without reacting immediately to the feedback. Some common (ineffective) feedback people give is something like, “Your code is awful”. When put that way, who isn’t going to get defensive? Even something like “You’re really great” makes it hard to understand what behaviours you should continue repeating, and what behaviours you might consider changing. It’s particularly challenging listening to other feedback if you’ve already been put on the defensive, therefore…

Clarify detail and ask for specifics
When you feel offended or shocked with the feedback, ask for what observations people made to reach that conclusion. I like to ask for what observations they made and what impact it had, as well as how they felt about it. For some people, it’s useful to help them understand that you currently feel defensive. I might say something like, “I feel like I’ve just been judged and feeling defensive. I’d like to understand what behaviours you saw had a negative impact so that I can better understand your perspective.”

Share your context with them
People often jump to the wrong conclusion because they may not have the complete picture. It’s often useful to share other motivating forces about the same observed behaviours. For example, “I joined the conversation uninvited because I feared you would never ask me for my input and I felt I had important things to contribute.”

Acknowledge and thank them for their feedback
When people give feedback, they are giving up some of their time. Some people may have overcome certain fears about giving feedback. So when you’re receiving them, ensure that you acknowledge what they are saying and thank them for their feedback. Even if you disagree with their conclusion acknowledge their contribution if you also observed the same behaviour.

Ask for feedback early and often
Giving effective feedback takes time and isn’t often at the front of people’s minds. We know that it’s easier to respond to feedback early when you have an opportunity to change something. As the person receiving feedback, it often helps to invite people to give you feedback as this alleviates the fear most people have when giving feedback, “How are you going to react?” Giving people some notice about collecting feedback also helps.

Move people away from judgements to positive action items
For some people, it will be difficult to move them away from their “evaluation” and brining them back to observed behaviours. Also, some people don’t take remember specific behaviours or impact and like to talk about their “gut feeling”. While this isn’t particularly effective, as a person receiving feedback you can still benefit by asking them, “What should I do differently?” or “What could I do to make more of the situation, or make the situation better?”

What helps you?
I’m sure there are plenty of other tips on how to receive feedback. What do you tend to focus on when receiving feedback?

Come along to XP2009

April 7, 2009 / / 2 Comments

At this year’s XP2009, I’m going to run the workshop, Climbing the Dreyfus ladder of Agile Practices where we’ll look at learning models (focusing on one in particular) and how to use them to help as a model for coaching and transferring skills around agile practices.

It’s going to be great fun, and contains some great material inspired by all the wonderful coaching work that Liz Keogh has been doing (we’re also hoping to get into Agile 2009).

Bring your friends, your work colleagues and anyone you think might get some benefit. I’ll be maintaining this page as we get closer to the conference.

How do I tell if a team is agile?

November 12, 2008 / / 4 Comments

Vivek asks what are the signs you use to tell if a team is agile? I prefer not to count the practices they might be using because that is almost too easy (to get wrong).

Example: I remember talking to a person about their team who claimed they did lot of automated testing. They apparently had tests but upon further questioning I found many of their tests didn’t work and hadn’t worked for quite some time. I continued to ask questions about their practices and they mostly seemed excessively ritualistic without the team benefiting from them.

Ticking off a checklist about practices is easy to do, yet hard to do well. I prefer to ask questions with a less explicit goal in mind. I care more about how people do what they do rather than what they are doing right now.

I prefer to look for consistent behaviours across what they are doing that tell me:

  • they care about what they’re doing
  • they understand why they are doing what they are doing, and actively question when it’s not clear to them
  • even better is that they can explain to people why they do what they do as a team and what value each part of their process has (I dare you to try that with your current team)
  • they help each other out even if it’s beyond their normal roles because they don’t believe that people fit in boxes perfectly. And most importantly;
  • they’re constantly trying to improve the environment they are in.

What other ones do peope look for? I’m sure there are plenty more.

The Agile Coach Role

July 25, 2008 / / 1 Comment

I’ve previously written an article for InfoQ about how agile coaches act when working with teams. For this particular entry, I want to investigate what jobs or roles you might consider trying to either focus on part-time or try full-time to develop the habits and skills necessary to be an even more effective agile coach.

At the XP2008 conference I spoke with both Liz Sedley and Rachel Davies, two other agile coaches, who ran a workshop about agile coaching. We talked about the different skills an agile coach might need and some of the duties they might perform. We talked about overlaps with other jobs and concluded that an agile coach may do some training, yet only being a trainer doesn’t make you an agile coach (there’s more to it). Below is a diagram that hopefully makes it clear some of the responsibilities that overlap with a number of other roles.

Agile Coach Development Model

As you can see in the diagram above, an agile coach may do many of the things you see full time facilitators, full time trainers, and full time coaches do. Yet doing each of these roles by themselves without the real experience garnered from agile projects does not make them an agile coach.

Using this as a model for career development

Even though I just put this diagram together to help others visualise this model, this is exactly what I’ve been using to further improve my skills as an agile coach. More recently, I’ve been in the role of a full time coach and trainer both internally and externally, and especially fortunate to work closely with other full time trainers to benefit from their experience. That experience has given me a better understanding of how people learn and a broader set of techniques to draw upon when helping others understand the concepts and principles.

Earlier to that, my focus had been towards better facilitation practice, reading books about good facilitation skills, and eagerly applying this during the projects that I’ve worked on. This has been particularly useful in executing the Retrospective practice. Beyond that, I’ve been lucky enough to work on many different agile projects in a development role, benefiting from others’ experiences through observation.

Just an agile coach role

I’d be keen to hear what other full time or part time roles other agile coaches have attempted for short amounts of time in order to develop the skills that will make them a better agile coach. Please leave a comment if you have a suggestion.

What you say

July 11, 2008 / / 1 Comment

May not be what people hear… Therefore it’s really important to listen to people, asking probing questions to ensure the intent of your message got across. I’ve seen many people (including myself) fall into the trap of focusing on delivering the method, that we never test to see if it made it across.

Why timeboxing is important

July 3, 2008 / / 7 Comments

In considering a leaner approach to software development, many people in the agile community are starting to turn towards an iteration-less approach. Wayne Allen talks of trialling No More Iterations, while Amit Rathore talks about an iteration-less agile process. Heck, I’ve even given it a go with a couple of my projects. On the other hand, there’s a whole movement in Italy devoted to the Pomodoro (Tomato) Technique that focuses on time-boxed activities.

So who’s correct?
The short answer: They both are.

Time box

Photo of a “time box” from Great Beyond’s Flickr stream under the Creative Commons Licence

The long answer: When you compare people not working in an iterative fashion (i.e. one phase of analysis, one phase of development, etc), to those agilists now turning away from iterations, there’s a noticeable difference, and is what I will call, discipline.

Those arbitrary time boxed units that we call an “iteration” creates cadence for teams. Cadence in turn creates rhythm, where teams can focus better on developing the healthy habits associated with agile software development. Much like the way that beginning martial artists repeat katas, it helps the Novice, Advanced Beginner and the Competent (Dreyfus Model) understand each practice individually and develop the discipline to make them effective. They don’t need to worry about which practice combines best with other practices, and yet, still see some benefit. It helps the team synchronise, predict and potentially even enforce when activities happen, giving people the stability they need when they are learning. It forces people to make important decisions that, without the associated discipline, end up deferred.

In absence of iterations, you need a guide to achieve a similar effect to encourage people to use the practices in an appropriate order. I argue that those people who are Proficient or Expert (Dreyfus Model) don’t need the iterations because they understand when to use what practice and the value it brings. They move towards what looks like an “iteration-less” approach because they are instinctively doing things iteratively without the arbitrary time box. They have enough discipline to ensure all the activities happen at the right time without causing disruption. Unfortunately, in my experience, many never make this jump to being Proficient or Expert.

What to do about it?
Iterations are useful, with that usefulness limited to a certain context. The learning level of the people involved heavily influences this. Respect the needs of the people you work with, and understand that jumping into “no iterations” requires a level of discipline you won’t achieve without people reaching these later levels of mastery.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑