Agile Coaching Ethics

Recently Dan Mezick (of Agile Boston and Agile Connecticut) has been writing about Agile Coaching Ethics. I welcome this conversation, and agree that a coach cannot be embedded to be effective. This is something I've come to learn the hard way--and was greatly inspired by comments at Rachel Davie's Grumpy Old Coaches panel at XP 2011 (Madrid).  Currently I have to admit that I do both contract work and coaching--but I have been clear with my clients that there is a difference and that I want to focus on the coaching. I've always measured my success by how well a team does after I've left--but I'm learning better and better ways to do this. My mantra, these days, is "I do nothing, I own nothing".  When I follow this mantra well, the teams I work with do better too--they become Leaderful Teams.
So let's work together as a community to make expectations clear about what a coach does, and doesn't do. Here's my stab: An Agile Coach helps a team shift its perspective, thereby allowing the team solve its own problems.  I also second George Dinwiddie's definition:

[A coach] build[s] the capability of the existing team. Rather than making choices for the team, the coach provides guidance about the choices available, perhaps making recommendations, and encouraging them to consider the options and choose their actions. The coach teaches the team about techniques or tools that increase their available choices. The coach offers observations about the team’s activities, and helps the team make it’s own observations and reflect on them. The coach helps the team articulate the results it wants, and generate courses of action to achieve those results. The coach partners with the team on the coaching process, but allows the team to exercise its own judgement about the software development practice. The coach does not become a member of the team, but endeavors to wean the team off of the need to consult with the coach on a regular basis.

With this kind of definition of Agile Coaching, I believe that clients will benefit even more from coaches-since there's the expectation that the coach isn't always there, and for that reason will be more likely to bring ideas in to the team from other environments. Another slant to this is that to me, a key responsibility of a coach is to go out and learn as much as possible that can be applied to the teams being coached.

What Dhondt Teams Gel is all about

Too busy fighting bugs and doing rush jobs? For less than the cost of getting your team certified, contact us to coach your team to more effective, higher quality software (if you're in the greater Philadelphia region)! Dhondt Teams Gel is staffed by yours truly as well as an associate or two when we need a second opinion--all for the same, low monthly subscription. Subscription rates vary, but are approximately the same price as a one or two-day training course. Basically, you don't pay until our coaching delivers real value to your organization--and even then, we are so confident that our results work in the long haul that payment for our services is made in a two-year annuity.


Pay for Results, Not Hours
Many coaches charge by the day or by the hour--regardless of the outcome of their work. Some offer satisfaction guaranteed--but still charge before the results are realized. If we're working on cutting the cycle time of your dev team by 50%, you don't pay anything more than a flat subscription fee until you're seeing working software sooner! Our Coach on Retainer product is only profitable when we deliver results for you!


Training Plus Coaching
We also offer training workshops and soon we'll offer classes for a certification program (no official announcement yet). Since I believe that training and certifications are just the beginning of an intentional learning journey, I also include two "refresher" visits in the price of any class with 5 or more participants from the same company. It's the long-term relationships where we provide the most value, and that's why we want to visit course participants again and again.

Communication About Design Workshop Series

Since a client of mine asked for help on communication skills in the team environment, I've been doing a short series of workshops on the topic (60 minutes each). For the first workshop, we did the [spoiler warning]: Marshmallow Challenge. Many participants enjoyed the workshop and saw how some of the teams had worked together while others had participants that checked out entirely. We talked about what it would take to work together better, to make a higher tower, and whether they've seen similar performance problems in the work environment. Normally I have everyone start this workshop at the same time, but in this instance we had some latecomers who began after they saw the final result of the other team's towers. The first two teams had built towers at 0 inches tall (it was unstable) and basically one spaghetti stick tall--and the latecomers were determined to win--so they focused on a design that would get them two sticks tall, and prevailed. Of note is that the teams that worked together by talking through and adapting their design ideas, succeeded at building something stable, while the team that had some people check out were unable to adapt their vision to something more stable.
For the second workshop, I adapted a game invented by Olivier Albiez and I--a brainstorming activity designed to show ineffective communication. We had 4 local participants and two remote (through a teleconference bridge). To make things more dysfunctional, I randomly gave each participant a 'vice card', with one of the following captions:

• ignore it
• criticize it
• be defensive
• say it's too simple
• support it
• rephrase it in your own words and ask if that's right
• ask clarifying questions

We tell participants they'll be brainstorming, and that no matter what anyone else says, they're to follow the instructions on the vice card in their response about the idea.  The same vice cards can go to more than one person; they're actually just a tool to save face for anyone that has a strong personality.
We set the stage by saying we're designing a fire safety kit to be used in office buildings, which includes instructions and basic fire safety essentials. All the participants are asked to do is to list what should be in the kit and/or on the instructions. As the moderator, my job was to write down any idea I heard as the group made suggestions. As you can imagine, hilarity ensued. People argued about every idea, and they repeatedly had me change the words I'd recorded. We ran this session for 7 minutes, followed by 5 minutes of observations like:

• we didn't get very many ideas
• almost every idea was from the two most vocal participants
• people on the teleconference bridge couldn't get a word in edgewise
• few people were listening or building upon others' ideas

We did one more round, this time without the vice cards, and people were more respectful of the phone participants--but the list was basically as short as before. Why no additional creativity? Here's what we came up with: 

• the product goal wasn't clear--was there a market for what we were building?
• participants who were now listening said they didn't understand their colleague's ideas, and so asking questions slowed them down from coming up with new ideas

For the third round we said we'd pick what goes in the tool bag for a long bicycle ride. In the first 90 seconds one person seemed to misunderstand the task, an argument ensued and the confused person never spoke again. We discussed this in the observations step, but offending party didn't accept the feedback--saying that person's ideas were off-target and so were rightly rejected. Based on this, I think I'd need to do yet another round, or to change the topics for each brainstorming session so people would be more likely to learn what it takes to brainstorm effectively.  Has anyone here played a similar game?
Overall, I'd say I'm happy with this workshop--I was hoping to create a situation where communication broke down, and we could get people to talk openly about it. I wish we could have gotten there quicker--and so that's what I'll work on the next time I run it.

The third workshop is yet to happen, but I'd like to get this team comfortable identifying "criticism, contempt, defensiveness, and stonewalling" during their planning sessions. I'd also like to set clear ground rules that prevent arguments, allow only simple explanations, and focus on moving forward (and even capitalizing on misunderstanding).

For the fourth workshop, I'll have the team quickly draw our real system architecture in 60-seconds, then ask what we'd have to change to support a real backlog item. There are two objectives in this workshop--to learn to manipulate our system architecture quickly and easily, and to learn to talk openly about new ideas. I don't know if we'll be ready for this by the fourth workshop, but I'll report back here!

3 Questions Considered Harmful

Since I've been reading a lot of pre-agile books, Dykstra's GOTO Considered Harmful seemed fitting here.  I think that the standard three questions for Daily Scrums (what did I do yesterday, what am I doing today, any blocks) should be considered harmful, because these questions force people to focus on themselves--and we want people to focus on the team! So for years I've been experimenting a lot with the Daily Scrum, by changing the format with  hot potato, pull, and synchronization points, and by changing the questions:

• are we on target to finish this iteration on time?
• what's important?
• anyone want a second opinion on something they're working on?
• any decisions to be made by the group?
• what's left to finish the iteration?
• what can we deploy next?
• open-ended questions about stories that are active
• any topics for the parking lot?
• any ripple effects? [that is, for something I just changed or am about to change, who needs to know and what effect with it have?]

It would be great if we had a stable list of questions, but I find it more effective to use two or 3 from the list above for a month, then to use a new set--it keeps people on their toes, and this thinking creates better communication.

To help clients and conference attendees see what I'm talking about, I've also prepared a slide deck entitled Freedom In Meeting.

Technically Philly Groups

Learning and Networking
Have you ever wanted to talk to other people using your favorite new development language--but just didn't know where to go? Have you ever wanted ideas on how to improve your teamwork or software development life cycle? Or do you just want to network--trying to find a job or trying to find good recruits?  Imagine a place you could go meet talented and passionate software team members--and you only had to wait for the right day of the week, since we've got events booked every week for the foreseeable future!  Welcome to Technically Philly Groups, a consortium of existing technical user groups in the greater Philadelphia region and an incubator for your favorite topic!


Values

Technically Philly Groups is founded on the following principles:

• Serve Others: we all do better when we share what we've got. Sometimes all we have to share is curiosity; other ways we can serve are to: teach; sponsor food for an event; bring a friend to an event.  We believe in, and live by the principles of, a gift economy.
• Create Relationships: we care about the long-term sustainability; we seek win-win opportunities by getting to know one another well enough that we can treat others the way they'd like to be treated.
• Increase Learning: the more we learn, apply what we learn, and validate that it's useful, the better we'll be at our jobs (whether we're in a start-up environment, academic institution, public service, or established business). The purpose of our meeting together is to learn from one another, and to accelerate our ability to deliver results in our software/technical environments. We also believe that learning is maximized when we're having fun--and joy at our events is closely tied to supporting autonomy, mastery, and purpose in the way we structure discussions.

We expect Technically Philly Groups events to be a hub of innovation, communication, and learning. We know that by uniting together we'll help build a more common language for talking about technology, ideas will spread faster, and we'll be able to show what topics we value.

History & How to Join
On June 15, 2011, organizers from 21 user groups founded Technically Philly Groups. Since then we've helped promote one another's events, attracted another 10 groups,  held co-located events, and have shared sponsor money to feed our attendees for free. If your group would like to join, contact us at http://groups.google.com/group/tech-philly-organizers.

loneliness and conference assimilation

Recently, I've been saying that conferences leave me feeling lonely--ironic, since I typically meet 20 people per day and have interesting, deep conversations with at least 5. I know from conversations on the topic that I'm not alone in this experience, yet I also know I'm contributing to the problem. How do I contribute?  It's this game I play--at every conference meal, I sit with strangers, so I can get to know more people. Sometimes we hit it off, sometimes our conversation is forced and dull. By never returning to eat with the same people, though, I'm implicitly saying that none of those new connections are important. In other words, if I don't show that "I like you" by finding you again, it implies that I don't.  That's not an accurate conclusion--I'm just trying to meet more people--but the more people I meet, the more people I leave feeling lonely. With lots of people playing either this game, or sticking with the people they already know well, odds are that many of us aren't feeling the love.  Within three days at these conferences, I typically have talked to 100 people or more, and I can always find someone I know to talk to during a break... but by this point I feel utterly vulnerable and lonely.

Loneliness is not just for Conferences
How do you feel, commuting to work? Watching TV? Reading a book? At the end of these activities, are you satiated? While these activities can be unavoidable, cathartic, or intellectually rewarding, respectively, they're not as emotionally rewarding as a long dinner conversation with good friends. Humans are hard-wired to seek, and to crave, emotional connection. In Community: The Structure of Belonging, Peter Block talks a lot about loneliness, and how to break the cycle by creating things together. Conference organizers, and even speakers, often feel connected to each other and to the community, due to the fact that they've worked together (in small groups) making the conference. Attendees, however, have an entirely different experience until they connect to a small group.

Self-Improvement / Specialization also causes Loneliness (and myopia too)
Since I'm so passionate about software process and teamwork, I spend most of my spare time (at least non-family spare time) reading blogs and books in the lean/agile domain.  Unfortunately, all this reading is lonely work--I'd love to talk about what I'm reading with my family, friends or colleagues in the office, and often mention it--but few other people are interested. So not only does this specialization make me lonely while I'm reading, but also when I try to chat at work. All this makes events at Agile Philly and conferences more important to me.
Even worse, specialization doesn't even give us the mastery we seek.  We've learned from the wisdom of crowds that experts and specialists are less likely to have the "right" answer predicting the future of complex situations than a crowd of competent generalists. Why? For any non-trivial subject, specialists must focus so much on one aspect of a problem that they miss the forest for the trees--and can't make holistic evaluations. So what good is it to isolate oneself, to focus on a topic to the point of mastery, if we'd simply be more wise if we spend time with other people?

Building Relationships
How do we break out of this loneliness? We build something together! In my next post I'll talk about Technically Philly Groups, a community built to promote networking and learning in the greater Philadelphia  region.

Conference Format Can Help Too
As David Rock says, people go to conferences for a couple of main reasons--to soak up new information, and to meet new people.  Rock argues that in this age of going online for our information, maybe the priorities of these two goals are backwards for most conferences. I agree. I don't want to sit in a room with 100 other people, staring at a speaker for 90 minutes, without a chance to speak up myself. If that was my goal, I would sit all by myself at home and listen to podcasts or watch conference videos. Rock breaks the mold of multi-track big conferences by imposing some interactive structure onto all conference speakers--something he calls DEAQ (at least every 30 minutes, stop for digestion, application, exercises, or questions).  I don't think he goes far enough, and prefer Pecha Kucha Pull (3-5 minutes of oration designed to provoke questions, followed by Q&A, then repeat) or repetitive exercise-then-debrief. I really expect more conference organizers to focus on session format.  Last year at XP2010 the organizers had a great variety in session formats, but not this year for XP2011 nor LSSC11. I'd even be happy to see more Bar Camp or Open Space style sessions... though I love Open Space, speakers rarely show up prepared to the same extent they would for a planned talk. Let's be agile about our conference talks--come with a deck of slides, prepared to talk about a variety of subjects, advertise those ideas, then let the audience  'pull' the information out of you!

Unconferences Don't work For Newbies
This past week at Agile Day Boston and Agile Day NYC, I applaud the organizers (especially Dan Mezick and Joe Krebs) for combining planned talks and open spaces in a one-day event. Even keynotes were limited to 20 minutes in Boston--letting us whet our appetites on ideas from many different speakers. Following the planned talks, we had afternoon open space sessions that attracted a huge number of topics and participants--as well as a sense of belonging!