Agile Coffee

Blog Posts

  • 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

  • What is Minimally Viable Agile?

    Jon recently asked (at 14:00 of episode 3 of the podcast) what’s Agile and what’s not.

    Do you ever hear “Oh, that’s not Agile” as a pejorative? There’a a lot of controversy – even a heated debate – about what constitutes the minimum necessary to still be considered “Agile”.

    Agile, of course, is not one method, but a collection of related methods. The term “agile” indicates (for us) a nimbleness or adaptability of these related methods.

    Could you boil Agile down into Iteration (the inspect-and-adapt cycle) and Incrementalism (breaking deliverables down into small units of business value)?

    What about respect for people? How about an un-ending obsession with eliminating waste (kaizen)? Are these elements that you couldn’t live without?

    What else? Let us know.

  • Using an Inception to kick off a project

    Agile Inceptions are powerful and fast ways to get a team to internalize a vision. It’s a two-day investment that saves the company months of up-front planning and allows the teams to begin immediately deliver core product functionality.

    Overview

    Since mid-2013, I’ve been involved with teams adopting the Agile Inception format used by Pivotal Labs to kick off new projects. I’ve been fortunate to participate in these inception meetings with a couple teams from Pivotal, and I’d like to share my observations on their agenda and process.

    The inception model is a kickoff strategy that is repeatable and well-vetted. At it’s core, the inception deals with how we scope. The session(s) relies on full participation by an engaged audience, and co-location is crucial as we swarm around note-cards on tables and walls.

    This page is not a comprehensive documentation of Pivotal’s process, but rather a how-to for interested project leaders to get started spinning up our own inceptions. For more details on Pivotal’s methods, see their detailed blog post.

    Pivotal’s default 2-day schedule

    Below is a sample schedule for a typical project that has had little formal planning until now. Some projects may not require a full 2 days if they are smaller in scope or have already undergone significant planning efforts. The schedule is a rough timetable (times based on an 8am-5pm day), and it is common to deviate from the exact times specified.

    While it is strongly encouraged that every team member – developers, PMs, designers – be present for the entire inception, the use of laptops is frowned upon. (They have a way of distracting people!) In addition to lunch, there are breaks throughout each day – email checking, etc. should be reserved for those times so that all attendees are focused and engaged.

    Day 1 Day 2
    8:15 – Office orientation & get coffee8:30 – Welcome: what’s an inception?8:45 – Introductions: who’s who?

    9:00 – High-level product concept & background

    9:15 – Break

    9:30 – Goals & Timeline

    10:00 – Risks

    10:45 – Break

    11:00 – User Roles

    11:45 – Lunch Break

    1:00 – Activities and Workflows

    2:15 – Break

    2:30 – Story Mapping

    3:45 – End of Day 1

    		 8:15 – Get coffee & be seated8:30 – Summary of where we left off & what’s ahead8:45 – Story Mapping (cont.)

    9:30 – Break

    9:45 – Story Mapping (cont.)

    10:45 – Prioritization

    11:45 – Lunch Break

    1:15 – Risks (revisited)

    1:45 – Break

    2:00 – Next Steps

    2:15 – Retrospective

    3:15 – End of Day 2

    Description of Agenda Sections

    Below are notes specific to the different parts of the agenda, as well as a few items that aren’t included in the default.

    Introduction of People and Agenda

    • Start with a quick go-around of everyone’s name / role / department / etc.
    • Discuss the agenda items, pointing out when the breaks take place.
    • Remind participants to not use electronic devices (laptops, phones, etc.) in order to have everyone engaged with few distractions.
    • Create a space for terms (acronyms and vocabulary that may not be understood evenly among participants) and another for parking lot items (topics to be discussed later without interrupting the meeting’s flow). Large pieces of paper from an easel pad work well – stuck on a wall somewhere visible.
    • Ask if everyone is clear with the agenda and rules (ie. get buy-in).

    High-level product concept

    • This is an opportunity for us to introduce the product design. Both UX and UI are covered.
    • This portion is led by the Product Manager(s) / PO(s), and previous experience with inceptions is helpful.

    The design (UX/UI) can be broken out into two types: experience vs visual design. The experience design is important for discussions of goals & risks and should be the focus of this section. The visual design, while important, can usually be covered as we create activities and stories.

    Goals

    Goals get logged – typically on a large, tear-away (easel pad) paper that can stick to a wall for quick reference.
    Goals fall into four categories (with examples):

    • business goals
      • engineering efficiency
      • better handling of customer growth
      • paid version of the product
      • better position for us to ship features
    • product goals
      • product readiness
      • SLA items (reliability, serviceability, availability, etc.)
      • no dropped / duplicated messages
    • engagement goals (for facilitator)
      • train how to do inceptions
    • non-goals (things we explicitly do not want included in the scope)
      • community / open source
      • fancy bells & whistles

    It’s important to keep all goals SMART (specific, measurable, achievable, relevant & time-bound). Identifying goals by time (eg. month or quarter) or sequence is useful.

    Risks

    This agenda section follows the following five steps:

    1. Hand out 3×5 cards to each participant. Based on the goals, each member should identify the risks they see, writing one risk per card.
    2. The facilitator (and helpers) will collect these cards organize them into themed groups spread across the table.
    3. Distribute three pieces of candy (or other tokens) to each participant. Everyone will use their three tokens to vote on the biggest themes (not individual risks) on the table, and they may give multiple votes to a single issue.
    4. Facilitator will tally the results onto another large (easel pad) paper and post on the wall.
    5. Facilitator leads discussion of mitigation strategies.

    Actors and Activities

    Call out roles (internal and external) and write one per 3×5 card. Ask for each actor what they can do in the system at a high level (activities).
    Examples include:

    • internal developers
    • other internal teams (billing, operations, support, etc.)
    • customers (technical & non-technical), their agents & apps
    • 3rd-party entities (eg. remote MTAs, spammers, etc.)

    Story Mapping

    This activity is the most time-consuming of the process, and facilitators should not rush it. Facilitators especially use their skills to:

    1. Keep one conversation going. Eliminate multiple conversations so that everyone can consume all available information.
    2. Remain impartial (don’t bias the discussion) and ask clarifying questions (assume that not everybody knows the shorthand).
    3. Break each story down as small as possible (eg. by method call).
    4. Log onto 3×5 cards. Two or more colors are helpful; use one color for the epic level, another color for child stories. Use colors different from the Actors/Activities cards.

    The goal isn’t to get all the cards created, but to establish a rhythm of story creation. More stories will inevitably get identified and created post-inception, but knowing how to brainstorm is the key.

    (insert pics)

    Prioritization

    Establish the strategy to be used for prioritizing. For example, are we going to address risks first, or do we want many stories to be completed quickly (momentum & visibility)? The product team representatives will take the lead responsibility prioritizing epics & stories.

    Tape the cards to a wall by prioritized epic left-to-right across the top. Stories (children) fall under each epic, prioritized top-to-bottom.

    Pointing / Sizing the Stories

    The developer teams (and others doing the work) will begin sizing each story, writing the points on each card. This activity can probably be done in parallel to the prioritization, at least after the first epic or two has been prioritized.

    (insert pics)

    Revisiting the Risks

    After stories have been prioritized and sized, the team re-convenes to revisit the original list of risks. Follow the same exercise as before, giving each attendee three tokens (pieces of candy, etc.) to vote on risk theme (not individual risk). Tally the votes and compare to the original baseline.

    Next Steps

    Review any Parking Lot items to see if anything has been missed (stories, etc.) and potentially schedule out additional meetings to cover edge cases, dependencies, etc.

    Capturing actions with committed people (including backups) and due dates is a critical part of the process. At a minimum, someone will be tasked with capturing the information on the inceptions artifacts (cards and papers) and enter them into your preferred project-tracking software system and other documents.

    Retrospective & Closing

    A quick retrospective of the inception is helpful to continually improve the process. Update this wiki with suggestions/improvements, and give constructive feedback to the facilitators so they can sharpen their skills.

    Conclusion

    Agile Inceptions are both powerful and fast in getting the team to internalize a vision, and the two-day session vets out goals, risks, roles and use cases, as well as other key topics.  All the players are together, focusing on the project and airing the ideas and assumptions about the project so that the entire team starts off on the same page. The design emerges organically, saving months of requirements gathering, and the structured discovery process enables participants to begin delivering core product functionality immediately.

  • 20 Questions

    Agilists are everywhere.

    We come in all stripes.

    Combine these two observations and you realize that at any time the opportunity can present itself to broaden your perspective on Agile practices.  When we meet other practitioners, it’s routine to ask a few basic questions; but if we take a disciplined approach to our inquiry, the encounter becomes a powerful learning experience for both parties – and one that frames the shared memory of the relationship’s inception.

    20 Questions

    I’ve recently come up with a list of 20 questions. The list isn’t static – it changes often. The questions themselves can range from the standard (team size, iteration length) to the unexpected (do you allow whining?), and I try to include one or two fun questions to make this exercise not seem like… well, an ‘exercise’.

    Here’s a partial list focused on the day-to-day:

    • How many teams do you work with?
    • What are the sizes of the teams?
    • Are Scrum roles defined?
    • What’s the iteration length?
    • Has there been an Agile champion in senior management from the beginning?
    • Is there a dedicated Product Owner (PO)?
    • How do you deal with drive-by interruptions?
    • Was the entire organization trained on the application of Scrum and how it would affect them?
    • Have you considered Kanban?
    • How do you balance between features that require a lot of details and delivering just enough just in time?
    • Are your teams co-located? If not, how do you collaborate with distributed teams?
    • Was the exec team on board with Agile adoption, or how did they otherwise buy-in?
    • Is there a scrum of scrums?
    • How do you show results to C-levels and keep them engaged?
    • Do you integrate regular Hackathons or Dev Days?

    I’ll also ask a few personal improvement questions:

    • Where do you see yourself in 3,5,10 years? (What drives you?)
    • Are there any trainings/books/podcasts/conferences would you recommend?
    • What have you learned from your mistakes?
    • How are you involved in your community?
    • What person/people do you know that I should get introduced to?

    Again, the point is not to interrogate these poor souls that you just met. I’m certainly not advocating that you read off this list and ask every question. Save that for the job interview 😉 Rather, I’m suggesting to use a few questions like these to not only break the ice, but to fast-track a sharing of your own views and experiences with the goal of reaching a broader understanding of who we are as agilists.

  • upcoming Diana Larsen workshop in San Diego

    Great news for those of you in sunny SoCal: expert agilist Diana Larsen is holding an Advanced Retrospectives workshop in San Diego on March 6th.

    The full title of the workshop is “Advanced Practices for Leading Agile Retrospectives: New Techniques and Activities”, and full details can be found here: https://www.eventbrite.com/e/advanced-retrospective-techniques-with-diana-larsen-tickets-8807454333

    from her abstract:

    “Agile Retrospectives improve any project or process — building on a team’s immediate past experience of success and failure. Smart teams and organizations hold Retrospective meetings iteratively, throughout the work cycle and at important release milestones. With effective meeting design and facilitation, Retrospective leaders help team members systematically evaluate their own performance, explore their lessons learned, expand their capacity and capability, and forge ways to continuously improve their work and deliverables. Teams can’t truly call themselves Agile if they don’t include Retrospectives among their regular work practices.

    “As Agile Retrospectives become routine, they can also become stale and boring, delivering less value to the team. How can you prevent this? Keep your Agile Retrospective practice fresh through a renewed emphasis on team learning, collective analysis, and collaborative decision making. View Retrospective facilitation and design through the lens of Five Rules for Team Learning: Keep it Alive!  Hunt Fluency, Start Obvious, Stay Focused, Adapt the Setting. Bring new activities and group processes to the meeting that will stimulate better thinking and improvements. In this workshop, Diana Larsen will introduce advanced uses of the Flexible Framework for Retrospectives and show how to incorporate the Five Rules for Team Learning in your Retrospective designs. Participants will share new team activities to enlarge your repertoire and gain practice in designing and facilitating effective Agile Retrospectives.”

    Diana is a founding partner of FutureWorks Consulting. She is considered an international authority in the areas of Agile software development, team leadership, and Agile transitions. Follow her on Twitter @DianaOfPortland and @FutureWks. 

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

  • LeanCoffee in Ohio

    Just got back from a relatively relaxing Thanksgiving pilgrimage to Ohio for family and football. While there I hopped over to Starbucks to host a LeanCoffee in Ohio (I’d posted it on Meetup a few weeks prior).

    As I’d expected, attendance was nil. Not sure if that speaks more to the fact it was a holiday weekend or that Ohioans don’t use meetup. I ruled out there being no love for Agile/Lean, for within a couple minutes of sitting there with my post-its and sharpies, the guy next to me (Robert) started asking me what I had? We talked about the setup and meetup a bit before getting to Agile. His company (hospital linens servicer) uses Lean principles to operate, and his brother works in an Agile shop (UI / Design).

    Alive and well in Twinsburg, Ohio.

    an example session at Starbucks
    an example session at Starbucks, with doughnuts!!

  • Packing my lean bags for Agile2013

    I’m excited to be heading to Nashville in only a few days, and not just because it’s a fun-sounding place that I’ve yet to visit. Agile2013 is a 5-day event that kicks off on Monday August 5th. I’ll be looking to connect with very smart people and share stories of successes (and failures). It’s also a great opportunity to learn and be exposed to new ideas that will add zest to my role as a scrummaster / project manager / coach.

    And did I mention five days in Nashville?

  • Everyday Progress

    Just read @zxed‘s post on skills you don’t have which had me reflect on my own style.

    I believe there are many skills (an unknowable amount and always in flux) essential to elite leadership. More than this, I believe that to become a great leader, everyday must be oriented toward greatness, no matter the increment.

    In my current role (technical project manager / agile coach) I have many opportunities to be great, breaking out like so:

    • competency: It sounds like a minimum requirement, but I feel I’m deficient more often than not. I feel that if off the cuff I can answer 80% – 90% of the questions asked by stakeholders, I’m surviving. Greatness strives for perfection. Time I save by not having my team members attend meetings is looked upon highly.
    • vision: No, I’m not the product owner (PO), but still I must have a clear vision of the goals of the projects that the team is taking on. Knowing what demarcates the path to completion is half my duty.
    • coaching: Pushing the team to be their best is the other half 😉
    • enforcement: I have an obligation to protect my team from distractions. This means not only preventing outsiders to interrupt the progress of the team, but also protecting the team from themselves. When meetings are held, I keep them on point, as efficient as possible so that no one considers their participation wasted.
    • nurturing: You’d expect this at the bottom of the list if only because it sounds like such a soft skill, but it can be a topic of its own. Simply tuning in to where each team member is with regards to their own hierarchy of needs goes such a long way to helping them identify with their own self worth.

    It boils down to this: My job is to stay in touch with what the people are doing and what they need to succeed. I succeed by pushing them toward their success. My goal is for each team member to create meaningful value – both personally and for the organization – each and every day.