The intersection of technology and leadership

Category: Coaching (Page 3 of 11)

Coaching Tool: Coaching DOJO

Short Description:Group of people getting together and coaching each other potentially using GROW model. Use short rounds with time limits.

How to run it

  • Seeker (a role that rotates) shares the problem with 2 other coaches and 2 other observers watching. Time boxed to 5 minutes.
  • 2 coaches comment in an active coaching role. Time boxed to 10 minutes
  • 2 observers then comment about the interactions. Time boxed to 10 minutes.

Original Source:
Sergey Dimiticus in Oslo and Rachel Davies

Where it’s been used
In agile coaching camps, learning together to generate coaching ideas and developing coaching skills.

Contributed from the participants of my XP2011 workshop

We’re not trying to be rude, honest!

I got included in on a twitter conversation by Mark responding to Brian talking about how ThoughtWorks people at a particular conference huddled around together. It’s not the first time people have observed that. A natural reaction by people outside of that circle is to comment on this, such as, “You’re not very inclusive,” or “Crowding around together is so rude.” Having been part of these circles before, and being told this judgement (with accompanying observation), I can tell you where it stems from.

ThoughtWorks is a distributed company
Though I can only observe consultants I interact with from other companies, I feel ours is definitely very global. We encourage people to travel from one country to another, frequently rotating projects and encourage each other to present at conferences. Being located pretty much all around the world, it’s natural you don’t get to meet everyone face to face. Even here in London, I am now used to turning up for a new office event only to meet several new people. We work on different projects, so it’s natural not to meet anyone.

Our electronic-social ties are extremely strong
Internally we have, at least what I like to think of as a very active mailing list. When I post something on there, I generally get some pretty good responses particularly from the largest community of software developers. Over time, you get to know someone’s online persona. You have a picture of them in your head, and start to see the nuances of how they express themselves. Even things like twitter help to do this. It’s not uncommon for me to feel more strongly attached to people actively participating in email conversations than some people in the same office of who I rarely see or talk to.

Conferences are attended by ThoughtWorkers from around the world
As I briefly touched upon before, as a global company we try to encourage people to travel and present at conferences. This naturally leads to opportunities for people to meet in person for the first time. It’s strange meeting people you feel like you’ve known for a long time in person for the first time. I still remember, for example, my first day in the London office where I finally met Liz Keogh and Tim Emiola for the first time after conversing with them electronically for 18 months before hand, and them now inducting me into the whole Britishness of “buying rounds” and the way that it all eventually works out.

People have a need for connectedness and belonging
Having just recently talked about it at the XP2011 conference, I noticed that we weren’t the only people to congregate into small circles. For instance, I remember a whole bunch of people from Brazil hanging around together for almost the entire conference. Likewise for a small group of people who worked for the same company in Sweden. It’s a natural thing, particularly in new environments, for people to stay close to those they already have relationships with.

It’s less about you than you think
It is all of these effects combined that lead to ThoughtWorkers aggregating at events. Perhaps it’s also because we tend to be quite loud/opinionated/noisy that it’s more noticeably. Gravitating towards each other isn’t a conscious act trying to exclude everyone. In fact, I know ThoughtWorkers like hearing other opinions, particularly if they’re even more different and based on strong experiences and though happy to contribute to conversation will be welcomed with open arms.

We can get better at this
I know it can be hard approaching a loud, opinionated group of people. I know we can do it better. Being aware of how we’re sometimes perceived, this is how I go about trying to break the perception:

  • Invite others in – If I know someone standing at the edge of a group, I’ll introduce them and explain my relationship to them to others. It helps break the awkwardness and creates more opportunities for everyone to talk about similar interests.
  • Randomly break away – If groups get too large, or hang around too long, I like to break away and meet some new people. I also try to encourage other people to do the same. It’s not only a good way of getting different perspectives, but helps address some of the above issues.
  • Explain to others the contributing factors and perceived effects – By talking people through the above elements, it helps others understand why perceptions come up the way they do. More importantly it lets them decide how they’d like to deal with it

Whilst I can only speak for myself, I do hope that other people can benefit from this by being more inclusive where possible in these sorts of situations.

What’s in your coaching backpack?

This morning I facilitated a coaching workshop at XP2011 called, “What’s in your coaching backpack?” It was a four hour workshop, so lots of time to go into detail. I designed this workshop to focus more on depth than breadth for the four hours. After some introductions to the purpose and format of the workshop, I got everyone to move into groups and spend some time introducing themselves to each other. In these groups, we spent some time focusing on brainstorming various coaching tools, models and techniques and we came up with a huge variety. I’ll get around to writing each one of these up (there’s quite a lot of detail) so look out for them in future blog posts. Our coaching backpacks are now much fuller than what they were before.

After a break, we then reconvened and I asked people to focus on some case studies of some coaching situations where, in their groups, using the coaching tools to articulate how they’d approach each situation. There were some really great conversations and discussions, where I hope people got a better feeling trying to see how others might apply different techniques to the situation. Having been grounded in real world experience, people also wanted to know what did happen (even though there aren’t any correct answers to case studies).

I also had a quite mini retrospective, asking the questions, “What you enjoyed about the session?” and “Suggestions for improvement?” I had some great feedback and wanted to put it on line:

  • Like – Practices and real examples, discussion and division to groups, Scrum board or presentation agenda
  • Great format, loved the taskboard, posting on wall “backpacks”, case studies
  • Good group size, great group
  • Really well facilitated
  • Interesting content generated by the open conversations
  • Sitting in the sun was AWESOME!
  • Great opportunity to discuss different approaches to coaching and agile
  • Like the idea of showing progress of the workshop at the scrum board using tasks
  • Case studies/real life examples always interesting
  • Good, clear setup with backlog
  • This was the session I got more out for my work/myself than any other session 🙂
  • The workshop format
  • Working in small teams, all adding different perspectives
  • Sun
  • Nice with practices and your communications
  • Your excellent preparation and light-weight facilitation
  • Small groups
  • Interesting case studies
  • Exchange of ideas
  • Case study
  • Very well organised and structured
  • Good atmosphere, positive energy
  • The case study discussions
  • Living whiteboard agenda
  • Maybe switching up the teams between case studies might reduce effect of powerful personalities
  • Rotate members in tables to get more ideas?
  • Suggest you split groups with the knowledge spread more evenly – you asked experience and could have used that info
  • Same team all he time. Maybe we could have shuffled people in the middle of the session
  • Changing teams after a while (e.g. at lunchtime if in for whole day)
  • I could even have a whole day of doing this without being bored
  • More practises and making the descriptions of “methods” out from this
  • Produce example tool(s)
  • Put all coaches tool/methods together and have a global short discussion
  • Common discussion about the good practices
  • Would have liked to hear/learn more about coaching techniques
  • Would have been nice with an introduction to the methods/worksheet part to get the flowing associations
  • A conclusions panel to write the achieved results

It’s never been about what you do

I find it fascinating talking to people about their agile implementation. Some people immediately claim they’re agile by describing the practices they use. I often ask a few more questions such as, “How is that working for you?” and they start to describe a number of problems they have. Another answer people often give is, “We’ve been doing agile for ages!”

“Doing agile” has never been the point. The agile mindset is about working with customers or stakeholders to deliver solutions whilst always continually improving. The practices are simply ways of getting there. It’s never been about what you do. What matters is how you do it.

Improving how you do something is easy yet requires constant discipline. First, you need to be continually asking yourself, “How does this practice help us?” and searching for answers to another, “How can we get better at this?” Talking to people outside your organisations often help, as does following what other people do around the world (made easy through social channels like twitter and blogs).

Agile Coaches Gathering UK 2010

Last year, I missed the announcement, and therefore the Agile Coaches Gathering UK organised by Rachel Davies (author of Agile Coaching). Fortunately I happened to join twitter late last year and saw the announcement for this year’s gathering shortly after its announcement. I bought a ticket as soon as I could. It’s a good thing too since I think I bought one of the last few tickets for a restricted sixty person gathering.

This year’s gathering, held at historic Bletchley Park spanned a day and a half with Friday evening opening the Open Space format to be used on Saturday. Bletchley Park ended up an awesome venue, and the open space format worked well with a number of spaces located outside. Given the UK actually had a summer this year, it turned out very nicely.

Bletchley Park Mansion

One of my favourite things about this sort of gathering is getting a whole bunch of people working in many different environments, contexts and getting them to share ideas and approaches about what works for them. We had a mixture of experienced coaches and coaches new to the role yet there was something about being there on a Saturday and a passion for it that brought people together. What follows are my notes from each of the sessions.

Experiences from the coaching discipline (not just agile practices)
My first session of the day explored other coach’s experiences working or exploring what coaches from other disciplines do. One person shared their experience working with a swimming coach and how they helped them get better at their practice.

This theme, looking at other coaching disciplines to see what they do, definitely ran throughout the day although I’m cautious of taking the role too literally. We discussed this during this session as most people being coached (life coaching, sports coaching, etc) tend to do so on a voluntary basis. Working as agile coaches for organisations, not everyone is necessarily there on a voluntary basis.

Another aspect that, I think differs, is that most coaches aren’t necessarily experts in the field they’re coaching in. For instance, sports coaches are often not people who’ve been the most successful in the world. In my experiences, agile coaches are really there to act as shepherds to help people get the most out of thinking and working with agile practices. Unlike other coaches, this often requires a level of mastery than what most other coaches have in their field. I’ve seen coaches act dangerously with not enough experience with agile practices.

I still think there is value in looking outside of our discipline for ideas and methods of working, yet conscious of the appropriate context to use them in (and there is always a context).

Presentation is not facilitation
Tobias Mayer is really well known in the Scrum community, and proposed a session to rant about the way that most training is done. I think there are plenty of examples where Death by Powerpoint is interpreted as effective training and whilst I agree with the premise, I’m not sure I agree with the end conclusion. I think presentations have a place, just maybe not in training. I also don’t necessarily think that training is solely about trying to trigger a complete mindshift in people.

When a coach gives up
I met Xavier Quesada Allue at XP2009 and again at Agile2009 so was interested to hear the premise around is it okay for coaches to give up and when to give up. This was one of those sessions located in the sun and some interesting stories about dealing with difficult teams or organisations where it doesn’t make sense to try.

We didn’t attempt to clarify, at the start of this session, what giving up meant to everyone. This probably made it difficult to get an agreement about when or why to give up, although we heard some very interesting stories.

My take on this, is that coaches end up needing to prioritise their work, just like everyone else and thus, not everything is going to get taken care of at the same time. Working with people also means you cannot predict how quickly people will move, or how they will react, therefore there is no way that you can always set completely achievable goals (it relies on others, not just yourself to make them happen). As a result, as a coach, you need to be comfortable with things not always going as planned.

I think that coaches also have the benefit of seeing the system that is driving a lot of the behaviour for the people on teams and unless something is done with that, then they will continue to behave as they always have. Both of these take time.

Game sense approach (what I learned coaching rugby)
Another inter-disciplinary coaching session that I attended briefly although a very loud bus made it difficult to concentrate and I ended up leaving because I had difficulty participating during this session.

Double loop learning + Defensive routines
If you ever get a chance to listen to Benjamin Mitchell in a safe environment, he’s quite the riot. If anything, perhaps it’s his self-deprecating and admitting his own faults and looking back at mistakes amidst his jokes that makes it so warming.

During this session, he talked about a book he’d been reading discussing how people react, and talking about different “models” in which the author classified people and using that to be able to project behaviour in different circumstances.

Once again, Benjamin reminded me of some key points I’ve learned over the years like:

  • What you say and what people hear are completely different
  • Avoid positional or solutions-based negotiation. Lay your interests on the table and you’ll often end up in a better position.

I’m not really clear about what double loop learning is, so I’m going to have to add that to my to do list as well.

Open space schedule

New books

XP2010 Review

This year’s XP2010 conference was held in the great Northern parts of Norway, up in Trondheim, only about 200km south from my first XP conference (XP2006) I attended several years ago. I always find this series of conferences interesting, partly because there is always the blend between the academic (research papers and experience reports) and the industrial side as well as the infusion of the hosting country’s culture.

This year, the conference saw 425 attendees (50% of them Norwegian) across 8 different tracks and covering four days of a wide variety of conference mixtures including Lightning Talks, Panels, Workshops, Tutorials, and Open Space events.

ScottPage

The first of the two keynotes, run by Scott Page was my favourite – a lecturer and researched on complexity in different environments. He talked about the importance of diversity and its impact on building better solutions as well as a provable formula calculating what the wisdom of the crowds was. Hopefully they’ll be putting up his slides somewhere as a result.

The second of the keynotes, ran by David Anderson did a great job of condensing down a long talk into a thought-provoking discussion on the work that he’s been doing on building a Kanban movement in the places he’s been working as well as a discussion of his recently released book about Kanban. He had some nice visualisations on the slides and even finished slightly earlier with plenty of times for questions.

Overall the conference seemed to have a nice blend of both process and technical topics, although there were a few complaints about specific discussions around “XP” itself although I think plenty of discussions about specific practices quite useful within any agile context.

I ended up much busier than I thought I would be, playing host for two of the session talks, helping out with a Pecha Kucha (more on that later) session and running a workshop on my own.

Entertainment

Venue, organisation and efficiency wise, the organisers need to be congratulated on a job that will be hard to surpass. Everything seemed to run smoothly including an amazing and difficult-to-forget Conference Banquet involving interesting local foods (smoked reindeer heart, moose and local seafood), a pair of comedic jazz academics, Keep of Kalessin playing some Extreme Metal, all inside Trondheim’s amazing Student Society venue.

ExtremeMetal

The strangest part of the conference for me was participating in a “What’s in my agile suitcase?” Pecha Kucha run by Martin Heider and Bernd Schiffer. You can read more about the format here and it was great to be one of the five other prepared Pecha Kucha’s including Rachel Davies, Mary Poppendieck, Joshua Kierevsky and Jeff Patton. I found the diversity of styles and approaches fascinating as well as the specific things that people “packed” in their suitcases. Being the first time format all the speakers found it a fascinating format made thrilling by the short-time and the fact you don’t have control over the timing of the slides. If I were to do this differently, I’d definitely try to focus on a smaller range of topics (or just one).

My week ended (as did the conference) with my final workshop called “Building the Testing Pipeline.” I’d specifically targeted people who’d been working with automated tests for some time and I ended up with a surprisingly full room. I’d run this previously at ACCU with a slightly different audience. We had some great brainstorming sessions (I’ll be putting that up soon) and hopefully more people came away thinking more consciously about the balance of tests they have and whether or not they have the correct balance that maximises their confidence, and minimises their feedback cycle.

I’m also very proud that the experience report that I shepherded won best paper (experience report), and I finally got to meet the author, Jørn Ola Birkeland of Bekk Consulting, in person to congratulate him on the day.

Thanks to all the organisers, participants, and passionate people that made the conference so much fun and success. Wonderful to reconnect with old friends and make many new ones.

Book Review: Agile Coaching

It’s about time I got around to reading the whole Agile Coaching book by Rachel Davies and Liz Sedley. I’ve owned it for at least six months now but has sat with a number of other books that demanded my attention. Fortunately long flights (like back to Australia) give you lots of time to pass with books to read. I’m glad I finally got around to reading it as well. The short version: if you’re interested in what agile coaches do, or if you’re working in an agile team, particularly a leadership role, this book is for you.

AgileCoachingBook

When you first open the book, it’s obvious it is a Pragmatic Press book. It jumps straight in with lots of helpful hints for those that want or are currently looking to be an agile coach. It’s broken up into four main areas, with smaller sections revolving around specific agile practices. This also means it’s fairly easy to digest it in smaller pieces (something I probably could have tried) doing the daily commute on the train.

I’ve been fortunate to know Rachel and Liz before and during their book writing. This book really captures the way they work, and great advice in the form of very practical tips for people. I hope that any readers, even without knowing the authors, can tell the wealth of experience both of them bring. I think writing a book on agile coaching is pretty tough. There’s a temptation to focus on the coaching elements alone, or to capture the distilled gotchas around introducing and coaching teams on specific agile practices. This book definitely gets the balance right for those new to coaching agile teams – enough background to the practice with helpful hints (it’s not meant to be a definitive guide on a particular practice) yet framed in a way that would definitely help anyone introducing and encouraging an agile way of working.

There are many other people this book wasn’t written for (more on that later) yet in its form is the best collection of wisdom steeped in experience that I see budding agile coaches benefiting from. I wish I had something like this when I first started out explicitly acting as an agile coach.

Like all the pragmatic books, this one is really easy to read. I think it took me about three hours on the first leg of my flight to finish it. Reading through each of the sections, the authors offer advice and helpful techniques. Many I’ve drawn upon over the years and draw upon often, a few I’ve never used and many that I definitely needed a reminder about using them. In other words, this book contain lots of practical advice that can really work depending on your team and circumstance.

There are many things that I like about this book – including the small personalised stories from both authors, named techniques that will help new coaches remember them better, and a very direct try this and see sort of philosophy that is both pragmatic and living by an agile way of working. I particularly approve of this book being, for the most part, methodology-neutral mentioning a broad spread of practices and principles individual methodologies espouse followed up with many other links to resources, books and references for agile coaches to then follow. I also like the hurdles section (there’s often much more than those listed!) as it hopefully prepares agile coaches for what happens when things don’t go to plan (almost always).

This book definitely fills a need – helping new agile coaches work out where to start with lots of advice that can be applied almost immediately. This book is also a useful reminder of tehcniques and a way of filling in some gaps for agile coaches who might have only experienced some of the agile practices and ways of working.

Like all well focused, practical books, part of what makes it so well focused and good are the areas that it leaves out (something I’m sure will be filled by other books to come). Some of these topics include:

  • Setting up an agile coaching gig right (when they perhaps need something broader than agile coaching) – it’s no panacea for all organisational problems and coaching isn’t guaranteed to turn every situation in short timeframes
  • Coaching larger teams or large organisations
  • Coaching distributed teams
  • Helping organisations “go agile”
  • Different types of coaching engagements (full time – to part time)
  • Working with other agile coaches as a team

I’m glad someone got around to putting this book together – and I’m happier knowing that it’s also written by practitioners grounded in plenty of real world experience and a variety of different contexts. To new coaches, many of these apporaches may seem optimisitc or impossible but I know that they’re all tested and can work in the right circumstances. Read this book as a way of starting off and refining your own agile coaching style – don’t view this as a definititve book to agile coaching, and as the authors put it so well at the end of the book – develop yourself continually.

Build the testing pipeline at ACCU 2010

Just a short note that I’ll be running a workshop for attendees of ACCU2010 this Saturday on understanding how to get the balance right for the testing aspect to build pipelines. We’ll explore the tradeoffs and conscious decisions we should be aware of when putting these into our feedback loops.

Slide deck to come, though it’s a classic me-style, participatory workshop (you learn more by doing!) so slides won’t necessarily make a whole lot of sense by themselves.

QCon London 2010 Day 2

Keynote: Ralph Johnson on Living and working with aging software
The final keynote of the conference kicked off the second day of QCon and presented to us by Ralph Johnson of the Gang of Four fame and whose students contributed to Fowler’s timeless Refactoring book.

Ralph was asking about the number of people who work on systems they created (versus systems that other created) and then argued about the meaning of maintenance programmer arguing for software evolutionists instead. Whilst I agree that no one likes to be labelled a maintenance programmer, changing the name doesn’t really matter.

I like the different perspectives that Ralph brought. He talked about Software Capital as about truly understanding how the software works. Code is one example of this, but actually there are many other things that go into understanding how the software works. He argues that the right sort of documentation (and other artefacts) that helps understand how the software works is another part of Software Capital. As a result, you also need the people around the software to help keep the story alive.

My observations of various organisations also backs up some of the things that he says such as, the larger a system gets, the more likely you need some form of documentation and social structure around the software.

I think a lot of people didn’t like Ralph’s keynote because he talked about refactoring as if it was a new idea and, unfortunately this audience is one that has been exposed to these ideas for a long time.

Track: Beyond Tools and Technologies
I spent the rest of my time on the track that I was speaking at later that day. The first talk of the day was Martin Fowler whose talk, “What are we programming for?” brought the tiny room to a stand still. The room was so full (although it was a small room) that they had to turn people away.

WhatAreWeProgrammingFor

Martin used the talk to highlight the importance of going beyond acting like hired guns and actually thinking about how to use the skills for something good. He asked people to consider the essence of the firms that they work for and whether or not they are benefiting humanity.

Rebecca Parsons, ThoughtWorks’ CTO then talked about the importance of team diversity in her talk, “How to avoid ‘We never even thought of that’!” She talked about the role that diversity played in creating innovations in science and how too much of the “sameness” creates problems with creating too many assumptions. I like the idea of a balancing tradeoffs of not enough diversity leading to problems in teams and too much diversity to the point that the team don’t share the same vocabulary.

After the lunch break, I ran my session, “Building the next generation of Technical Leaders“. I was very happy with the turnout and had some great feedback from the participants. It’s an issues I think is sorely neglected in our industry and has a huge impact on the team effectiveness.

The next session was run by our Director of Social Engagement (Jeff Wishnie) and Merrick Schaefer of Unicef discussing the importance that technology has on developing countries and the significant impact it can have on the lives. They talked about the Rapid FTR project that is being developed to help capture information about children who’ve been separated from their parents with hope of quickly reconnecting them, and at worst, giving them legal status by registering them with an agency such as Unicef.

The final session of the day rounded out with Mick Blowfield with a presentation titled, “IT in a Low Carbon Future“.

Whilst there were many other potentially interesting sessions, I was really happy to hear about the issues that go beyond just Tools and Technology.

Agile lets people be people

When you introduce agile methods to very traditional organisations there’s a side effect most people underestimate. This is, I believe, where the first line in the manifesto is most appropriate:

Individuals and interactions over processes and tools

Traditional organisations are geared for efficiency – keeping individuals busy to the point where you lose overall effectiveness if you ever need to synchronise between parts (which you inevitably do for software these days). Calling a meeting is frowned upon as it takes up lots of time, so out of necessity, most communication occurs over email or IM. As Alistair Cockburn pointed out a long time ago, these are pretty ineffective channels of communication. Relying solely on these types of channels only turns to a build up of frustration as issues go unheard by the right set of ears. In traditional environments, these often turn into build ups set to explode at the most random of moments.

BrokenBottle

Image from Nic Jacka’s flickr stream under the Creative Commons licence

Perhaps you’ve seen it? Think about when one person hijacks a meeting to highlight an issue (typically important one) not being addressed, or when someone spontaneously shouts at someone for no apparent reason. It might even be as bad as someone having a temper tantrum, literally throwing things across the room. Traditional environments often do not provide mechanisms as outlets for this.

Therefore, when introducing practices such as daily stand ups, planning meetings and retrospectives, the first few times you run them, expect an avalanche of unresolved issues and emotions to ensue. This is fine. Expect this from some of the quieter members as you give them explicit permission to talk about important things that need resolution where traditional structures have not given them that permission to talk about them.

Treat it as you would the opening of a previously shaken soft drink bottle for the first time. You’ll have to be ready to clean up some of the spilt liquid, but you don’t have to worry about picking up broken glass. Now that the bottle’s open, you can work to address the real issue at hand.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders NorenUp ↑