Engineering @ Pluralsight: Continuously Delivering Value
At Pluralsight we’ve put a lot of thought and effort into developing the engineering practices we use every day. These practices are based on principles that we’ve come to value and those principles lead to practices. In order to both preserve and evolve our principles and practices, we had our engineers nominate some of our most respected engineers to codify them; this resulted in our Engineering at Pluralsight document. You can read more about that here.
If you take a look at that document, you’ll notice that on the left side of each page there is a principle that we value, and on the right side is a list of items that we Do, Encourage, and Avoid. The Do section are items that we have agreed all engineers will do at Pluralsight. The Encourage section is a nod to team autonomy, they are things we value and encourage but not all teams are required to do them if they can find alternative approaches that still accomplish the value on the left. And the Avoid section are things we all agree to avoid at Pluralsight.
There are several principles in this document, this post is going to focus on the first: Continuously Delivering Value to Production.
What We Do
To support continuously delivering value to production, here are the practices that we ask all engineers at Pluralsight to adopt:
We focus on flow efficiency over resource efficiency. Which is to say that we value flowing value to production over everyone being busy or the system appearing to be busy. The terms flow efficiency and resource efficiency come from the Lean Manufacturing world. At Pluralsight, Lean Software Development is our flavor of Agile. Valuing flow efficiency supports practices such as Mob Programming, Pair Programming and single-piece flow. Single-piece flow suggests that we will have a team focus on a single feature (or story to use an Agile term) and will work on that feature together until it is released all the way to production. In a traditional, resource efficient world this causes discomfort – for example, people might ask “Why have four people work on a single feature when you could have four people working on four features simultaneously?". The answer is we value flow efficiency and we believe we can flow value to our customers faster and more efficiently by focusing on just one (via mobbing) or two (via pairing) items at a time to production.
We frequently release small changes to production. In a recent month we deployed to production over 1,000 times! This is spread across about 40 small teams, so about 6 releases to production a week per team – small, frequent releases. Single-piece flow, small WIP (Work in Progress) limits and several other principles help us to achieve this.
We track our work on digital Kanban boards. We use Kanban boards to track our work. These are boards that show, at a glance, the status of what we are working on. Simply put, they have columns that essentially communicate To Do, Doing, and Done, etc. This allows us to be able to prioritize work and pick up the next most important item and move it through to production. It also allows us to see how much work we have in progress and manage that work with WIP limits.
We set and follow work in progress (WIP) limits. Work in progress limits are a way to help the team recognize when they are trying to do too much at once. Our Kanban boards have WIP limits set for each column and if we exceed that limit the column will turn red. Typically when this happens the team will start expressing feelings of chaos, being overwhelmed or excessive context switching. Our WIP limits serve as a reminder to focus on flow efficiency, not just being busy.
We extract platforms from working code. This speaks to the amount of (or lack of) up front architecting and planning we do. While it is important for us to think deeply about the features and other work that we do, we try to avoid creating massive designs and architectures up front. We do just enough for us to see ahead so that we aren’t walking in the dark but we aren’t creating entire platforms or architectures before we start on them. Pluralsight used to be simply a website for finding and viewing high quality video content for learning new tech skills. Today it is an entire technology skills platform that goes far beyond that. But that platform wasn’t all envisioned and designed years ago – rather, it emerged as we identified new value propositions for our customers and delivered them to production. As more and more value was delivered to production we then began organizing them into a platform. This helps us to focus on delivering value first and avoid creating large platforms upfront that have not been validated by our customers.
What We Encourage
To support continuously delivering value to production, here are the practices that we encourage all engineers at Pluralsight to adopt. They are important to us and we believe that they will bring additional value, but we also respect the autonomy of our teams and engineers. So, while we believe that these are valuable, we allow some flexibility here based on the context in which each team is working.
We encourage trunk-based development. Trunk-based development means that when we push code to our repository, we push it to the master (or trunk) branch. It also means that we always keep the master branch in a deployable state – that’s deployable, not deplorable. :) To accomplish this we use feature flags rather than feature branches. A team may be working on a feature that is incomplete but they still want to push it to the repository. In order for that incomplete code to be pushed to the master branch it may need to be surrounded by a feature flag that essentially ignores that bit of code. This requires a bit of rigor, but it means that we are frequently validating our code as it goes through our CI processes and is deployed to stage and production. It allows us to do smaller, more frequent deploys and validate more frequently that we haven’t caused any unintended regressions to surrounding code. On teams that are not practicing single-piece flow, it also allows them to integrate their code together often on the multiple (although few) features that are concurrently in development.
We encourage single-piece flow. While we expect all engineers to set small and resonable WIP limits, we don’t require all teams to use single-piece flow. For example, a team of 6 who choose to pair instead of mob would likely have around 3 pieces in flow at any given time. We value the mindset of working on a single thing at a time but also value teams choosing the best way to work for their team within their context. In pairing teams, they may also gain value from a single-piece flow mindset by focusing on a single larger feature area. For example, where possible it would be better to have two pairs on a four-person team working on two different parts of a single feature rather than working on two totally separate features.
We encourage limiting our planning horizon. We’ve touched on this a bit already, but typically we have very small backlogs. In fact we are very hesitant to call anything a backlog. If you were to imagine a Kanban board with To Do, Doing, and Done columns, the To Do column is not full of items to do in the next year or quarter or even month – ideally they are items that we expect to get to in the next week or two. We don’t work in sprints and so we aren’t planning for one or two week sprints, either. Rather, we’re identifying the next most important piece of value we can provide to our customers and that is our planning horizon. There may also be some product discovery work that is happening beyond that horizon for “what’s up next” after we deliver the current piece of value, but that is about the extent of our planning horizon. This allows our cross-functional teams (which consist of a devops engineer, product manager, designer and a few software engineers) to really focus on the work at hand and quickly deliver value in that area to our customers.
What We Avoid
This is essentially the opposite of the What We Do section. We ask all engineers at Pluralsight to avoid these practices.
We do not create big designs up-front. We discussed this already above, but this What We Avoid practice is another reminder that this is something we have specifically chosen to avoid.
We do not work unsustainable schedules. The practice of avoiding unsustainable work schedules supports lots of our values. It is a practice that supports the “continuously” part of “We continuously deliver value to production”. Working unsustainable schedules leads to delivering in bursts of overtime followed by lulls of burnout. It also supports the value we are delivering since unsustainable schedules inevitably lead to reduced quality and therefore reduced value to our customers. We explicitly focus on working sustainable schedules so that we can continuously deliver value.
Continuously delivering value to production is one of the many principles that we value at Pluralsight and have documented in Engineering at Pluralsight. These guiding principles and the corresponding practices have helped us to scale engineering at Pluralsight while communicating, maintaining and evolving our values and practices as we grow. It has been valuable for us to separate values and principles from practices – this allows us to tailor our practices to support what we truly value. Practices are a means to an end. The values, or principles, define the end and the practices are our current best understanding of how to reach the end. Have you given thought to the things that you value in your organization? If you were to create something like Engineering at Pluralsight, what would it look like for your organization?