I’ve been talking up my Lean Coffee Conversation Starters since the early part of this year, mostly in face-to-face discussions. The decks I have been envisioning would each contain the best and most popular topics from my over three years of hosting local meetups, as well as a number of sessions up and down the West coast and throughout the Midwest.
Once summer hit, I poured much of my time into producing these decks: cultivating the right questions, getting the design and layout right, and running tests with printers and lean coffee participants.
I’m extremely happy to announce that the campaign to produce these cards decks has officially begun on Kickstarer. As of today, the doors are opened for anyone to examine these products and support their production.
Being out of work is a blessing and a curse. On one hand, having long stretches of time to focus thoughts and efforts on pet projects and learning is amazing. With clear vision and consistent effort, one can make tremendous progress in achieving high-value goals. On the other hand, you’re still out of a job.
The search could surely be going better – summer vacations really slow down the hiring process – but it’s at least moving, giving me hope that I’ll land in a great spot. And on the plus side, I’d already planned to have some time off this summer, so I had a bit of savings put aside. Once I became free, I let my inner circle know of my availability and began sending out my updated resume.
Once this transition from the old chapter begins, I’m able to focus not only on my new career goals, but also make a dent in real and actionable work to “sharpen my saw”. As you review my progress, reflect on your own methods and projects. I’d love to hear what others things passionate agilistas do to make positive strides in their personal and professional growth.
What I’m doing with my time
Blogging – My first priority has been to give attention to my own personal blog. I’m not a very consistent writer, and I’m not extremely confident in the voice or style I employ, so I set an aggressive goal of one post a week. Now nine weeks without work, I’ve produced enough posts (this being number eight) to be pretty close to that aspiration. For me, posts are reflections of my working philosophy and summaries of experiences I’ve had on the job. They allow me to inspect and prepare to adapt my approaches to coaching and working with teams. As of this writing, I’ve got another eight posts pending – some started as drafts, others mere ideas on a backlog.
Product Development – The Lean Coffee Starter Deck is another important project I’d had in mind for a while. I’ve been hosting local meetups twice a month for over three years, with little downtime. Since the earliest sessions, I’ve kept a running list of all topics the groups brought up. As you can imagine, there’s quite a lot of repeated questions over the three years, so I affinity-grouped these and created two decks (54 pre-printed cards each) of the most popular topics. I’m preparing to put together a kickstarter campaign (just need to finalize a nice video), but you can have a sneak peak here (link).
Reading – What’s a summer without some good reading? I now begin (after morning meditation) and end most days with a chapter or three from either my long-ignored pile of books or one of the many new selections I recently acquired. I’m currently juggling Reinventing organizations (Laloux) and Leadership Agility (Joiner and Josephs), and I’ve already finished off quite a stack: Essentialism (McKeown), No Asshole Rule (Sutton), Three Pillars of Agile Quality & Testing (Galen), Management 3.0 (Appelo) and Art of Agile Development (Shore). In the queue is Fritjof Capra, Kent Beck, Peter Senge, Ron Jeffries and a few others. (I do my best to model reading to my nine-year-old, but she’s having none of it; instead enjoying her summer break surrounded by her little pony toys.)
Volunteering – A few activities (gratis) to keep me insanely busy but also connected to actual humans. First, I’d presented a lunch-and-learn at the L.A. office of TEKsystems in June. An hour of Agile and Scrum to a roomful of recruiters – hopefully I did some good to the world of job-seekers. Next, I’m once again helping organize the Agile Open Southern California (link). If you’ve attended in the past three years, those new emails you’re receiving are from me. (You’re welcome!) I’ll be pulling other duties for AOSC as well, perhaps holding space alongside Diana and others. Finally, I show up at a number of Dr. Dave Cornelius’ 5Saturdays (link) events to share techniques of Lean Coffee and other goodness with high school kids and their adult instructors. Good times.
Podcasting – Of course there’s still the Agile Coffee Podcast to maintain. We’re up to episode 32 published to iTunes and Stitcher, and I’ve got three more recorded and in the editing pipeline. This project is among my most self-fulfilling as I get to talk with passionate agile minds about topics of great interest. I average a new 45-minute episode posted every two weeks with no signs of abating – so please subscribe and rate us on iTunes. And holy cow, WOW, I was recently interviewed by Ryan Ripley on his Agile for Humans podcast, episode 8 (link). Ryan’s show has quickly become one of my faves (I listen to many other terrific Agile shows), so it was quite the honor to appear with him there. (And guess what? Look for an Agile Coffee for Humans crossover in the near future.)
Industry Events – Back in June I participated in two great affairs: Scrum Day San Diego (link) and Scrum Alliance’s Scrum Coaching Retreat (link). Compelling voices and good friends gathered in by the waterfront in San Diego, and I talked with many Scrum heroes there for podcast episode 32 (link). The retreat in Seattle was a particularly rewarding and welcomed opportunity to escape the grind of the home office and meet truly awesome people. The project team I joined was engaged in building out a Coaching Dojo, an undertaking that made great use of research that I’m doing in the area of pair-coaching. Teammates were engaging, and they inspired me to raise my game. What more could you ask for?
What’s next for me?
It’s hard to deny that I’m keeping busy. I feel that I’m striking a good balance between personal/professional development and community involvement. I believe in the value of giving, and I’m grateful for all I get in return. Still, I feel driven to do more. There are a few presentations (link) I want to revise or develop, plus a couple videos I’d like to produce. Then there’s the kickstarter project I mentioned – really stoked about creating card decks to help coaches, scrum masters and other agilists create conversations. And I have an idea for another podcast, one focused narrowly on the topic of servant leadership.
Is it enough? I can’t answer that. No one can. But it certainly gives me new experiences to discuss in the future. And focusing on self-improvement keeps me from sinking into a victim-like mindset of pity and self-loathing. It helps give me confidence to have honest conversations with colleagues and potential employers, unashamed of the duration between engagements.
I’m curious to hear what others do in times like this. Leave a comment below or hit me up on twitter (@AgileCoffee). What keeps you busy improving? How do you sharpen your saw?
A colleague approached me recently with a request. He was about to meet with a new division of his company and lead transformation activities at the team level, so he wanted advice on the best agile games to include. As usual, I turned my advice into a blog post so that (hopefully) others can benefit from my experiences.
We all know that games are fun and that humans are hard-wired to play. Like most coaches, I use games, simulations and other learning activities fairly liberally in my engagements, but I want to be clear: I never play games just to play games. There has to be a need for taking an activity out of my toolbox and introducing it to the team.
Activities that get us out of our chairs are generally good. The body moves around and gets blood up to our brains. It gives us a chance to get away from the book-fed material and internalize the lessons. All good points, but still we often sell the benefit of game-play short to say something like “this section of the training material is dry, so let’s put a game here”.
Including a game or simulation should be thought of as a “teeing up” of the learning objective. Another way to say it: the game creates an effective canvas for painting the picture. It prepares the learners to “get” the message. Just as I wouldn’t force a game into my curriculum for the sake of having a game, I also wouldn’t ignore the opportunity to reinforce the training objective with a valid learning activity.
My favorite games for teaching lean and agile concepts
Learning Activity – Exercises that engage people, helping them reach a conclusions and assist in learning (thereby increasing performance).
Problem-Based Learning – Learning activities which require participants to solve problem relating to a specific subject.
Simulation – A problem-based learning activity that has components which cognitively mirrors the environment, methods, problems and practices of the learning domain.
Game – A simulation which has rules of play to either win/lose (finite game) or to keep the game in play (infinite game).
Jargon aside, here’s a list of games:
Buy a Feature – Teaches feature prioritization
Best played in groups of 3-8. Takes 10-15 minutes.
Each player receives two items: (1) a handout with a menu of features and their prices (2) a sum of play money. (Features can be anything: items to have on a vacation, goals of a two-day training, benefits of a high-functioning team, etc.) The play money should contain a variety of denominations. The sum total of all players’ money should be less than the total of all feature prices – this introduces scarcity and forces the team to make trade-offs because it’s not possible to purchase all items on the list.
Players take turns using their individual sums of money to but the features they deem most valuable. Once players have spent most of their funds (either they don’t have enough individually to make another purchase or they don’t value what’s left on the menu to buy anything else), the group will pool the remaining funds and discuss what to buy from the remaining items.
Best played in groups of 6-20. Takes about 2-3 minutes per round, including instructions.
Start with all players standing to form a large circle, facing inside the circle. Everyone moves in close (shoulder-to-shoulder) and reaches their left hand into the mix, grabbing the left hand of another player (not their immediate neighbor). Next, reach in the right hands and grab a new person’s right hand (again, not the neighbor next to you).
While keeping all hands connected, the group then proceeds to twist and turn out of the scrambled knot they’ve formed. After a minute or more, the group should once again return to a large circle of people clasping hands.
Remember: Safety first. If someone is getting squeezed or about to trip, it’s better to release a hand or two tham to end up with broken bones or sprained thingies.
It’s fun if two or more groups of equal number compete to see who can “untie” themselves first.
Multitasking [ link ] – Shows how multi-tasking reduces effectiveness.
Played individually at a table or whiteboard. Playing two rounds takes less than 5 minutes.
Each player needs one sheet of paper (or on a whiteboard) and something to write with. It’s best if they each have their own stopwatch (phone, duh), but the facilitator can monitor time for the group if necessary.
The paper will have three blank columns to be filled in, and the task is the same for each of two rounds. Column one will contain the letters A thru J; column two lists the digits 1 thru 10; column three will have roman numerals I thru X. All finished columns should contain their ten elements in their proper order.
The difference between the two rounds comes in how the columns get filled out. in round one, players must write one letter, followed by one digit, followed by one roman numeral, then repeat. In round two, players should write all letters first, before moving on to the digits, and filling in the roman numerals last.
Each of the two rounds is timed, and we see that the multitasking of round one consumes a greater time than the focused task completion of round two.
Pair-Origami (link) – Illustrates the importance of face-to-face (vs. distributed) communication.
Need total of six or more players. Takes about 10-15 minutes.
Divide the players into three groups (A, B & C). Players for pairs in each group. Each pair consists of a folder and a PO (product owner) or manager. All folders get a single sheet of 8.5×11 paper, and each PO/manager receives an instruction page (download link).
Players in group A sit side-by-side. Only the folder player may fold the origami, but both partners may see the instruction sheet.
Players in group B sit face-to-face. Only the folder player may fold the origami. The PO/manager may give feedback but may not show the instructions to the folder.
Players in group C sit back-to-back. Only the folder player may fold the origami. The PO/manager may read/explain the instructions to the folder but may not see the origami as it’s being folded.
When the timer starts, all pairs get to work. When a pair completes their origami, their time gets recorded. The facilitator may (mercifully) call time when it’s apparent that pairs in group C are about to explode.
Penny Flip game (link) – Emphasizes value of small batches and process improvement.
Teams of 8-10 gathered around a table. Four rounds of play takes about 20-25 minutes.
Need a roll of pennies (other coins or cards may be substituted)
(more description coming soon)
Ball Point game (link) – Teaches teamwork and process improvements.
One large team (bigger is better – up to 30 is okay). Four or five rounds of play takes about 15-20 minutes.
Need 20-50 balls (balled-up paper works okay) and a large, open space for team to move around.
(more description coming soon)
These are just a few links to a tiny percentage of games available. For many more activities, I recommend joining the aforementioned Google group: Agile Games as well as visiting some of the great sites that aggregate these invaluable learning activities (eg. TastyCupcakes.org).
A few years ago I came to realize that I am passionate about serving others. I’ve probably been aware of this sub- or semi-consciously for most of my life, but it wasn’t until I became a student of the Agile principles and methodologies that I learned the name for my greatest calling: Servant Leadership.
a mindmap of sorts, produced shortly after attending Tom Looy’s session at SF Agile 2012
Over my years working with and “managing” teams, I knew that traditional models of leading people were misaligned with how I was wired. The expectations described by business school (in the general sense) and my supervisors had always left me wanting more – having enough self-awareness to recognize the hard time I had with command-and-control personas. Once I became immersed in Scrum and Lean practices, I began to understand that Servant Leadership was the model I’d been operating in. My methods and inclinations began to make sense and get validation.
In June 2012 I made my way to San Francisco Agile 2012, a conference that became the bedrock of my own ideas of building an Agile community. There I met Jim Benson, Steve Blank, Tobias Mayer, Ainsley Nies and many others who have greatly influenced the way I learn and practice. (Those three days deserve their own post…) But one session stands out more than any other: Tom Looy’s workshop on “The Path to Servant Leadership”.
one version of Tom’s presentation (pdf)
All this preamble is leading up to me sharing my own path, but first I want to explain why I found the exercise valuable. As I said at the top, I felt throughout my career (if not my whole life) that I’d been called to serve, and that calling overlapped with my role as a leader. But not until I sat down and identified the discreet steps along my path did it become clear to me the extent of this self-identification. Being able to look at the arc of my development became terribly empowering, and the act of uncovering these past roles was the vehicle to my epiphany.
I recommend that all who call themselves agilists take the time to document their own path. Servant Leadership is truly at the heart of what we do leading teams through challenging transitions and powerful conversations. By making ourselves explicitly aware of the steps in our own transformational journeys, we keep our core values at the front of our minds, confident of the experiences that brought us here.
What follows is my personal account of this exercise. It may resemble a list of “jobs”, but these activities are not the typical fodder for my resume or LinkedIn profile. Instead, they add depth and complexity beyond me as a mere “job applicant” or anonymous cog in some bland organization.
Below is a timeline highlighting some roles that shaped my path of servant leadership:
Altar Boy – Growing up Catholic, perhaps my first encounter with the opportunity to serve came via the local church. Both my brother and I became altar boys in the late-seventies and stayed on through the mid-eighties. Covering duties at Ss. Cosmas and Damian parish, we aided the fathers and brothers as well as our neighbors. (I wonder if my mom still wishes I’d become a priest?)
Carrying Kevin’s books – While in middle school, I’d befriended a classmate named Kevin who had difficulty walking. (Though I don’t recall his specific condition, it prevented him from fully extending his arms/legs.) Carrying his own books up and down the busy halls was problematic, at best. In seventh and eight grade, Kevin and I shared a common class schedule, and I was happy to lend a friend a hand. Oddly, I recieved a commendation award each year for doing something that I’d considered a basic act of helpfulness.
High School theater – Drama club provided an outlet for creative expression, not to mention teen-aged angst. As a freshman I’d landed a speaking role in Pippin, and as a result I was the envy of my 9th grade cohorts. Yet in my sophomore and junior years, instead of auditioning for another high-profile role, I’d volunteered for the position of assistant director. All around me, other students enjoyed their spotlight, while I worked silently coordinating schedules and projects. The satisfaction on opening night was no less sweet.
Peterson Sound Studio – At university, I’d concentrated my undergrad years in studio recording and audio engineering. Persuing an MFA degree in filmmaking, I immediately found a job working in the sound studio: syncing mag stock in the many playback machines, supervising voice-over work, and occasionally performing a full-on master mix of other students’ 16mm masterpieces. As well, I’d served as the location sound recordist on no fewer than 27 films over a three-year span. While other students jockeyed for the title of director or cinematographer, there I was capturing and mixing the sound of their stories.
Casa Nueva – Every film student needs a steady flow of cash to support their habit, and I was no exception. While still an undergrad, I’d landed a job washing dishes at the Worker Owned Restaurant Corp., dba Casa Nueva. When I became part owner with thirty-some others, I’d received a crash course in egalitarian work dynamics. I’d worked my way up to operations manager and discovered that I was talented in the art of facilitating our monthly meetings. Everyone had a chance to debate each topic, ranging from new menu items to what color to paint the walls. When a particularly tense meeting loomed and an even-keeled temperament was called for, the co-owners demanded I be facilitator.
Teustepe, Nicaragua – Many causes came and went, but one of our passions was developing and maintaining relations with a sister city in Central America. After our group helped build a library in this small town 700 miles away, Bob Ramsak and I received a small grant to document how Nicaraguans (and Teustepeans, in particular) were impacted by the policies of Structural Adjustment. The pair of video documentaries we produced for public television in 1993 have also been used in schools.
VISTA volunteer – National service came next, and I contributed my media/filmmaking skills to Rural Action, a not-for-profit economic development agency serving the Appalachian region of (mostly) Ohio. An offshoot of Americorps, the VISTA program invests in nonprofit and faith-based groups, providing difference-making volunteer experiences across the country. In addition to capturing videos/photos to raise awareness of our many programs (river cleanups, community center renovations), I helped as a carpenter, gardener and chicken processor.
Assistant Language Teacher – With master’s degree in hand and experience making websites, I could have easily joined the movement of the mid nineties to Silicon Valley. Instead, I went to Japan. The salary of an ALT on the JET Programme wasn’t much to speak of, but the challenge of living overseas and teaching English in rural schools was formative beyond imagination. I was the first foreigner most of the children (an adults) in these villages had ever met, and I was humbled to be considered a sensei by mere virtue of the language I spoke.
Community Television Network – Back in the U.S., I spent a few months working on films in SoCal, but quickly found that it wasn’t the lifestyle for me. I returned to the midwest and started my IT career in earnest. Still, the allure of working on a set was strong, and I soon began volunteering with CTN, the local community television station. Not much in front of the camera; my desire was to support others behind the camera – or by hanging lights or holding the boom mic.
Toastmasters – Public speaking had always been a passion of mine, so joining was a no-brainer. It was in taking up leadership responsibilities, though, that I began to give back. Serving whatever role was necessary became my mission. I even formed a chapter in a former workplace in order to help other PMs and IT workers develop their own speaking/presentation skills. I guess that I was serving the corporation (not just individuals) in that sense.
It’s not a comprehensive list, and I find more things to add practically each time I reflect on it; but it always serves to remind me of where I come from and what I’m called to do.
In addition to our regular podcasts, I host a couple lean coffee meetups every month where we get people dropping in who are less experienced yet very curious about Agile methodologies and lean principles. One common theme at these in-person sessions centers around the role of a ScrumMaster, and it’s a topic that engages us old-timers just as much.
Many of us have been serving as ScrumMaster of our teams, but the job description changes for every workplace and every team. For this reason, I trust the responses from my peers; still, we’re often left with more questions than “correct” answers. Here are a few of the questions with some of my observations.
What is a ScrumMaster?
There are many good starts at a definition, but I like Mike Cohn’s for its succinctness:
The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum. The ScrumMaster is often considered a coach for the team, helping the team do the best work it possibly can. The ScrumMaster can also be thought of as a process owner for the team, creating a balance with the project’s key stakeholder, who is referred to as the product owner.
One key responsibility of the ScrumMaster is to protect the team from outside interruptions, requests that could potentially derail the team’s focus and increase its work in process (WIP). In this way, the SM is like a sheepdog guarding the flock. In fact, Ken Schwaber uses this analogy often, saying it’s the SM’s role to keep the wolves away.
Another aspect to the role is to remove impediments, and the best ScrumMasters are those who have the technical or political know-how to recognize a roadblock early and see that it gets removed. Speed and tact are two skills that they brandish, skills that improve the more they are yielded.
Does a ScrumMaster need to be dedicated to the role 100% of their time?
The saying is that a good ScrumMaster can take on two-to-three teams, but a great ScrumMaster can only handle one. There’s room to have a debate on this question, but my feeling is that if you’re working with only one team and you find yourself with too much idle time, you may not be looking hard enough. Either that, or the team is mature enough to no longer require a full time ScrumMaster.
I find both these lists comprehensive and extremely useful when discussing the work of the ScrumMaster. In fact, I built my own assessment primarily from Bernd’s article. (Merci beaucoup to Fabrice Aimetti for translating the document into french: Evaluation des compétences du Scrum Master.)
If you can honestly say that you’re scoring eights or nines across each of the rows on the assessment, then maybe you are working yourself out of a job. (That is the goal, after all.) It’s likely that your team has benefited to the point that they are mature enough for you to look for another team to lend a helping hand. Which leads nicely to the next question…
Can another member of the team also be an effective SM?
My own opinion is “Sure, why not?” If the team member – and the team – are willing to try it, I wouldn’t discourage this automatically. It ultimately depends on the maturity of the team and the willingness of one contributor to give of himself to serve others. But keep in mind: if the ScrumMaster is committing to work in the sprint, their bandwidth (and motivation) to help clear impediments or pick up other responsibilities (eg. evangelize Agile outside of the team) is at a substantial disadvantage.
I was a coach in an organization that did encourage team members to try their hand at scrummastering (albeit, out of necessity at first). It’s a great way not only to cross train new skills, but also to strengthen the Agile culture within an organization. Just make sure that everyone is on board with the decision – it should never be forced upon a team member. (I still believe that a dedicated SM trumps anyone who is splitting their time with multiple duties.)
Does the ScrumMaster need to be technically proficient with the software stack?
I don’t believe the SM needs be technical at all. They can maintain a “beginner’s mind”. It helps to have someone who is terrifically unbiased in many situations – especially if they’re focused on guarding the process. That eliminates a potential conflict of interest.
On the other hand, some familiarity with the technology can help when clearing impediments. Anticipating the needs of the team based on historical relationships with the ADLC are certainly valuable.
But the argument can be made that being too knowledgeable is bad because then the SM would be tempted to inject herself into discussions of how, and this could lead to (or be interpreted as) dictating to the team what or how to do their work. Smells of micromanagement arise.
Do they need to understand the product inside and out?
Similar to the need to be technically adept, is it important for SMs to be experts on the product they’re delivering? Again, I can see two sides to the debate. On one hand, that’s the role of the Product Owner, and being completely free of bias can prove to be a large advantage for the otherwise engaged ScrumMaster.
However, everywhere I’ve worked as a ScrumMaster or coach, I realized tremendous value in understanding the product at a moderately deep level. It helped (again) anticipate needs for communication and dependencies, and the PO usually appreciated having someone to back her up from time to time.
So, as they say, “try it – you might like it.”
What other characteristics make an effective ScrumMaster?
One of the most powerful traits is courage. Call it “having kajones” or simply “being comfortable in delivering the message”, this skill sets the effective Scrum Master apart from the many who just go “by the book”. However, willingness alone will not get you there; to be most effective you must also possess a large amount of tact. Being able to deliver news without alienating your audience is critical. (As Ken Schwaber reminds us, “a dead sheepdog is a useless sheepdog“.)
So don’t be afraid to step onto the soapbox. It’s not “un-Agile”. In fact, it’s not only appropriate, but demanded. Remember that you’re more empowered than you think.
Situational leadership is a related skill to be mindful of. By speaking up and identifying that the team is off track, you can provide solutions; but always remember that team needs to own them. When team is too dependent on the ScrumMaster, that could be a learning experience. Maybe the SM should walk away and let the team figure out the path out of the woods.
One final characteristic I’ll mention is to be a continual learner. Our landscape is always changing, and we need to keep abreast of the ebbs and flows. By continuously checking our own orientation, we can become more trusted to guide the team through changes and challenges.
Additional Resources
Don’t just take my word for it. As I said, sometimes there are no right answers – that’s why we continue to have the conversations at the lean coffee meetups. And here’s a list of pretty good opinions, well worth checking out to help inform your own opinion:
Back in March I led a pair coaching workshop at Scrum Day Orange County 2015. My goal with the session was to examine a few pair-coaching roles, share a list of competency areas for Scrum Masters, and use dominoes to demonstrate viable situations where pairing will help the coach, her team, or the larger organization.
No matter how good we are, we still can’t learn or do everything on our own. Whether you’re a Scrum Master, product owner or other member in an Agile workplace, you should consider using pair-coaching to raise your skill level, create positive change on your teams and improve relationships throughout the organization.
When I was approached to make a presentation on pair-coaching, I began asking around for comments. It was important to me that participants left with something tangible and valuable. I began building the content as a powerpoint deck, but early feedback (and my post-lunch time slot) suggested an interactive workshop made more sense.
Roles in Pair-Coaching
The goal of the workshop was to get participants thinking in terms of the many ways to use pair-coaching at the workplace. To do this, it was important to share the five pairing roles that I previously discussed:
Trainer / Observer
Driver / Navigator
Yin / Yang (I’ve renamed this role from “Good Cop / Bad Cop”)
Kohai / Sempai
Co-Learners
By introducing the five roles, I was able to give specific contexts in which to imagine using pair-coaching. (The handout above offers a summary of the five roles.)
* I owe much to Yves Hanoulle, a true creative collaboration agent, for his work identifying most of these roles (I am really just mucking with them). Yves has been a strong proponent of pair-coaching for many years, and most of the research I do on the subject turns up his name.
This assessment I put together was taken primarily from Bernd’s list of 42 tasks, though I overlaid the “grading” rubric to meet the needs of this game. (A big thanks to Fabrice Aimetti for translating this into french: Evaluation des compétences du Scrum Master.)
In the workshop, I ask the participants to give themselves a grade for each competency – from “0” equating to “no experience” to “3” meaning “expert”. They can sum the numbers across each row (competency group) to gauge what areas of coaching they’re good at and which could use improvement. (The point isn’t to be too critical here, but to have some grounding for the game.) The range of row-scores is zero (0) to nine (9), identical to the range of numbers on my dominoes.
Rules of the Game
Finally we get to the game itself. Each participant has a double-nine domino tile at their seat when they come in the room. They are asked to match one of their numbers to pair with another participant – this is done to get them out of their chairs and meet “random” people in the room. Example, if my domino has a two (2) and a five (5), I find another person with either of those digits.
When they form pairs (eg. both have a five (5) on their domino), they assume expertise levels based on the other number not used to match up. In my two and five scenario, I would use two (2) as my expertise level because I used the five (5) to meet another five. (It’s a pain to explain, but participants caught on quickly.)
Each pair then talks through a case of which roles they might play for a hypothetical scenario. For example, if a “two” (novice) is paired with an “eight” (expert), they might play out a Driver / Navigator situation. If the numbers are close but low (eg, 3 & 2), the scenario might be Co-Learners; and a 7 & 9 combo may yield a Good Cop / Bad Cop storyline.
Let me say that this early iteration of the game could certainly use some adjustment. I’m open to feedback even to the point of removing the dominoes altogether. Having said that, however, it seemed to work very well to stimulate role-playing and discussion in the workshop. So… success!
Below is a video of the session. The workshop begins by reviewing the five roles, and we start playing with dominoes approximately 22 minutes into the video. I am again grateful to Scott Dunn of Rocket Nine Solutions for the support, and to Cliff Rosa of Rosa Media Productions for the recording – thanks to you both!
I hope that you try this game and I welcome feedback in the comments here on this page or to me on Twitter at @AgileCoffee. Best of luck in your pairing!
Most of us work in teams. We go to work and see the same folks each and every day. We check in when we fill our coffee mugs, and we offer a “see ya tomorrow” when we leave. In between, we work with them – either as a group, in pairs or quasi-independently with occasional interactions. We might spend more waking hours with these people then we do with our family and non-workplace friends.
But how well do we know them?
If you’re working with or on a team, you have a vested interest in getting to know each other. Doing so develops trust, openness, respect, courage and commitment – many of the values we prize in Scrum and Agile. So here’s an exercise that you might consider: throw a “Bring Your Self to Work” Day. (I’d seen this listed as a topic at an open space, but I wasn’t able to attend, so you’re stuck with my imagination.)
Before you laugh it off and say “don’t we do this every day already?” or roll your eyes at a seemingly trite concept, hear me out. I’m not about to preach being fully invested in being 100% present in your own daily activities (though that’s a noble goal). Rather what I’m proposing is a team-based exercise, whether on-site or off.
In fact, despite the name, you might opt to meet at a restaurant or other non-work location. Holding an event after working hours sounds ideal, but it could be hard to pull off if co-workers have their own family- or commute-based constraints. And given the choice of having the whole team participate vs. a convenient time for most of the team, I’d choose the former.
Here are a few suggestions for pulling this off.
Keep it Social – meeting at the office always carries connotations of work. Heck, even the word “meeting” is so charged that you might consider referring to the gathering by another name. If budgets allow, consider social activities such as bowling or karaoke – making sure, of course, that the activity is something that all are able to take part in. And even if getting out of the office isn’t feasible, try to find a space far enough away from your work area that there aren’t the normal distractions.
Share a Meal – something we all have in common is the need to feed ourselves. Whether you and the team decide to brown bag it out at a picnic table or in a bright conference room (preferably with natural light), or you head to a food court or restaurant, the gesture of “breaking bread” together is powerful and commonly accepted. If you splurge and have food brought in (bonus points if it’s not pizza), odds of participation increase greatly 😉
Start Conversations Small – setting things in motion with a firm demand for all to open themselves up completely is the quickest way to kill the mood. Instead, begin by asking small, basic questions like:
what movies are good this season?
what was your favorite thing to do as a kid?
what was the worst thing about school?
hobbies / books / interests / etc.
You can be creative – more creative than I am – but the point is to get people talking about themselves, maybe even laughing with each other. When this happens, we start to find unexpected connections and create or reinforce our bonds.
I’ve done this with just about all my teams, and my favorite questions usually relate to our childhoods. Living on the west coast, I find that these teams are so diverse in terms of where they’re from and when they grew up, so the stories from our early years are always filled with new things to learn. Many remarks of “Oh, I remember that/those!” pepper the conversations, and people really open up and respect others more.
Ask a Keystone Question – if and when the team is comfortable with the conversation, I encourage you to ask a deeper and more meaningful question, something that gets to the heart of your SELF. It doesn’t have to be too deep or serious, but it should allow for each member to see that they’re truly part of a trusting group. Something along the lines of “what’s one thing you have (talent, interest, experience) that you haven’t told anyone at work?” I’ve heard answers ranging from “I used to sing opera” and “I’ve always wanted to visit Nepal” to much more intimate stories of personal loss or achievement.
Again, the point isn’t to put people on the spot and be too vulnerable, but to show that it’s safe to share with this group, to show a bit of our true selves. You can’t (and shouldn’t try to) force connections and respect, but these connections are meaningful and usually happen as a result of honest and open conversation.
Treat the Team as a Family – after the day is over and we’re back in our work routines, it’s very important to keep these bonds alive. Treat your team as an extended family. You don’t have to bring up the stories that were shared, but try to keep that emotion and connection with your co-workers as often as possible. It enables stronger, more natural collaboration and clearer communication. When appropriate, celebrate individual achievements as a team and help each other out with personal goals by occasionally checking in.
And don’t make this a once-a-year activity. Anytime the team changes adds (or loses) a member, or if the group needs a collective pick-me-up, break out the invitations to another “Bring Your Self to Work” Day.
Agile coaching demands many skills of the practitioner. In addition to being conversant in common agile processes, we are also called to serve as teacher, facilitator, mentor, counselor, negotiator, and leader. Of course, this is a partial list; there may be no limit to the skills identified as valuable to our coaching profession.
Where did you learn these skills? If you weren’t born with these skills or have them injected into your being, how did you acquire them? Books, videos and training courses can help, but on the job is perhaps the quickest and most lasting method. Did you have someone training you how to train? How to facilitate or lead your first team? Chances are that you were thrown into the fire like most of us.
Now imagine that you did have a mentor to guide you along your path, someone to show you how to lead a retrospective and offer advice when your team just stared at you dumbly. I’m not talking about your CSM instructor or your boss who gives you encouragement once a week, but an honest-to-goodness partner with you on the job.
That is one pattern of pair-coaching.
Here is another example. Let’s suppose that you’re involved in a transformation effort. You and a colleague want to introduce agile methods and scrum practices that will represent a different way of working, but some team members want nothing to do with this – for them the medicine is hard to swallow.
This is a case where your partner might play a more “prescriptive” role, clarifying the need and structural changes with little emotion invested in her delivery. Your role as the counterpart would be to offer deep empathy – providing an open ear or a shoulder to cry on – while also offering a softer interpretation of why the organization is trying this change. You, the “progressive”, help the transition to this different mindset.
More than a “good cop / bad cop” relationship, the Contrarian pattern allows for divergent viewpoints to both be expressed equally.
Pair-coaching is not anything new in the workplace. You may be practicing one or more patterns without being aware of it. Once made visible, the value of coaching in pairs should become apparent.
There are many patterns that pair-coaches can fill. A few that we will examine include:
Trainer / Observer
Driver / Navigator
Contrarian (Progressive / Prescriptive)
Senpai / Kohai (mentor / protege)
Co-learners
Trainer / Observer
With new teams adopting agile practices, it’s almost certain that training will be necessary. Often a trainer works alone; showing up to set up the room, greet arriving participants, communicate & demonstrate the concepts, take questions and mind the agenda (including breaks, meals and other time-boxed events). That could be quite a lot to handle, especially if the audience is large or varied in their prior experience with (and reception of) the topics.
With a partner, much of the burden is eliminated from the primary trainer’s responsibility. (For non-training events, a co-facilitator becomes useful for the same reasons.)
In this pair-coaching scenario, one coach may lead the training while the second may:
observe to offer feedback later
tag-in and lead other slides of same training
be called upon as an expert (SME) or for her experience/validation
scan the audience for outliers / those needing attention
Driver / Navigator
Han had Chewie. Michael Knight had KITT.
This pairing closely resembles the Trainer/Observer, but it can happen outside of the full team environment. In other words, an activity with only the coaches participating (e.g. drafting a retrospective agenda) can benefit from a second pair of eyes. Similar to how developers may engage in pair-programming, two (or more) coaches can make light work of otherwise daunting tasks, saving time, catching errors and preventing rework. A Product Owner / ScrumMaster relationship may make use of this dynamic during (for instance) a story writing exercise or preparing for a complex backlog grooming session.
To extend the navigator role a bit, an internal coach may pair with an external coach to provide a much needed map of the terrain. When outsiders come to an engagement, the organization may be charged with mistrust and fear (why else would the outsider have been brought in?). Having a “man on the inside” helps to get the “lay of the land” with regards to the organization’s culture and politics, potentially helping to avoid the minefield altogether.
The Contrarian
The earlier example showed one instance of this common usage. As a coach, you may find there are times when the team (or one member) resists what is being suggested, even being demanded. In these cases, try having one partner offer a prescriptive approach, while the other provides counterpoint. If there’s a bitter pill, there should be empathy.
Additionally, when constructive conflict is habitually missing from team discussions, introducing an alternate viewpoint may encourage necessary debate. Two partners can take opposing views in the effort to model a constructive dialogue.
Senpai / Kohai
The Japanese culture is rich in traditions of well-defined social behaviors, and the senpai/kohai relationship is one of the most popular. Similar to a mentor / protege (or a senior / junior) pairing, this role can be thought of as a more formalized “buddy system” to be used when newer members join an organization (eg. company, school, sports club). The senpai serves as a mentor of sorts, showing his charge the ropes – guiding, protecting and teaching. The kohai offers his full attention and respect to the senior, even though the two may be very close in age and status.
This can be a very beneficial role to play as an agile coach, whether you are the mentor of the mentee. Thinking back to your first days on the job, did someone help you with onboarding, telling you how to navigate the HR paperwork, where to submit the expense reports and what time is best for booking the meeting rooms? In Japan, the two may bond over dinners or drinks engaged in casual conversations, and the senpai/kohai relationship often lasts many years or decades, usually well past the individuals’ tenures at the organization.
Co-learners
When the subject matter is new to both participants, or the terrain is dangerous, each coach helps the other understand in very short feedback loops. Much like infantry soldiers on a dangerous battlefield, high-performing teams offer encouragement to each other as they make their way through uncharted and challenging territory.
The experience levels of both participants are often close in this role, neither being expert in the new subject or working environment. This type of dynamic may happen when we pair up to do exercises at a conference or other training session. If you’ve ever joined a coaching circle, your assignment could call for you to relate your experiences to a partner who’s job might be to actively listen and understand before swapping roles.
Much in the same vein as saying “two heads are better than one”, I think of the parable of the blind men describing the elephant. Each of us has our own perspective on things, but by listening to and learning from each other, we help increase our own knowledge bit by bit.
What’s Next?
Those are five of the roles that can be played by coaches who work in pairs. It’s likely that there are more, whether obvious or not. The goal of this post was to define these roles so that we can have a common set of terms to use when discussing how to become better coaches by working in pairs. Although I believe that there is very large value to be discovered by pair-coaching, I am not calling for every coach to work with a partner on all projects at all times.
Over the next several months I will be attending Agile Opens (#AONW begins this week), Coach Camps (I will host ACCUS in Irvine) and a Coaching Retreat, and at each event I will do my best to engage others in this dialogue. It’s my hope to use the matrix below to see where we feel each role fits best given the situations I just described. If you see me there, feel free to pair up with me!
At the latest lean coffee, we had two cards with a similar question: how do you neutralize the bad apples / stop the eye-rolling? Later that night I remembered something I thought might apply, so below I try to craft it into a parable.
(This post offers a huge tip of the hat to Robert Anton Wilson whose first chapter of “Quantum Psychology” describes a similar “parable about [this] parable”. Chapter nine of “The Trial” by Franz Kafka includes this central tale which Wilson treats as zen koan.)
There was once a young scrummaster who had achieved some early success. His new team, however, offered only resistance to his words. Throughout his first two sprints he employed many methods to convince or cajole the team to change their perspective and accept agile / scrum. He offered empathy, used silence and questioning, provided studies and “facts” to support his claims. The scrummaster grew impatient and threatened the team, but they simply laughed him off.
Finally he swallowed his pride and approached the agile coach. She offered the scrummaster a cup of tea.
“This team is impossible!” the scrummaster exclaimed. “Why won’t they buy-in?”
“Let me tell you a story,” the coach offered. After sipping her tea, she began:
A man from the countryside comes up to the door of the Law, guarded by a doorkeeper, and asks for entry. The doorkeeper says he can’t let him in to the law right now. The man thinks about this, and then he asks if he’ll be able to go in later on.
‘That’s possible,’ says the doorkeeper, ‘but not now’.
The man waits and grows older. Any time he asks, the doorkeeper rebukes him. The man offers bribes to this doorkeeper, and the guard accepts each offer saying as he pockets the money ‘I’ll only accept this so that you don’t think there’s anything you’ve failed to do’. Still, the man is not allowed entry.
Over many years, the man tries time and again to get inside. In the first few years he curses his unhappy condition out loud, but later, as he becomes old, he just grumbles to himself. He becomes senile…
Finally his eyes grow dim, and he knows doesn’t have much longer to live. In the moment before he dies, he brings together all his experience from all this time into one question which he has still never put to the doorkeeper…
‘Everyone wants access to the law,’ says the man, ‘how come, over all these years, no-one but me has asked to be let in?’
The doorkeeper can see the man is near death. ‘Nobody else could have got in this way, as this entrance was meant only for you. Now I’ll close it forever’. As the door is slammed shut, the man expires.
The scrummaster all but spits out his tea. “He died?” “Indeed,” the coach assured.
Another sprint passes, and the scrummaster returns to the agile coach, finding her in the lounge outside her office.
“I’ve considered this story from many angles, and I have questions. If the door existed only for this man, why was he not allowed to enter? Why was the door left tantalizingly open? Why did the guard close the door only when the man was too old and weak to enter?”
As the coach poured two cups of tea, the scrummaster continued. “Am I the man in this parable? Is my team the majesty beyond the door? Who is the doorkeeper?” Ignoring his tea, the scrummaster implored “Please. Explain to me the lesson of this dark parable.”
“I will explain it to you,” the coach promised, “if you follow me into my office.”
The coach stepped into the room, quickly turned, and slammed the door in the scrummaster’s face.
At that moment, the scrummaster experienced enlightenment.
Does your IT organization make a practice of yearly roadmapping? Mine does. The current shop, the previous one, the one before that, and on and on. Just about every technology department I’ve been a part of does some form of yearly roadmapping exercise. The one characteristic that they all share? They’re drudgery.
The process of creating a roadmap seems a staple of the yearly business cycle, but that doesn’t mean that it has to suck. I work with technology folks who, independent of the sales pipeline, are asked to list, size and prioritize some set of initiatives that are either wanted (eg. trying out a new language) or needed (eg. addressing tech debt) by the engineering departments. It’s a noble goal, making developers’ lives better by helping them get their environments free of impediments.
Problem is: no one looks forward to the planning sessions. When I try to recruit participants (usually a subset of architects, team leads, etc.) for a roadmap planning session, everyone spontaneously seizes up and/or runs from the room.
When my boss asked me to coordinate this latest series of roadmap discovery and prioritization, I replaced the standard “sit around the table and gripe” sessions with two alternatives: Lean Coffee and Six Thinking Hats.
I invited the team to what I called a “planning coffee”, and curiosity took over. When the dozen-or-so members arrived, they saw an inviting table with index cards, markers and coffee carafes (optional). We made chit chat until enough people were there to begin (we did not wait for or worry about the stragglers). A quick explanation of the coffee rules, and we were off writing our wishlist items onto 3×5 cards. People got out of their chairs – their brains getting more oxygen than when they all just sit around – and the mood remained light.
Affinity mapping the cards is a fantastic cue for glimpsing the importance of a topic, but we still did some dot-voting after each topic card (or group of cards) was summarized. If we ended the meeting at this point, we would’ve already collected more information transparently and asynchronously in under ten minutes than we could have hoped for in a two-hour session going around the table with each representative speaking up in turn. Still, we played out the hour-long event asking questions of and examining the top few topics.
After the “meeting”, I took these data (topics cards, votes, added explanations) and compiled them onto a shared document. Others people throughout Engineering were free to read this and add or update as they like. Visibility makes the process much easier.
For the next round (with roadmapping, there’s always a next round) I brought together the whole department in a large open space with no tables. On the walls I’d hung 14 easel-pad sheets of paper – eight representing the top eight issues that came out of the prior “planning coffee”, and one poster of each of DeBono’s Six Thinking Hats. After quick explanation of the goal (to add ideas & insights to the list of prioritized roadmap items), we had everyone form groups (counting off 1 thru 8 helped randomize & balance the teams) and move to one of the eight stations.
Each team spent about five minutes at each station, working through each of the six hats at every stop. They recorded their ideas onto the large paper with markers, then moved on to the next topic paper. At the end of the session, we had fantastic data and suggestions on every one of our top eight roadmap items.
The Six Hats exercise added greater dimension to the department’s wishlist than a room full of mandatory attendees ever could have. The CTO appreciated that the entire exercise was kept to two one-hour meetings (as opposed to multiple days spread out over a few weeks), and she knows that the department “owns” (has defined and is accountable for) this list. It makes her job of negotiating with other management much easier.
