Home > Case Study: Screencastify

Case Study: Screencastify

Summary

Screencastify is the #1 screencasting browser extension for Chrome, and is extremely popular among educators. The product and development teams focus relentlessly on making the best possible product for their core user base of teachers in classrooms.

Here's how I worked with them to create a well defined product development pipeline, achieving a steady, predictable development cadence, weekly release schedule, and reliable model for forecasting the delivery of development milestones.

Challenges

The C-suite saw a new market opportunity and decided to build a second product in addition to their flagship product. To make sure they were first to market, they temporarily devoted their entire 4-person development team to the new product. The team was working on borrowed time, since every day that the new product didn't ship was another day they were putting off maintenance and feature development on their existing product. Lacking a coherent roadmap describing the path to market, it was impossible to predict when the new product would be ready. And with no defined process for turning business goals into development tasks, the team was spinning its wheels.

Insights

The company had a strong product vision and a team of competent developers, but too much refinement of features was happening after developers began writing code. The product team would describe a new feature leaving many details to developer interpretation, and the developers would immediately break those features up into technical to-do items.

Confusion grew as time passed and the context for these technical to-do items was lost. By the time a complete feature was delivered, it had usually diverged significantly from what the product team had envisioned, and the feature would have to be clarified and reworked.

On top of this, there was no defined process for prioritizing work based on business value. Features, bugs, and infrastructure chores would be addressed based on whatever seemed most urgent at the time. There was no clear finish line and therefore no way to measure progress.

Solutions

Reorient development and product routines around feature delivery

First thing, I worked with the team to reoriented all development procedures and routines around the delivery of features, instead of disjointed developer to-do items. Every feature has one developer who is responsible for delivering that feature top to bottom. To make this possible, the product team defines explicit acceptance criteria from the perspective of an end user. Now when a feature is delivered, the Product and QA teams were much more likely sign off on it the first time, without costly confusion and rework.

Milestone-based product roadmap

I also worked with the Product team to define coherent milestones against which we could track progress. To keep from getting too focused on product delivery at the expense of accumulating technical debt, we defined a flexible policy for prioritizing ad hoc bug fixes and maintenance chores into those product milestones.

Forecasting model for milestone completion

Within several weeks, we had achieved a steady, reliable cadence of feature delivery. This cadence, combined with the new milestone-focused roadmap, enables the product team to reliably forecast the delivery dates of individual milestones, as well as assigning a degree of confidence to those forecasts.

Key Results

Less than 15% variance week over week in features delivered means reliable delivery forecasting

Within two months of my arrival, the development team was delivering features at a pace that fluctuated no more than 15% week over week. It is now possible to accurately forecast the delivery of milestones, as well as visualize the effect of changing scope on those delivery windows. This makes for clearer communication of progress to key stakeholders such as investors, and enables marketing and other business initiatives to be coordinated with the product delivery timeline.

Weekly scheduled deployments with no costly code freezes

Production deployments occur at scheduled times each week and have been routinized to the point that any developer can execute them. The product team always knows when they will be able to see finished work in production, and there is no separate code freeze or deployment prep phase for the development team. Developers can continue working at their regular pace and deployments will happen on their set schedule.

Team has demonstrated ability to maintain process and self-organize

Through a structured phase-out of my involvement, the team has been able to take ownership of all elements of the new process, maintaining their pace of delivery in my absence. Periodic team retrospectives create productive discussion for improvement and commit routines to institutional memory with little or no documentation overhead.

Free Email Course:
Painless Agile Adoption

If you want to get started on your own, try my free 5-day email course. It details The Five Steps for Painless Agile Adoption. Each lesson is a mix of actionable advice for starting an Agile workflow, along with practical explanations of the reasoning behind each step.
  • Day 1: Features, Value, and the Investment Mindset
    Focus on the features, not the tech
  • Day 2: Organizing Your Development Board
    Believe it or not, it's not a to-do list
  • Day 3: Estimation
    You'll always be wrong when you estimate time. Use this one weird trick instead.
  • Day 4: Roadmapping and Forecasting
    If you don't know where you're going, you don't know when you'll get there.
  • Day 5: Standups and Retrospectives
    Making sure things get done and continue to improve