The Anatomy of the Demodesk Agile Framework
How we dropped “fake scrum” teams to fix our product development
Introduction
There are a lot of approaches for operating product and engineering teams and while the discussions around it might not be as heated as developers arguing about tabs vs. spaces, one sees a lot of different opinions from various authors and industry leaders.
In this article, we’re going to give an overview of problems we faced at Demodesk and how we resolved some of them by introducing a new organizational framework.
The “Demodesk Agile Framework” outlines the team composition and processes of our product and engineering teams. It is heavily inspired by the “Pipedrive Agile Model”.¹
(If you want to learn more about Pipedrive’s framework, I also highly recommend this article by Jurgen Appelo)
Our framework introduces a couple of core concepts and roles, most importantly, the “launchpad” and “missions”.
This not only helped us solve some of the biggest problems we faced in our previous “fake scrum” cross-functional teams, but has also allowed us to more easily define interfaces and processes, especially between product and engineering.
Motivation and pain points
Before the switch, Demodesk had three product engineering teams with dedicated product owners and engineers. The split was done according to vertical product areas: “scheduling”, “meeting/conferencing” and “sales assistance”.
Our product development was driven by a lot of hypotheses and experimentation which means our focus could switch between product areas from quarter to quarter.
Tying our engineers, product managers and designers to specific product area teams made it harder to efficiently allocate resources to bigger projects.
As Demodesk grew in functionality and complexity, the maintenance effort of keeping everything running smoothly increased as well.
As a result, our engineers would frequently get pulled away from new product development projects to work on maintenance tasks, and the projects wouldn’t progress at the rate we wanted.
While some interruptions are inevitable, we wanted to make some changes in order to increase productivity and happiness.²
Framework overview
The following sections define the core concepts and processes.
Tribes — the new definition of bigger teams!
A tribe consists of an interdisciplinary team (mostly engineering and product/design) that owns one bigger area of Demodesk’s products.
We currently operate in one single tribe which is supported by a platform team.
As we grow, we want to keep the tribe sizes between 15 and 25 engineers. This seems to be a good trade-off between being big enough to be flexible without running into capacity issues while keeping the mental overhead of knowing all about the owned service area still manageable.
Launchpad — keeps the lights on
The launchpad is responsible for running the services the tribe owns. It takes care of maintenance tasks, fixing bugs, as well as owning cross-department communication like providing technical support for customer success.
Launchpad engineers don’t work on any major feature development but rather focus on refactorings, small tech/product/UX enhancements, tooling improvements and resolving debt.
The launchpad team is the “default” team for all engineers of a tribe, but it’s a very dynamic team as its members and size vary significantly as missions take off and land. Ideally, we will have at least three engineers on the launchpad team at a time; however, these constraints can vary depending on a tribe’s maintenance efforts.
As developers rotate between being on missions and being on the launchpad, they gain broad system knowledge which helps us prevent knowledge silos.
Most developers prefer building shiny new features over doing maintenance work and this framework allows us to ensure that everybody gets the possibility to regularly build new features while also ensuring that ongoing maintenance is a shared effort.
In addition to their maintenance responsibilities, launchpad members also take part in planning for future missions and support running missions (common examples are high-level concept reviews of solutions a mission team is working on or providing input as a technology or domain expert).
While designers and product managers also support the launchpad work, they usually spend most of their time on missions.
Missions — the delivery machine!
Missions are where innovation happens and have only one goal: product development to tackle specific problems we want to solve for our customers.
Mission team
A mission consists primarily of an interdisciplinary team of engineering, product and design. But it can also include members from business intelligence, customer success and marketing on an as-needed basis. A mission is a full-focus team effort to ship something meaningful.
A common setup for small missions includes one product manager, one designer and two developers.
Anybody can be part of a mission. When it comes to staffing upcoming missions, there is no strict process. We keep engineers updated on upcoming missions that are in the planning process, and engineers might already state their interest in them.
When a mission is about to be staffed, we often simply ask on Slack who is interested in joining one of the upcoming missions. This generally works quite well. If more engineers than necessary are interested in joining a mission, the mission lead and launchpad lead will make a decision (we’ll learn more about these two roles later).
When a developer is on a mission, their main focus is to ensure that the mission “lands” successfully. They know they can rely on the launchpad engineers to take care of any maintenance and support tasks that need to be resolved.
This helps us to reduce the amount of interruptions and context switches and the corresponding lack of focus, so that engineers can “get into the flow” as often and for as long as possible.
Productivity increases when we can maintain periods of what psychologist Mihály Csíkszentmihályi calls flow, described by people who experience it as “a state of effortless concentration so deep that they lose their sense of time, of themselves, of their problems.” […] Flow requires focused attention; interruptions break flow.³
Duration and timeline
Missions can take anywhere between one to eight weeks. Aiming for four to six weeks works best for us and we prefer splitting bigger projects into smaller separate missions (especially if we might be able to work on them concurrently).
There are different phases during a mission and especially product managers and designers invest a lot of time into preparing a mission before the actual lift-off (e.g. doing user interviews, gathering customers’ pain points etc.).
During the mission itself, the organization and delivery are completely up to the mission team. Most teams decide to do continuous delivery for smaller chunks of the mission to gather insights on how the new solution is used by actual customers (new functionality is usually hidden behind feature flags).
Bigger missions often have a kick-off week where all team members of the distributed team come together in one of our office hubs.
When “landing” the mission successfully is at risk, the mission team consults the launchpad lead to find a solution like extending the mission by a week or by getting more support from the launchpad.
While the framework allows for extending missions, the preferred option is to land on time. One problem with extending missions is that it can lead to capacity issues on the launchpad or delay the lift-off of other planned missions.
An encouraged pattern that helps mission land on time is keeping the mission’s scope flexible, so that the team can reprioritize small enhancements as they go. To make this easier, missions have strict success criteria and the most important goal is to make the mission a success. This not only encourages building MVPs over fully-fledged features, it also allows the mission team to come up with an easier solution to resolve a problem.
Rotating roles
The framework provides 4 main engineering roles
- Launchpad Lead (dynamic role)
- Mission Lead (dynamic role)
- Support Engineer (dynamic role)
- Engineering Manager (static position)
The engineering manager role is the only one that is static (and in fact a “position” with a dedicated title), all other roles are dynamic and anybody can take them over.
Encouraging engineers to take over leadership roles has proven to be a great success for multiple reasons:
- It gives everyone the opportunity to see our processes and organization from different perspectives
- It creates an atmosphere where everyone feels encouraged to give feedback and speak up if they don’t like something
- Engineers take a high level of ownership throughout a mission’s lifecycle and during launchpad work
- Every engineer can provide a different perspective that helps with process innovation
- Taking additional responsibilities and to “experiment” with a leadership role enables great personal and professional growth
👸 Launchpad Lead
On the launchpad there is one person who owns the role of the launchpad lead. That person usually maintains the role for two months.
The high-level objective of the launchpad lead is to ensure that the team operates smoothly. This means that they will moderate a couple of operational meetings (eg. stand-ups, retros, optional backlog grooming sessions, etc.). They will also report how the launchpad is doing in our “Engineering Weekly” meeting.
As part of our feedback culture, the launchpad lead holds regular “operational 1–1s” with all launchpad engineers. This helps them to learn about potential issues with our processes and allows them to improve accordingly.
Furthermore the launchpad lead is the main contact person for communication outside of the engineering department.
These responsibilities are documented and all launchpad leads are expected to follow the basic guidelines but are also encouraged to challenge the processes and experiment whenever they have new ideas.
Besides these operational responsibilities, launchpad leads are also expected to thrive for continuous improvement of the launchpad processes, by questioning the status quo and experimenting with new processes or tools.
👩🚀 Mission Lead
Every mission has one mission lead who is accountable for the execution and landing of the mission.
The mission lead is usually the one responsible for holding the operational meetings and high-level planning of the mission. However, based on our experience, they will also heavily involve the rest of the team with these tasks.
To ensure that all mission team members feel comfortable in their role during the mission, we encourage the mission leads to have regular “operational 1–1s” with everyone. These 1–1s are just a quick check-in on how the other person is doing, whether they see some risks with the mission or the progress etc.
The mission lead role is assigned before the mission lifts off and doesn’t change during the mission itself. The “dynamic part” of this role comes from the fact that in a future mission someone else will become the mission lead.
🧑🔧 Support engineer
Every week the launchpad team appoints a support engineer. The main responsibility of the support engineer is to keep an eye on our Slack channels where bugs are reported by team members or customers and monitor any errors that may come up in our observability tools.
Additionally, they are the first point of contact for supporting other departments like Customer Success when they need technical guidance to help customers.
Having this dedicated role helped us to significantly improve the error reporting process, as the support engineer has enough time to draft detailed bug reports with all the necessary information to resolve the issue.
Similarly, we can now provide more input and support to other teams like customer success and product.
The support engineer role is no full-time job and the engineer usually has enough time every day to do normal launchpad work.
Conclusion
The Mission/Launchpad framework turned out to be a great success for Demodesk! We are committed to continually changing and improving the framework, so this is just a snapshot in time of our current workflow.
We were able to resolve some of the pain points we faced in our previous scrum teams, eg. improved resource allocation, faster product velocity and increased developer happiness.
This was just a high-level overview of the framework and we plan to publish a series of in-depth articles that cover the missions in more detail (eg. how we decide which mission to work on or the landing process), how we onboard new developers, as well as how we do continuous improvement.
Interested in working at Demodesk?
The mission framework is only one of many aspects that make Demodesk a great place to work for software engineers!
We are an ambitious and diverse team that’s building the future of customer-facing meeting software.
If you want to find out more, we’d love to have a chat with you as we’re always looking for curious software engineers!
Check out our current job openings at the link below:
[1]: Pipedrive Agile Framework: A Detailed View (Kadri, Juan Gutiérrez) and Pipedrive Unfixed (Case Study of a Unicorn Company) (Jurgen Appelo)
[2]: Site Reliability Engineering: How Google Runs Production Systems (Betsy Beyer; Chris Jones; Jennifer Petoff; Niall Richard Murphy)
[3]: The Effective Engineer (Lau, Edmond)
