Agile Coffee

Blog Posts

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

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

  • What counts as Velocity?

    Recently we encountered a large-enough issue that required a postmortem (like a retro). One of the teams involved asked if they should put that into the sprint and give it points (ie. size it). This reminded me of a debate we encountered in our earliest days of implementing Agile.

    One side insists that we only point planned stories that provide immediate, direct business value to the company. Therefore, things like defects, chores, and meetings should not get points assigned. The reasoning here is that these activities are typically not included because they may occur without consistency and predictability across iterations; while they are a necessary part of our project, they can be thought of as an ongoing cost of just doing business.

    Pivotal Tracker (a fine issues-tracking tool) asserts in their FAQ that “by measuring velocity in terms of features only, [the tool] can estimate how much real, business-valued work can be completed in future iteration, allowing you to predict when project milestones might be achieved, and allow you to experiment with how any change of scope might affect such milestones.” So again, the focus is on business value, risk, and prioritization as opposed to the “constant drag on business-valued output”.

    The other side argues that fixing a bug is just another change with no fundamental difference from a feature request. Ie, the application shows a certain behavior and someone wants it changed. Bugfixes and features are the same from a cost / benefit equation, and business types will evaluate them according to their given strategy.

    Most teams at SendGrid do point bugs, some point chores as well. My feeling is that as long as the teams are consistent and the PO / business types are aware of this, then the impact of straying from “by the books” Agile/XP isn’t too concerning. Still, I’m interested in hearing how others deal with this, both the benefits and risks.

    [ Here’s another link from Pivotal’s community board on the topic. Good read! ]

    – – – – – – –

    [Update from Feb 25]

    We at SendGrid just made the change to not assign points from defects and chores. The decision was made at our all-hands Engineering Summit and was initiated by the developers. One big argument consisted of “Hey, our velocity has dropped to 3pts because we’re focused almost solely on bugs. Stop forcing the team to work on new features before we can clean up the tech debt from our previous efforts.”