Skip to content

Indicating development stages to help provide more visibility to product and design and engineering leads

Victor Wu requested to merge development-stages into master

TL;DR

  • A developer maintains the status/labels of their assigned issues similar to this:

Screen_Shot_2017-08-21_at_14.40.00

Problem

  • GitLab is very special in that we are remote and async.
  • So when we do development, we have to rely on async signals to provide status.
  • The signals are extremely important for us, because we are currently working on a monthly cycle. Often times the engineering teams may be working on higher priority items that were not accounted for adequately in the initial planning stages of the cycle (or just almost impossible anticipate, e.g. regressions). And then the product and design teams are not in sync. When this happens, the development team may end up scrambling to finish originally scheduled work toward the end of the iteration. This is not healthy nor sustainable.
  • During a cycle, if the original plans change, the product and design teams need to be made aware, confirm those changed priorities, and support them. Also, product should recognize earlier that originally scheduled features are unlikely to be shipped, and plan for that by adjusting future iterations, informing other stakeholders (sales, marketing, external customers), etc.
  • Ultimately we don't want to surprise people. We want to mitigate risk and uncertainty.
  • Currently, we often do not successfully finish scheduled features. This is a problem that should be retro-ed separately. (Are we scheduling too much? Can we reduce regressions?) But this is not the problem I am trying to address. I am trying to address the problem of visibility. I want to know that features are unlikely to ship earlier in the cycle, and be proactive in managing this.
  • Let me re-iterate: I am not blaming anybody or complaining that scheduled features slip. I recognize that this is a reality now and I want to manage it better as a product manger. Even if the problem of slippage is reduced in the future, the problem I am trying to address will always remain because we can never be 100% perfect.
  • Given our long cycle time (a month), and our async communications, we are currently not doing a good job with this.
  • One possible solution is more meetings! This is a terrible solution because it introduces more overhead, is not scalable, and unworkable for our fundamentally async product development process.

Proposed solution

  • See merge request diff here.
  • Use labels! And issue boards!
  • Introduce the minimal overhead of requiring developers (who are the main drivers during the development phase of a cycle) to indicate the stage at which they are in during the development process.
  • I've sketched out what I think are reasonable stages (and associated labels) that are appropriate for our current GitLab process. (e.g. we don't have a formal QA or UAT processes. So I just lumped all that into In review).
  • Product managers and engineering leads can maintain issue boards to see issues flow through these stages.
  • They can quickly dig into the issues / merge requests if they want further information if they want, and can get an immediate approximate high-level status of the iteration just by looking at the issue board. They can ping the developer for a status update. But this may not even be necessary.
  • This is minimal extra work for developers, but introduces massive benefits.
  • The stages are granular enough to serve as a status update, but coarse enough to not overburden the engineering teams.
  • It will be massively helpful for product managers to plan and communicate to other stakeholders.
Edited by Victor Wu

Merge request reports