Agile Coffee

Blog Posts

  • Agile games, simulations and learning activities

    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

    Before I share my list, a quick word on terms. (Credit goes to Derek Wade @derekwwade for this description in the Google group: Agile Games)

    • 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.

       

    • Human Knot [ link to example video ]- Teaches self-organization
      • 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).

  • My Path of Servant Leadership

    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.

    map to my servant-leadership epiphany
    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.

     

    sf agile 2012In 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”.

    Tom Looy: Path of 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.

  • What is a ScrumMaster?

    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.

    Michael James, in his erudite article at the Scum Alliance’s site, fairly well states this case. He spells out no fewer than 42 items for a ScrumMaster to keep on her checklist. Incidentally, 42 is the same number on Bernd Schiffer’s similarly excellent post on a ScrumMaster’s job (be sure to check out the comments – GOLD!) Maybe 42 really is the answer to life, the universe and everything.

    ScrumMaster competencies assessmentI 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:

  • The Pair-Coaching Domino Game

    domino-game
    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.

    (You may remember that I enjoy exploring this topic, and that I wrote about it earlier in the year. It seems that I’ll be talking about more this summer at the Scrum Alliance Coaching Retreat, possibly at the Agile Open SoCal and certainly at Agile SoCal in November.)

    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

    Roles in Pair-CoachingThe 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.

    ScrumMaster Assessment

    While I’m giving credit to others who deserve it much more than me, I’d like to call your attention to Bernd Schiffer’s excellent article on the 42 Tasks of a Scrum Master’s job. I find his list quite comprehensive and very useful when talking about pair-coaching.

    ScrumMaster competencies assessmentThis 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!

  • Encouraging a Bring Your SELF to Work Day with your teams

    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.

  • Patterns in Pair-Coaching

    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.

    good cop / bad cop
    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

    co-training

    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 / Kohaisenpai-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!

     

  • Kafka, Agile Coach

    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.

  • Roadmapping with Coffee and Hats

    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.

    hats-6

    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.

    hats-ahats-chats-b

  • Lean Coffee in the workplace

    Recently I was asked about using Lean Coffee (LC) in the workplace, something I’ve been doing for the past few years. While I’m a strong advocate for LC’s workplace applications, I’d like to start with my view of the broader picture. (I’ve written about my experiences with LC before, but this post has more experiences to back it up.)

    I’d originally heard about Lean Coffee three years ago when I met Jim Benson at SFAgile2012. I immediately fell in love with the framework, so much so that I switched my twitter handle to @AgileCoffee.  Once I returned from the conference, I started a bi-weekly Lean Coffee here in Orange County, CA, that still meets regularly. (By the way, I’ve got nothing but love for Jim & Jeremy and the leancoffee.org website. I credit them often and drive traffic to their site, all so I can help shout about LC from the rooftops. So many potential applications, IMO.)

    For the community LCs that I run (and I’m all about community), I use meetup.com to get the word out and organize. It costs a bit of money out of my own pocket, but the payback has been amazing. We’ve had an Agile/XP community here for many years – mostly project managers and technologists showing up to monthly workshops out of habit to eat pizza – by and large, those events (while useful) aren’t very exciting. The LCs, on the other hand, draw a subset of non-zombiefied practitioners as well as students and entrepreneurs who find us via meetup. I’ve been holding these for nearly three years now, but rarely have co-workers come by to participate.

    A recent spin-off of the community meetups is the podcast. Some of the regular visitors to the meetups agreed that the conversations were often too valuable/entertaining to let fade away, so we began holding separate sessions to be recorded (and published to Stitcher and iTunes). It was an easy transition, and we follow the LC format in real time on each episode. (In the earliest episodes I explained the rules, not so much these days.) These have allowed us to share the conversations around the globe. As of this writing, we have about 240 downloads per session with a few questions & comments coming from these. 18 episodes produced so far, three more in the pipeline, and our next recording meetup in a week. All recording sessions for the podcast are held in person – I’m resisting the temptation to do a LC by Skype or Google hangout, mostly because I believe face-to-face is the only way to do a LC.

    When I go to conferences and Open Space events, I carry a kit filled with index cards, sharpies and some blue tape. Impromptu LCs can spin up in no time at all. (An interesting aside: I’ve kept nearly all the (anonymous) index cards from my meetups, podcast sessions and impromptu LCs for a few years now. Someday I hope to index, group and share them. Not sure how or why, but I enjoy seeing questions repeated or themes forming over time.)

    I also get invited to speak locally/regionally about LC and the benefits for using them in the workplace. For each presentation, I use a slide deck I created so I can put LCs into context before holding mini-coffees with large groups. (This year, I created a pecha-kucha for the Scrum Alliance gathering in Phoenix … crossing my fingers to get accepted.) We also were talking a year ago about trying a Scaled Agile Coffee TM (aka really big LC), but realized that Agile Opens and Agile Coach Camps are pretty much what we had in mind. (We’re hosting the next ACCUS here in Irvine in a couple months.)

    Okay, so with regard to the workplace…

    It didn’t take too long after starting the community LCs before I wanted to experiment with them at work. Back then I was a coach/SM at SendGrid, and I was always looking for alternative experiences for the retrospectives. The first time I ran a LC, the quick reaction was “WTF?”  The team was used to me trying different techniques, but this one caught them off guard somehow. By the time the session timebox expired, they (almost) didn’t want to leave the room. We’d discovered together how some topics – previously given lip-service at prior retros – were actually important and complex enough that they dominated a 90-minute session. More cards were created mid-coffee, and we were surprised that even the normally quiet and reserved members became vocal. (I think it was as much about getting them out of their comfort zone as much as it was about the LC format itself, but… winning!)

    A year ago I attended a workshop on retrospectives led by Diana Larsen. I’d brought up LCs as an alternative technique, and the room exploded. Other folks there had previously employed it, to equally dramatic results. I’ve found, though, that I can’t use it on a regular cadence with my teams. I like to spring it on teams when they least expect it, otherwise it could turn into one large bitch session.

    It’s a great format for brainstorming activities, as you likely know. Not so good for ordering / prioritizing work or detailing technical concepts, though.

    I’ve used LC with my Scrummasters. SendGrid had 10-12 teams spread across four locations when I left, with about five full-time SMs who self-organized to share “best practices” (I use the term loosely). When we were able to be together in person, I would carve out time for a SM-focussed LC so we could address common concerns and brainstorm new activities. We’d even tried to hold a SoS as a LC, but it wasn’t too successful. Oh well, we tried.

    Now I’m at another workplace, and I use LC more than ever. I still keep it as a retro technique, but I’ve also introduced it to managers and executives. When my boss asked me to organize the ritual yearly Roadmap exercise, I shocked the system by holding a LC in the boardroom. Defenses came down when we affinity mapped the cards into topics and found overwhelming support for issues related to tech debt, stability and scaling our services. Suddenly pie-in-the-sky features didn’t seem nearly as urgent to the C-levels present. Although later meetings were more traditional, the LC exercise cut right to the meat of what would become our highest priority objectives for the year. Saved time with a lot less arguing and horse-trading than I’d experienced with similar roadmapping cycles at previous organizations.

    Over the holidays, a peer/mentor of mine pushed me to try to find more applications of this lightweight, agenda-less model in the workplace. It really is my laboratory, and LC is a fantastically easy and effective format to throw at unsuspecting participants.

    I’d like to discover more uses of Lean Coffee. If you have other applications, please share in the comments below or to me via twitter @AgileCoffee.

    – – – –

    Update 2/25/15: I wrote a guest post on the Modus Cooperandi blog entitled Fresh Perspectives on Lean Coffee where I go into a bit more detail on the roadmapping exercise. I’ve also dedicated an entire post on Roadmapping with lean coffee and Edward De Bono’s Six Thinking Hats. Enjoy!

  • Capacity Planning worksheet for Scrum teams

    [ UPDATE July 2016 – I no longer subscribe completely to the concept of capacity planning, at least to this level of detail. I will keep this post available, but I will not maintain the fancy spreadsheet 😉 It’s fun to geek out with numbers and formulas, but we could do better having meaningful conversations with our teams. ]

    The topic of Capacity Planning came up in a recent coffee, and I decided to introduce it to my new team. I just developed a spreadsheet (illustration below) that helps make visible the number of hours that each team member is committed to for various activities not related to actual work on user stories and defects. The purpose for doing this was to make everyone aware of their overhead before they commit to a sprint.

    Capacity Planning worksheet
    sample Capacity Planning worksheet for Scrum teams (with chart)

    I was introduced to the concept of making capacity transparent at the start of each sprint when SendGrid did the initial Agile transformation. I was especially drawn to the focus factor (though we didn’t use that term at SG) which accounts for the hard-to-quantify time that an individual loses each day to tasks such as checking emails, impromptu discussions, unplanned meetings, helping teammates, etc. For focus factor, we plugged in a flat value of about 25% of each person’s day, but the more I consider it, I now prefer using a range (eg. from 15-30%) specific to each team member. This factor may also may change over time (eg. sprint to sprint or day to day).

    The hours in the worksheet (full size image below) are all based on a two-week sprint, so how many hours for activity x are consumed in 14 days.

    sample Capacity Planning worksheet for Scrum teams (table)
    sample Capacity Planning worksheet for Scrum teams (table)

    I’m going to walk through the rows in some detail here:

    • Columns C – H represent six individual contributors on a Scrum team. The team’s Tech Lead attends more meetings and is interrupted more than other members. Dev4 is a new team member and is attending orientations and trainings.
    • Rows 2 – 8 are related to Scrum ceremonies that are repeating and predictable over the two-week sprint.
    • Rows 10 – 15 are related to non-Scrum activities scheduled by the company, department or guilds that are repeating and predictable over the two-week sprint.
    • Rows 17 – 21 are non-repeating and unpredictable. The ScrumMaster solicits each member’s hours in this category at the start of the Sprint Planning session.
    • Row 26 represents the unknown, unquantifiable “soup” that consumes our working days (described above). The focus factor (row 25) changes for each team member, and the higher the percent value, the more the member is expected to be distracted. This percent value is applied to the hours remaining outside of those already accounted for in the above three categories.
    • Row 27 is the sum (in hours) of each of the above four categories.

    Note that (for this sample team) no account is made for any team members splitting their time between projects (eg. the FE developer is 100% allocated to this team). Also, the focus factor isn’t adjusted for multi-tasking between an unreasonable number of stories (ie. this model assumes an individual WIP limit of 1 or 2) with the possible exception of the Tech Lead.

    [update 5/15/15] Here’s a download of the Team Capacity Worksheet (.xls).  I offer this download with no guarantees that it will work on your OS, and I will not be updating it or converting it to other formats.

    I welcome comments below or on twitter using #capacityworksheet

    pie chart
    pie chart for sample Capacity Planning worksheet for Scrum teams