thekua.com@work

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.

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.

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.

Comments(1)

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.

Comments(1)

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.

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.

Comments(7)

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)

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)