Tag: launch-planning

Launch stages

Agreeing to incremental launch stages and the criteria that govern promotion from one stage to the next makes launch commitments, aka deadlines, less risky. For example, Google SRE’s launch plan documentation describes four: Early Access Preview, Alpha, Beta and General Availability (GA). Committing to a GA launch is easier after a successful Beta, which is easier after a successful Alpha, end so on.

Comparable to a deployment pipeline, promotion from one stage to the next ideally concerns stability rather than features. In other words, if the difference between Alpha and Beta is a length of time without issues, we can promote with confidence after that time, but if the difference is a set of new features, we don’t know how those features will perform.

Posted on by Erik 1

Deadline-driven

I have found it problematic to couple the construction of something with a launch date. For contrast, I’ve found it advantageous to launch something when it’s ready and then promote it when it’s stable.

A couple exceptions:

  1. externally imposed deadlines, eg security issues, GDPR and Transfer Service Agreements
  2. cadence meetings, eg demonstrating the latest work at the end of the week

I commonly see teams saying development is not deadline driven, but then doing it anyway. I think it’s common because it’s easy to see the value of having something to show at, say, a conference, but hard to estimate the completion date of a project.

When conferences were cancelled wholesale for the Covid 19 pandemic, all deadlines relaxed, to what seemed like universal relief and no reduction in shipping, but once conferences seemed plausible again, deadlines returned without a thought 🤦‍♂️

I’ve found a couple tools help with launch planning:

  1. Listing tasks required for launch
  2. Agreeing to launch stages

Making shipping a priority is more fun, too. Deadlines feel like work, shipping feels like a challenge.

https://signalvnoise.com/posts/2486-bootstrapped-profitable-proud-github
Posted on by Erik

Praise for a task tracker 📉

I just wrapped up a three month project in a new tech stack. From the beginning to the end, I was regularly asked: “Will this be done in time?” I was new to the tech, so it was difficult to estimate. The best I could do was document tasks as they revealed themselves, and then point at the percentage of tasks complete as a measure of progress.

For the first couple months, I added more tasks than I closed. The scope of the project seemed like it would grow unbounded, but then it leveled off. Today, I closed the last task. Amazing, and it wasn’t that hard, because we at least had an agreed-upon task tracker. I just needed to tend it.

Some features I like:

  • Using the same system used for tracking bugs. This frees folks to use whatever tracker they prefer. A few colleagues prefer a simple spreadsheet of tasks in descending priority, for example. It also enabled folks to use familiar bug tracking tools, like subscribing to updates, assigning ownership, commenting, etc, to communicate about tasks
  • At least trying to present a burndown chart. Such a chart is the most accurate tool I’ve found for estimation; even if we can’t estimate the completion time, we can say the job will be done when the number of tasks drops to zero, and easily follow along on the chart.
  • Organizing tasks in a variety of ways, notably, differentiating organization by project from organization by week
  • Organizing tasks by blocking relationship. In other words, enabling me to specify this task depends on that task. Identifying branch nodes in this tree as milestones is helpful for maintaining a sense of momentum

Some usage patterns I like:

  • Presenting the tracker in a periodic (agile, 4DX) cadence meeting and using it to structure discussion. Avoiding tracker maintenance was helpful for maintaining meeting pace
  • Agreeing on one approach to tracking helped focus attention and minimize maintenance cost, though an alternative popped in and out mid-project, and the project launch used a different tracker
  • Layering trackers. For example, a team-level tracker prioritizing several projects, each with a project-level tracker prioritizing tasks. A product manager might manage the team-level, and each work-stream might manage the project-level.
  • Discussing deadlines in terms of the list of tasks to complete, as opposed to a subjective commitment. Rough estimates help in this context, eg 1 hour, 1 day, 1 week. Summing the rough estimations, and comparing the result to the desired date, are at least rational processes. Given the list of tasks, we can also have an objective discussion about priorities.

Posted on by Erik