Agile Coffee

Blog Posts

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

  • Now with more Meetups

    Introducing the newest meetup: Agile Coffee – OC.

    I’ve been meaning to start this group since Stuart & I went up to San Fran for the SF Agile conference last May. There we met Jim Benson (Personal Kanban) and were introduced to Lean Coffee as a forum for discussing Lean, Kanban, Agile, limiting WIP, visualizing workflow, and just about anything else. A self-organized pull-system of learning / sharing. (Jim helped create Seattle Lean Coffee and has run it at dozens of conferences before the SF Agile event.)

    So that’s the goal here, in Orange County, is to get us together and start forming a community of enthusiasts and labs of lean experimentation. (There are a couple other lean alternatives in the area, but none focus on project management and coaching, my zing.) I’m kicking things off Monday 2/11 at the coffee shop by my place. When they get attended we’ll try to find more optimal locations, but for now I’ll use these productively – as writing sessions with OHIO treatment.

    This Monday is our first event. I’m looking forward to the buzz.

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

  • “I’ll have the salmon”

    Simple words that answer the second-most important question at a business lunch.

    At any professional lunch, the most important question is directed at you and usually needs to come from you. (How often does your boss ever ask “so, what are we here to talk about?”) A great question may be “what are we here to fix?”, and you’ll have your answer, in bite sizes of course. This is, after all, a business lunch where all people talk – not a monologue.

    It’s also good to stay within custom when it comes to timing. Before your order is taken, stick to small talk – usually begins on the trip to the lunch spot. And once the food arrives, no more initiating business talk. By all means, allow your boss to, but don’t prod her to re-engage. Not considered polite.

    Remember, order the fish then get to the point. When lunch arrives, bask in the conversation’s afterglow. Business lunch nailed.

  • new year, new projects – a fresh start

    With the new year comes a fresh new crop of initiatives targeted for the upcoming twelve months. And those initiatives ain’t gonna drive themselves to completion. This is where the project manager / scrummaster steps in resolutely and takes control.

    First, the tech leads of each team get together with the SMs and POs and hold a very important conversation: yearly scoping (aka commitments). The POs & product staff define the initiatives in broad strokes, then the tech leads discuss with each other what it takes to get these projects done. Slowly a list of Ins and a list of Outs begin to take shape. Bartering ensues. The scrummasters help by facilitating the meeting, making sure opinions are voiced from those less vocal.

    The next priority for project managers (SMs) is to set up the necessary project spaces. At SendGrid we use JIRA and Confluence to track story progress and post documentation (respectively). Getting backlogs started, versions lined up and items labeled, the team is ready to begin breaking down the highest priority initiative into epics, user stories and tasks.

    The scrummasters will next set appropriate ceremonies within the sprint cadence, including demos, retrospectives, and backlog grooming sessions. The POs continue breaking the stories down as finely grained as possible, and the teams begin work on the top-ranked stories.

    It is the job of the project manager / scrummaster to aggressively take control of these projects and lead them down the path to success. The SM is the enforcer of solid agile practices, and they rely on their project management skills to drive and communicate the progress of the teams.

  • Start Strong

    “The morning cup of coffee has an exhilaration about it which the cheering influence of the afternoon or evening cup of tea cannot be expected to reproduce.”
    ~ Oliver Wendell Holmes, Sr.

  • Hello coffee!

    Agile coffee, indeed.  I’ve had no fewer than three cups today.

    Resolutions for 2013:

    1. no more discussing coffee, today
    2. make most of Mike Cohn’s day with us
    3. talk through my retrospectives at SendGrid
    4. get out into the community talking about agile principles
    5. OHIO – only hit it once!

    That’s what’s brewing. Let’s make 2013 our best!