How to Scale Responsibilities From Scrum Team to C-Level
This article aims to paint a simplified yet big picture overview about the responsibilities of some major roles across an organisational hierarchy ranging from the Scrum team level right through to C-Level — however flat that hierarchy may be.
I am starting off at the team level for two reasons: the first is that it’s likely to be more relatable for most people. The operational level is, by nature, closer to a broader and more diverse group of people. The second reason is that Scrum prescribes responsibilities on the team level in detail, while not extrapolating to C-Level (on purpose!*). I’m making this extrapolation the topic of this post, because I’ve seen (and struggled through) various situations with unclear C-Level responsibilities and guidelines on how to scale down to team level.
Responsibilities in a Scrum Team
For each role I’ll list the operational responsibilities and then elaborate on what they essentially mean.
The Product Owner
Product Owners in Scrum are responsible for creating or heading the Product Backlog. This includes the inception and validation of ideas, required research, conceptual work and eventually, the creation of User Stories. I know those are not a Scrum guide requirement, but let’s be honest, most of us want a prioritised backlog where a PO highly INVESTs in User Stories. Why does a Product Owner do all that? What is their prime motivation and responsibility? It is the generation of value and therefore, effectiveness.
The Team
Development teams in Scrum are responsible for implementing or executing whatever is deemed the most important and/or most valuable, and they self-select how many Backlog items they commit to completing in a given Sprint. Why is this self-selection so important? To give the team autonomy? Partially yes. But now let’s ask, why is autonomy so important? The answer is only with the autonomy to decide how much to do in one Sprint will the Team gain full control of quality. If no one forces the team to compromise and take shortcuts for the sake of getting more scope done at the same time, they can fulfil their sole responsibility: Delivering high quality products.
Now since this might be controversial, I’ll elaborate. Why is it the team that needs to focus on quality? Shouldn’t it be the Product Owner? After all, a higher quality product will surely deliver more value won’t it? Of course! But with all kinds of creative work and software development in particular, there can be an unseen lack of quality popularly referred to as technical debt. Your product might be ready and usable but these questions may remain: How long will it work? How far will it scale? How much effort does it cost to maintain it? How easy is it to extend?
Technical debt has an impact on all these aspects and the team is responsible for keeping this in check.
To teams struggling at getting permission to tackle technical debt, which already is an anti-pattern, try defining its cost. Use these arguments to highlight the meaning of technical debt for your product.)
The ScrumMaster
The role of the ScrumMaster is pretty clear. Yet every now and then I encounter questions in the form of:
“Is [this] still the responsibility of a ScrumMaster?”
Often these questions come with a connotation that the topic shouldn’t be. The responsibilities of a ScrumMaster are manifold, but fortunately can easily be checked in the Scrum-Guide.
To summarise: ScrumMasters, please care for facilitating events and generating a common understanding of all things! Care for agile best practices and help other roles to self-organise. Help people to continuously improve and work with other ScrumMasters to drive organisational agility.
What is the common driver behind all of this? If value and effectiveness are already being taken care of? And if those things are being done effectively and with high quality, what’s left to be improved? The ScrumMasters’ sole responsibility boils down to efficiency. To make sure we’re doing things in the best way possible.
Disclaimer: If effectiveness is not taken care of by the Product Owner and the team doesn’t care enough for quality, then of course it remains a task of the ScrumMaster to coach them to get there. After all the following responsibilities must always be a priority:
- Effectiveness
- Quality
- Efficiency
“There is nothing quite so useless, as doing with great efficiency, something that should not be done at all.” ― Peter Drucker
I can’t help but promote (without affiliation!) the best book on this topic in quite some time: Scrum Mastery!
Credit Where Credit is Due
This view of Scrum is inspired by a great post on Agile42’s blog by Martin von Weissenberg, who expertly lays out how the three Scrum responsibilities enhance one another:
- Effectiveness (delivering customer value) lowers pressure on teams and provides time and head space for quality measures and process improvement.
- Quality lowers pressure on teams by causing less backtracking and bug fixing which again allows time to deliver more customer value instead.
- Improving efficiency again directly contributes to being able to do more quality work in the same amount of time. We get this by enhancing ways of working through regular retrospectives.
Responsibilities in a Management Board
The Chief Product Officer (CPO)
The CPO’s responsibilities are defined as building “a great product that avails sustainable value in terms of revenue and profits for the business” and “is responsible for all product-related matters. Usually this includes product vision, product innovation, product design, product development, project management and product marketing.”
Everything from the product vision to various stages of product development and product marketing is very specific already. The overall goal — the why behind those activities is value generation, which negates to the use of certain budgets to generate enough revenue to make a profit. The capability of producing a desired output (which for any investment is profit) is called effectiveness. Where the Product Owner of one team owns that teams Product Backlog (one piece of the puzzle) the CPO owns the company Product Backlog and is responsible for sizing and prioritising items in that backlog.
The Chief Technology Officer (CTO)
The responsibility of a CTO is to “make decisions for the overarching technology infrastructure that closely align with the organisation’s goals”. Additionally, a “CTO should be aware of new and existing technologies to guide the company’s future endeavours.” Let’s dive into the reasoning behind these things:
- Why do we need to make decisions regarding the overarching technology infrastructure?
Overarching is the operative word in here. In the details, of course, there shall be widespread autonomy with (Scrum?) teams. However, on the big scale, technological decisions need to be aligned and consistent. Otherwise (again) we accumulate technical debt and it will become increasingly hard to retain quality in the products we’re building. - Why align technological decisions with the organisation’s goals?
If technological decisions are at odds with the goals of the organisation, we’ll see conflicts on a team level. No ScrumMaster can mediate conflicts between opposing goals communicated to development teams and Product Owners. - Why be aware of current and emerging technologies?
We don’t always have to be bleeding edge when it comes to technology (it’s called bleeding edge for a reason). But we have to make sure that we don’t fall behind and lose the competitive edge of our technology. We need to accumulate the opposite of technical debt.
With regards to our products, the CTO is responsible on the highest level for the exact same things teams are responsible for on a ground level. This includes:
- How long will our technology stack work?
- How far will our products scale?
- How much effort does it cost to maintain our product suite?
- How easy is it to extend our product offering and integrate with one another?
A CTO’s responsibility has the same as the responsibility as every role within the tech organisation. Everyone — between CTO and Junior Associate Development Intern — is responsible for quality. As the VP Technology in one of my last companies put it:
If you breathe, you are responsible for quality. — Juan Vidal
The Chief Operating Officer (COO)
“The COO is responsible for the daily operation of the company.” This includes weighing effectiveness and efficiency. In a company that has a CPO there is a role responsible for the effectiveness of its product offering. A COO still needs to cater to the effectiveness of its internal services, but overall should put greater emphasis on company efficiency.
Let’s compare the responsibilities of a ScrumMaster with a COO:
- A ScrumMaster makes sure a team works well together internally and communication between the Product Owner and team is smooth.
A COO has the responsibility to make sure all teams within a company work well together and also must ensure that communication with the management and other stakeholders is smooth. - A ScrumMaster drives the improvement of the team’s internal processes as well as supports the collaboration with others, as needed.
A COO must keep overall company processes working. Ideally above industry standards to achieve a competitive advantage. - A ScrumMaster caters to the general mood inside the team, drives self-improvement, learning and escalates if the required skills are not present or cannot be obtained.
A COO should be “maintaining and monitoring staffing, levels, knowledge-skills, attributes […], expectations and motivation”. (Wikipedia)
Leadership Responsibilities of C-Level Roles
The responsibility of a role remains the same regardless of how well this role on any given level of a hierarchy is fulfilled. This article doesn’t cover leadership aspects of C-level roles on purpose. The topic of how roles higher in the hierarchy are supposed to scale themselves by teaching, coaching and supporting people in their area of responsibility is a whole different domain — a different dimension of responsibility.
Scaling Responsibilities
This now leads us to this simplified overview of responsibilities at scale:
- Effectiveness: CPO → … → Product Owner
- Quality: CTO → … → Team
- Efficiency: COO → … → ScrumMaster
This picture is how I wanted to draw this initially and shows the silos of responsibilities across the levels of hierarchy in the organisation:
This first version is the most simplified approach, but it leaves out the aspect of collaboration and therefore would go against the heart and soul of Scrum. Let’s add that required overlap between the roles. A vertical view of those overlapping silos would look like this:
Now, let’s look at the nature of those overlaps. What do these roles collaborate on because their very own responsibilities depend on it?
Product Owners work with teams to elaborate on a product vision and roadmap. ScrumMasters work with Product Owners, sparring in many ways on all topics around work and teamwork. Teams work with the ScrumMaster for ongoing self-improvement.
The very same overlap does exist at the highest level of the company. There are mutual interests between C-level roles. While there may be more, the following shall demonstrate the responsibilities extrapolated from the team responsibilities in the same areas of overlap.
The long-term product roadmap is an essential responsibility of the CPO. A long-term technical roadmap cannot be devised by a CTO in isolation from the former.
The overlap between COO and CTO is similar to the one between ScrumMaster and Dev-team. For example, caring for the release process (on company respectively team level) and for automation and/or shipping. Most things which at the start of a business are done manually, hold potential value in automation. Time spent here is time (or money) that could be spent elsewhere.
The CPO and COO have the same common interest as a Product Owner and ScrumMaster, such as measuring value generation, the ability to plan better while retaining agility, reporting and ideally the automation of it (at first cumbersome, and then all of).
Do You Have a Bigger Company With More Roles in Between?
Any roles along the reporting lines between the highest office and teams ‘on the ground’ retain the very same responsibilities. They are inherited, so to speak. What changes is primarily the area or size of responsibility. But what the people in those roles are responsible for remains the same.
Conclusion
Scrum is successful because it takes all the responsibilities from an overpowered (and conflicted) role (the project manager) and puts the responsibilities where they belong — on three roles who shall focus on one responsibility and hone their capabilities in the respective fields.
These responsibilities are in constant conflict — if only because of the fact that there is always more work to do than time and money allow for. Collaboration is key to overcoming these conflicts and pave the way for productivity. However, the overlap in the operative field of work does not mean that any role can neglect their main responsibility. That holds true for the team level as for the C-level.
Depending on the situation of the company, the overlaps and their weight might shift. Exceptional situations might call for exceptional measures after all. Still, it’s important to remember the balance between the main responsibilities and the value within — both on a team and C-level.
The Scrum guide is short on purpose. Scrum doesn’t prescribe things beyond team level for several reasons. First and foremost, is that whatever works on team level does work because it’s based on Scrum values. While scaling, people shall rely on those values and chances for success are quite high. Second, is that with a more complex framework — based on more rules instead of values — it is suddenly less adaptable and therefore cannot be applied by so many teams.
Links other than Wikipedia and the Scrum guide:
A note from the editor:
This article is for educational purposes only. The structure described does not reflect how Quandoo is currently structured. To find out about our structure, come and work with us.
