Agile Coffee

scrum

  • 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

  • presenting “Agile for Start-ups: SG’s History with Agile”

    In November I presented at SoCal Code Camp (USC) on the topic of my company’s history with Agile (from start-up to 200+ employees and 160B emails). It was my first time to present this topic, and it was tailored for an audience without much Agile experience.

    (For those interested, here’s a link to the slides: http://www.slideshare.net/VictorBonacci/agile-for-startups-sendgrids-history-with-agile-2013-bonacci# (If you’re interested, you can also view the full hour-long presentation here: http://www.screencast.com/t/WNwufLDPh01)

    In December I presented the topic again, this time to a roomful of practitioners at Agile San Diego. The audience there gave terrific feedback, including questions such as:

    • which metrics were introduced when? to what effect (efficacy)?
    • did metrics allow members/teams to game the system? which metrics?
    • what were some of the most impactful experiments we did with the processes?
    • how often did we experiment?
    • how did we measure results of experimentation?
    • was there an ebb/flow to the buy-in at the executive level?
    • do we use data to move people between teams?
    • how do we measure efficacy of pair-programming?
    • does our Agile adoption contribute to morale or turnover?

    The answers to these questions will make there way into the next iteration of the presentation, tentatively scheduled for an upcoming Agile SoCal event in Irvine. Meanwhile, I’ll discuss this at my AgileCoffee meetups and post notes here as they roll in.

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

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