How should we do Heartbeats in 2015?

NOTE: this is an open, straw person draft in search of your feedback, edits, love and interrogation. Please comment and ask questions so we can refine and turn this into a polished piece of documentation.

We’re coming up on a new year and a fresh start. We’ll start using some shiny new tools, double down on distributed  leadership, and streamline our processes for getting shit done. Part of that is about refining our two-week “Heartbeat” process for planning and  communicating. This post outlines some proposals for doing that.

Where do we want to improve? 

    • Openness. More visibility for all stakeholders. Easier to see what we’re working on. Plus: easier to get your own ideas and work into the queue.
    • Continuous improvement. Move faster, work smoother, work better.
    • Putting 2015 plans into action. In Portland we crafted a solid set of quarterly milestones. Next we’ll refine the process for putting those milestones into action — one  heartbeat at a time.
    • Cross-team collaboration. We need to co-ordinate well across all teams to succeed (in 2015 more than ever).
    • Build on what works. Small teams that know what they’re accountable for and have the freedom to move. With two-week chunks as the atomic unit of work.

A typical heartbeat

 

Here’s what a typical two-week process might look like (TL;DR version):

  • Monday: Clean up from the last Heartbeat. Decide and prioritize what we’re doing next. Publicly share out that plan with the world.
  • Tuesday: Project Kick-Off Meetings. Get together in small project teams around those priorities.  Brainstorm, plan and whiteboard together. Make sure all the required stakeholders are on the same page.
  • 2nd Monday: half-way point. How we doing?
  • 2nd Friday: Finish line! Demo what we got done. Review what we learned. Make proposals for the next Heartbeat.

For really important (“P1”) work: layer on daily 15-minute stand-ups. To make sure questions and problems get answered fast.

That’s it! Layer on whatever other meeting, communicating and dance parties required. Rinse and repeat.

Heartbeat Process

Here’s the more detailed version of that same process:

Week 1

Mon

  • Clean up. Tie  off any loose ends from previous week. Push to production, write blog  posts or documentation, communicate out, etc.
  • TPS meeting. TPS meets to review heartbeat proposals. Communication and horse-trading happens. TPS sets priorities for the heartbeat: P1 / P2 / don’t do.
  • Publicly document and share priorities. At build.webmaker.org/now. This is the finalized set of priorities for the Heartbeat. It’s publicly visible, shareable, and always up to date. Plus includes owners and roles for each project.

Tues

  • Kick-off meetings. Project owners and teams get together to plan and communicate up front. Co-leadership, consultation and white-boarding happen. Good kick-off meetings are essential; here’s a template we can edit together to make them awesome.
  • Ticketing. All tasks are created as tickets and assigned.
  • Resourcing. Review for bottlenecks. Who’s got too much on? Who can help?

Wed – Fri

  • Daily stand-ups. On all P1s. 15 mins max. Status check: red, yellow, green. All issues with the “needs discussion” label are reviewed together as a team.

 Week 2

Mon

  • Halfway point. Project teams meet to review progress. Reality-check. Includes a check-in for each team member about the issues assigned to them. What adjustments do we need to make?

Tues – Thurs

  • Daily stand-ups. (Same as previous.)

Friday

  • Demo. Cross the finish line together. Review completed work, including all P1s. All interested stakeholders (that means you!) are welcome to attend — it’s a chance to see what we got done together. (note: new time for demos =  11am PT / 1pm ET)
  • Retrospective.  Together and in small teams. What are your personal highlights  from the past two weeks? Something you’re proud of? Something that was hard? What’d you learn that you commit to address next time around?
  • Proposals. Plan for next Heartbeat. Given the milestones we’ve set together for the   quarter, where should we focus next? Some structure and planning will  already exist — but take the afternoon to review, consult with colleagues and make proposals.

Ch-ch-ch-changes

More visibility and distributed leadership

  • Better inputs and outputs. This is the single biggest improvement you’ll notice in how we work going  forward. There will be much greater visibility into the current scope of work, in terms of what the priorities are, and how to get your own ideas and work into the  queue.
  • Clear links to quarterly miletones. Each heartbeat will orbit around and tie back to the quarterly milestones we set together in Portland.
  • Meet and communicate as needed. This heartbeat flow is just a skeleton. Flesh it out and layer on however  you see fit. Our hope is that this gives you more time and freedom to meet, communicate and collaborate with colleagues as needed. You’re the expert on that.
Building a new project intake process. Strategic, templated, open.

New tools and dashboards

  • New project intake process. Coming soon, anyone will be able to propose a piece of work at build.webmaker.org/new. It will provide a project intake process and template that will help us put distributed leadership into action. (NOTE: There’s a bug that’s breaking this right now. We’re working on it!)
  • See what we’re working on. This new alpha prototype: build.webmaker.org/now shows our priorities for the current heartbeat. Plus what’s been proposed so far for the next one. (Janky alpha version, improving daily.)
  • Using GitHub issues.  Moving forward, we are embracing GitHub issues in place of Bugzilla for  much of our work. Of course, we’ll continue to use and support both. We  think you’ll like the GitHub interface and ways to make the work more  visual. And we’re offering Git Hub issues training to anyone who wants it. Also: feel free to ask in #webmaker IRC any time you’ve got questions. We’re all noobs. We’re all learning together.

Fewer, better meetings

  • Demos. We’re changing how and when we do demos. We’ll do them every other Friday, add the end of each heartbeat,  at 1pm ET / 10am PT / 6pm GMT. The goal: add weight and ritual, and add emphasis to what we’ve accomplished each heartbeat. Note: *all* P1s will be expected to demo.
  • Daily standups on P1s. Stand-ups are quick, 15-minute check-ins. They start *precisely* on time, and are designed to carefully respect your time. These ensure you get any help and answers you need quickly.
  • Project Kickoff meetings are an art. They’re a big part of distributed leadership, collaboration and minimizing headaches. There’s more detail on tips and tricks for Kick-off Meetings coming soon.

Changes to TPS

  • TPS will meet bi-weekly. TPS will no longer meet weekly. They’ll meet every other week instead, at the start of each heartbeat.
  • TPS will get a new name. Something clearer, more natural language and friendly. (“Tactical Priorities Syndicate” sounds Darth Vader-ish.)
  • Program Managers will join TPS.  Beginning in 2015, Program Managers from Engagement and Mentor Networks will join TPS meetings to help document and share  out each heartbeat’s priorities with their teams.

The goal: collaborative production for happy MoFos

What do you think? How do we do all this better? What questions does this leave unanswered? What examples or stories do you have around how others are doing smart, agile collaboration in the open? Please share as comments here, in #webmaker IRC or via whatever channel works for you. This is all meant to spark dialogue and put fresh wind the sails for 2015. So let’s talk!

10 comments

  • I love all of this. The focus on transparency, the regular rhythm, and the scrum-like flavor, especially.

    Some questions:
    * I don’t know much about how/if estimating happens. Seems an important piece of the horsetrading practice will be having estimates, preferably by the people who will actually do the work. I’m a big fan of using story points and tracking velocity trends over the course of many heartbeats. (Mike Cohn has good stuff to say about story points: http://www.mountaingoatsoftware.com/blog/tag/story-points)

    * When/how does grooming happen (where grooming = any activity that helps create a shared vision of upcoming work, e.g. whiteboarding, prototyping, user research)?

    * Will there be continuity across multi-heartbeat projects, or is each TPS meeting an occasion to revisit the longer-term roadmap?

    * Do we have overarching Done Criteria documented anywhere (e.g. an agreed upon level of test coverage, documentation reqs, standards for l10n)? It can be useful to run through those checklist-style, along with revisiting any acceptance criteria that were written for particular projects, at the Demo. That way the Demo serves double-duty as a “review” of sorts, and the backlog can be managed in real time.

    • Hey Hannah. These are great points — I’m hoping you’ll bring proposal for rolling some of this stuff into the process for our first heartbeats in January. :)

      * Estimating. We could use a more rigorous process for doing this together — maybe bring a proposal for how we might incorporate story points / planning poker to the first heartbeat in Jan?

      * Grooming. We’ve been working on a visual-style kanban board here: https://waffle.io/mozillafoundation/plan Something I’ve been challenged by: nothing online replicates the awesomeness of good ol fashioned post-it notes on a wall. Could use your ideas here as well. Plus: lots to do to get Q1 Learning Networks stuff into the backlog in Jan, so we can more clearly visualize that upcoming work.

      * Continuity. I think clear quarterly milestones are key there. We probably need to surface those as a clearer, one-page view of Q1. The KPIs are in the 2015 plan, but we should make sure they’re translated into stories and filed in the backlog.

      * Done Criteria. Each project has a “Quality Lead,” and Andrew and Wex have been working on test scripts, etc. Talk to them about that. Agreed re a template / checklist. Also: clear “acceptance criteria” will help people think about what “done” actually means.

  • I thought I would share a little bit about the particular heartbeat that I am working on right now – as it might provide some context/answer some questions.
    I am working on developing a new onboarding experience for Webmaker. You can see the progress for the ticket here: https://github.com/MozillaFoundation/plan/issues/52 and my whiteboarding here: https://redpen.io/p/zre152d4dfbdd65cc5. I am using this time to prototype and ideate on a make-first learning experience that will hopefully introduce users to our approach and tools and encourage them to “Join Webmaker” by signing up. Prior to the project kickoff, I did a bit of research – using the tools, watching maker parties, talking to Hive staff and members and observing n00bs use the site. (I also had experimented with Hackasaurus, the goggles, the Maker Party snippet and with the Outfit of the Day tutorial). We had our official kickoff meeting on Tuesday. I have been prototyping rapidly and openly, and asking for feedback regularly. Once I have a low fidelity interactive prototype working, I hope to find a way to do even more formal user testing – and the product team is working hard on developing a way to make this a natural part of all of our workflow. I am sure that the process will evolve, but as far as my first-heartbeat-ever goes, this one seems inclusive of testing and community – although I can definitely do more, and am eager to hear more ideas.

    • This is awesome Jess. What was particularly awesome was: you brought a lot of this advance work and thinking to the Kick-Off meeting. And visual thinking and white-boarding (instead of the usual MoFo habit of perpetual etherpad vomit 😉 is something we want to encourage all of us to do more of.

  • This looks cool Matt!

    Is there a way for volunteers to “plug in” to this heartbeat process? A few years ago, I remember Mike Beltzner, former Firefox product lead, talking about how estimating and planning was a bit tricky with open-source projects because you wanted to leave some wiggle room for unexpected volunteers to jump in and provide entire awesome new features (not just bug-fixes). I’ve heard this was the case back in ’06 or ’07, when Ed Lee, who was then a volunteer, worked with Alex Faaborg to forge the legendary AwesomeBar.

    • Is there a way for volunteers to plug in? Yep, always. Anyone can see, propose and comment on work through build.webmaker.org. And we’re hoping that working in Git Hub will help with attracting skilled contributors as well.

  • Great work everyone.

    One addition would be a people-oriented view of the upcoming heartbeat. Since github only allows a single person to be assigned to an issue, the build/now view can’t show all the people involved.

    @mentions will solve this in some ways (more so when legacy projects and bugzilla bugs are resolved). But if a heartbeat continues or revives a project, roles might not be newly mentioned. This also doesn’t allow us to see how other people are spread across the priorities.

    I’m not sure if a meta-ticket of all the meta-tickets is the right solution, but a single issue that summarizes a heartbeat could provide a central spot for this info.

    • Definitely needed. Would love to follow up with you on this in the New Year.

  • I am wondering two things
    1. How does one know what heartbeats are happening? And will these be visible (as in is there some dashboard of what projects are taking off)?
    2. Is there a process to submit a project/idea for engagement in a cross-team Heartbeat, or does one just use Bugzilla?

  • A good bit of my work does not follow a typical “product creation” lifecycle. Some does, but often there are urgent dev needs that fall outside of a “kickoff, iterate, ship” rhythm. For instance, net neutrality announcements just made mean we need to potentially build a set of campaign assets in the next 3 weeks that weren’t anticipated. I would love to game out a scenario that’s typical for our advocacy work / movement building effort (sometimes things develop that require fast build and iteration, without luxury of time). I want to make sure I understand the proper steps of how to fit that kind of urgent need into a heartbeat so that process is better understood, and less disruptive to everyone.

Submit a comment

Your email address will not be published. Required fields are marked *