The framework is not quite right for you? You can still contribute!
Different teams might require different frameworks to work as efficiently as possible in their contexts. However, having an higher level framework where all can contribute will further enhance focus, adaptability and knowledge sharing.
Scoro is very mindful about time because time is the ultimate asset. We have been seeking ways to increase focus time for quite a while already. In addition to making full use of our own product internally, we’ve also made other conscious efforts to improve on it, such as decreasing the standard meeting duration, not holding meetings without an agenda and a clear objective, implementing meetings-free Wednesdays, etc. However, out of all those actions, what I want to talk about in this post is how our software development framework helps us to ensure focus time without giving up flexibility.
In January 2022 (one year before this article was written) we started with our own flavour of the Pipedrive Agile Framework (aka: The Tribes & Missions Framework or simply The Missions Framework), which Pipedrive envisioned in 2018. As said, it is our own version of it because it has been adapted to fit our context better — Scoro has, as of today, a single product with a few different areas within it and a Product Engineering organisation of almost 60 people. The heart of it remains the same though.
The aim of this article is to explain those differences and the rationale behind them from the focus and flexibility angle. Meaning that the article will not explain the framework itself in detail, but will only cover the basics of it as much as needed for understanding. If you want to go deeper, I recommend going through these two posts by Kadri and me that already explain the framework in detail.
Different types of teams
Teams differ in nature, depending on the needs and context. And I’m not only talking about team topologies or ways of working, the team culture or habits, but the actual team size, which is directly linked to priorities, investments made into the area/domain, size of the responsibility areas, maintenance load, etc.
Given that The Missions Framework (with its dynamic re-teaming nature taken to the extreme) is intended for bigger teams (in Scoro, we call them Bases and they range from 7 to ~25 developers or from 10 to ~35 persons), forcing that team size just to match the framework requirements feels more like a hack to adapt the reality to the framework than actually finding the best framework to fit the reality. A framework should help us solve problems in the best way, but we should not artificially force the context to make the framework work well (and maybe end up not solving the problem efficiently as a result of it). This is applicable to any tool because, after all, a framework is just one type of tool.
What this means is that either we force all teams to be of a certain minimum size (tribes or bases everywhere!) or we cannot use The Missions Framework effectively. Or can we?
Following the framework vs. contributing to the framework
Smaller teams (and why not also bigger ones?) can then use the framework that fits their particular context the best, be it Scrum, Kanban, XP, Waterfall (yes, for some contexts) or whatever else. This means we can have a mix of teams working with different frameworks, all in harmony, provided certain high-level boundaries.
What The Missions Framework provides is a perfect fool for focus, collaboration and contribution — the missions. But what is a mission? For those who are not yet familiar with the concept — to put it shortly, a mission is an entity that defines a very clear problem to solve, an objective, where a focused team is created with the single purpose of reaching the mission objective. Since teams are created for the missions –we call them the mission crew — and then dismantled, then re-teaming is dynamic and happens frequently. And anybody can apply to join whichever mission they want. Thus, the missions can extend beyond the base of their origin (remember: base = a bigger team) and when a mission is created, anyone can join it, even if they are coming from another base or… any other type of team! This reinforces collaboration across teams, allows anybody to contribute to what they feel more passionate about, promotes knowledge sharing, ensures focus during the mission duration, and gives a lot of flexibility to adapt to any priority changes.
Thus, we have bases following The Missions Framework, whereas we have other types of teams contributing to The Missions Framework. This is the main difference between the Scoro Missions Framework and the original missions framework. To clarify the structure, this is how Scoro looks like from an organisation perspective:
That makes the company very adaptable and at the same time avoids context switching and ensures focus time. We have then two bases following the framework fully and other smaller teams using other frameworks that adapt better to their domain, size and context, but at the same time contributing to the main missions framework. People from the small teams can join the missions created by the bases and small teams can also create missions when they think this is the best approach, even if they normally work in a different way.
At this stage, you may be wondering two things:
- If the mission is fully focused, who is handling incidents, bug fixes and any other more reactive work?
- How is the team selected for a mission? What if there are too many or too few people opting for it?
Besides the missions, a base has a launchpad, which is a dynamic team focusing on more reactive work: bug fixes, maintenance, support, technical debt, small technical or product improvements, etc. If someone is not taking part in a mission, that person is automatically in the launchpad. People rotate between the launchpad and the missions. That should answer the first question.
Roles have not been introduced yet, but to answer the second question, one role needs to be specifically explained: the Mission Captain. However, for the sake of clarity and better understanding, let’s have a closer look at three roles:
- Mission Captain (MC). Every mission has a Mission Captain who is responsible for the mission, mission set-up, execution, ways of working and outcome. The MC is usually a software engineer, and any engineer (regardless of the seniority) could potentially be a MC. The MC works very closely with the Product Manager within the mission lifecycle. The MC is also responsible for ensuring that the mission has a crew and who is part of it.
- Launchpad Captain (LPC). Rotating role (3–9 months). The Launchpad Captain is responsible for the launchpad and the outcome, its set-up, ways of working and launchpad backlog prioritisation. They are working closely with PMs, support and other stakeholders to ensure the right prioritisation of the backlog. The LPC is also responsible for accepting the landing of missions in the launchpad.
- Product Manager (PM). The PM is responsible for “the” or one of the product areas within the base. They are responsible for the customer and business impact and ensuring that missions are very targeted from a product perspective, have a clear objective and good KPIs that can be followed. They work very closely with Mission and Launchpad Captains, designers and stakeholders.
The approach described above intends to go one step beyond the standard mission framework set-up and team set-ups as such because it is about being truly Agile and having a dynamic approach as a company, not only from a team perspective. It avoids a one-rules-them-all framework and looks for the best solution for every team’s context. All in all, it is about truly acknowledging the concept of “responding to change over following a plan”, while ensuring focus time from a framework/method/ways of working perspective, which has always been one of the core aspects of being Agile.
Want to experience this in action? Come and work with us!
