Agile Coffee

SendGrid

  • Need a new game to teach Scrum ideas? CardZinga!

    Need a new game to teach Scrum ideas? CardZinga!

    One of the most popular exercises for teaching Scrum concepts (empiricism, self-organizing, etc.) is the Ball Point Game (BPG), and most Scrum trainers I ask say they’ve used it. If you’ve taken a Scrum class or two, you’re likely to have played it, too. (Here’s a link to a video I recorded in 2012 of a large team playing BPG.)

    When playing the Ball Point Game, a team will organize themselves around the goal of getting as many balls as possible passed through the system within a defined period of time. There are a few specific rules / constraints, and groups will typically undergo three to five iterations while tracking their progress. It’s a fun, lively activity that introduces empirical processes and lays the groundwork for a more tangible exploration of Scrum.

    In late 2018 I started looking for alternatives, and it wasn’t long before I came across the Lean Workflow Design Game by Nancy Van Schooenderwoert and introduced at the Play4Agile conference in 2011. It’s a useful and fun game; nonetheless, I wanted to extend it a bit, share a virtual version, liven up the name, and give it a home online.

    And so, without further ado: CardZinga!

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

  • Scaling Me, Scaling You

    I just scheduled our next meetup and threw these two questions out:

    • How many teams is too many for one roving scrummaster?
    • How many members before a team is too large?

    What’s great is that the group can discuss / debate the question. Despite being in Scrum environments for over six years, I don’t have THE answer, but I DO have some opinions based on solid experiences.

    Without playing too much of my hand prior to the actual meet-up, here’s what I’m thinking:

    Roving ScrumMaster

    I was hired here at SendGrid as an Agile Coach tasked with leading the transformation and maintaining the learning and culture that goes along with that. One year into my job here, we had nine teams located between Anaheim (five), Boulder (three) and Romania (one); and for most of that year, each dev team provided its own scrum master. I and another coach (Stuart joined us in January, 2012) would coach the teams, paying much attention to the nine scrum masters.

    Since then, however, we’ve taken over the role of scrummaster for each team, allowing the devs to focus more fully on the design / development / testing work of the sprint. As you can imagine, Stu and I became busier than ever trying to juggle multiple teams and all the communications and dependencies that go along with this.

    Good to Great

    It’s been said that a good scrummaster can handle 3-4 teams, but a great scrummaster will insist on working with only one. I’m a firm believer in this model, but that wasn’t currently possible in the time frame I describe. Back then (early spring 2012) we were told that the organization would work to hire more scrummasters (and they did by mid-summer), but that in the meantime it was up to Stu and I to handle the responsibilities. The teams woul no longer provide their own scrummaster.

    Results varied. It started with both Stu and I taking four apiece. (The Romanian team was being “managed” by their own “scrum master”.) But Stu and I each had at least one team in Boulder (we’re in Anaheim), and that added complexity.

    Part of my role as Coach has been to spread Agile learnings throughout the organization, including up through management / leadership. I’ve worked with our VPs of Engineering (we’re on our third in two years) to understand the business situation and share my teams’ concerns. It comes down to values on both sides: commitment and focus for the teams and delivery and growth goals from business folks. These values are not contradictory, but neither are they perfectly aligned.

    Pizza Teams?

    Okay, dear readers, time for a pop quiz. What is the ideal size of a scrum team? If you answered “seven, plus or minus two”, congrats – that’s the magic number, also supported by the Scum Alliance and other leading Agile voices. The “two-pizza rule”, attributed to Jeff Bezos, states that no team should be so big that it cannot be fed with two pizzas. In my experiences, this jives with our successes.

    But can a team of only two devs make it work? (Lots of leftover pepperoni and cheese slices.) What about teams larger than nine? Can their scaffolding support them? We’ve hadt tw0 2-person teams, plus another (in Romania) that now brims with ten. I don’t even know what goes on a Romanian pizza.

    Anyway, these are some topics I hope to work through next week. In the meantime, I’m craving pepperoni.

  • SendGrid’s history with Agile

    I thought I’d highlight the milestones SendGrid has had in our Agile journey.

    Ground Zero

    When I started at SendGrid in May 2011, the organization was on the verge of adopting Agile and Rally’s agile software solution. In other words, the decision to move to Agile had been made prior to my start. (In fact, it was a key selling point used to get me to join SG.) The company was barely 18 months old, still a start up and had an Engineering staff of 10-15, tops.

    Hired as the first project manager and Agile coach, I was responsible for putting the training strategy together. We had inroads with Rally b/c Chad (our CFO) had also been employee #7 at there, and they were in Boulder (as are we).

    Prior to using Rally’s tool, SG had been using Redmine to store all features and defects. There were no formal teams either.

    Agile training, Rally style

    Within my first couple weeks, I met with Ann Konkler (Rally certified trainer) and we drafted a schedule for the following visits:

    1. phone conversation to set stage
    2. visit to Boulder to meet with stakeholders (I was present, though our VP of Eng still had not started)
    3. two-days of training in Anaheim with all Engineering staff (VP Eng now present)
      • for the first iteration, we converted all US to physical note cards (sticky notes) and placed them on the walls, per team
      • no use of tool at this time
    4. after 2 weeks (iteration length), a follow-up with Ann in Anaheim with Engineering staff
    5. after additional 2 weeks, hosted addt’l Rally trainer for two-day training on Rally SW

    Ann also followed up via email/phone. When the whole organization (young and small as we were) is making the transition to Agile, having a trainer on-site and dedicated for those first weeks is critical.

    We adopted Rally’s tool for managing our projects, and I created some custom panels (views / queries) using javascript. It provides a very powerful and flexible means of tracking epics/features/bugs across an organization, and adoption of the tool came quickly with Rally’s training.

    Tom’s tweaks

    Our new VP of Engineering, Tom A had come from an Agile background, so he had a lot to say on:

    • the formation of teams
      • a large discusion/debate ensued on the topic of cross-functional teams vs teams aligned with a specific function; in the end, we took Tom A’s approach and created a web team, a backend team, etc.
    • function and composition of Demo mtgs
      • a strong proponent of team’s presenting from a standardized set of power point slides

    During Tom’s tenure (8/11 – 1/12), we made several small tweaks along the way. I was still the only project manager, and our Engineering department (including QA) reached approx 25-30 (10 teams) while Tom A was at SendGrid.

    Also at this time we initiated weekly Theme Prioritization meetings, a forum for stakeholders to insert and prioritize larger engineering initiatives. Despite it’s shortcomings, we retained this process for over a year as we transitioned leadership a couple times.

    Staying the Course with Isaac

    After Tom’s departure, Isaac (one of our three founders) assumed VP Eng duties, and Stuart joined SendGrid as our second PM / Agile coach. Having Stuart on board helped me incredibly. We were now able to divide the teams and projects between us, giving attention & coaching much more rapidly.

    Stu and I worked with Isaac to deliver a newer set of metrics than what Tom had focused on. We reported things like outages by priority (P1- P4), velocity (Tom also liked this) and percentage of commitments made. On this final stat, Isaac was most insistent. We began asking our teams to explicitly state a list of the stories (and defects, etc) that they committed to getting done.

    Also in January, after only six months of using the Rally product, we adopted Pivotal Tracker. Although Rally provided terrific tracking and reporting features, the UX left developers feeling too mired in rules. Pivotal was proposed (Tom’s final push) and was accepted by many (but not all) teams due mostly to its ease of use.

    This time I dove in to write a few PHP scripts so we could:

    • perform cross project searches
    • create department-wide cumulative flow charts
    • identify blocked items & dependencies
    • archive retrospective notes, etc.

    Agile training, year two

    As we approached the summer of 2012 (now one full year in to Agile as our methodology), Stuart and I prepared another round of training for our growing Engineering staff. Although Thomas Peng had recently been hired as VP of Engineering (relieving Isaac), he stepped back to let us administer more-or-less the same training that Ann delivered the year prior. Two days in Anaheim for all Engineering staff, now tipping 30 strong.

    One addition to the training agenda was a brief introduction to kanban (from Jim Benson’s fantastic Psychology of Kanban – as Stu & Vic recently attended the summit in San Fran).

    Season of Change, 2013

    We more-or-less stayed the course for Thomas’ first six months, but with the new year came another opportunity to review and revise the way we do things. Things that we’re currently experimenting with include:

    • Embedding our Project Managers as Scrummasters
    • new Demo Day sked
    • Overlapping Sprint schedules
    • Engineering Retro
    • transition to JIRA (with access to training)

    We had a few other events in early January, namely:

    • Management offsite, including a half day with Mike Cohn
    • Product Owner training at Rally attended by Stuart and members of our PO team
    • SendGrid’s 2013 Kickoff in Puerto Vallarta

    We also hadn’t held a retrospective for the Engineering department since early October, and we were overdue. (The teams hold their own retros after each sprint.) This time Thomas wanted to make it more of a summit than solely a retro, so we’re scheduling a day and a half affair for late February. Items to include:

  • notes from retro: reducing distractions

    By our Agile cadence at SendGrid, team retrospectives (and demos) fall every other Tuesday. Today one of my teams is coming up with a focused set of actions to try to solve the problem of distractions / context-switching.

    This team deals with many of our system-critical services (mail processing and delivery), so it’s staffed with really smart folks. (Well, really smart folks are on all our teams, but the features these folks work on receive a bit more attention than others.) They get interrupted often with everything from questions about our daemons and architecture to brain-teaser solutions and lego designs. Distractions are just part of the day for all of us (bacon, beer and crossfit are other biggies , but this team has put their foot down, resolving to do something about it.

    Some of the steps may seem like no-brainers, and the teams may have tried a few of these in the past, but maybe they lost the discipline. Other ideas are new to the team.

    make afternoons meeting-free

    Some meetings (we call them ‘ceremonies’) are a valuable/necessary part of our Agile/Scrum process here: daily stand-ups, sprint planning, backlog grooming, demos and retrospectives. Aside from those, there come (occasional) meetings that pull in the tech leads from across teams and (more frequent) interviews of awesome candidates (have I mentioned that we’re hiring?).

    It’s been a challenge for us to go entirely without meetings – this week we’ve been consumed with 2013 planning – but this team wants to limit their involvement to morning-times only. They’ve proposed designating the hours from 1:00 to 4:00 pm as “no meeting zones”. The idea is to give the team a long block of time in which they can focus on developing without context-switching.

    pomodoros

    Additionally, the team has decided to try using pomodoro – a time management technique that basically tells us to work uninterrupted for 25 minutes then get up / walk around / take a break for five. The size of time-boxes may vary, and longer breaks come after every four pomodori. Other teams here have used it with generally very positive results. The key is to let everyone else know not to interrupt you as you’re in the work period.

    finding a quieter home

    Our Anaheim office has a wide-open floor plan. With only a handful of offices and breakout rooms in our 4500 square feet, we encourage mobility and self-organization. The trouble is that this team, prone to interruptions due to their function, also has their desks grouped in the high-traffic area between the beer-room and the rec center. By re-locating their desks to a quieter space off the beaten path, we give the team a space of their own in which they can thwart invaders earlier and easier.

    The goal of these changes is to have the team apply more focus to their work, the work they love but have been unable to concentrate on. With the changes that the team decided on, we’re hoping that these goals are reached in some amount.