The important role Scrum bubbles play in Agile project success

In an earlier post The Scrum Product Owner challenge affecting your project made reference to a “Scrum bubble”. This is my way of explaining one of the things that enables scrum teams to be effective and deliver Agile project success. There are a wide range of technical approaches used by Scrum teams that also lead to their effectiveness, but these are more development oriented rather than business oriented. They may be the subject of another blog.

What is a Scrum bubble?

I’m calling a sprint a bubble because it is an artificial construct with the specific purpose of constraining those factors that add complexity, eat up the time of technical resource, but deliver little value to the customer. The Scrum bubble keeps the team protected and creates a stable environment for them to solve the limited number of problems taken into the next sprint. You are shrinking the problem space and allowing the team to “get on with it” – a very similar approach to the old expression “Take some bright people, lock them in a room, and don’t let them out till they’ve solved the problem”.

Scrum sprints are bubbles that protect the team from complexity

The complexity factors held in abeyance for the sprint include:

• Managing conflicting stakeholder needs, these are outside of the sprint and managed by the Product Owner
• Changing requirements, may impact the Backlog, but not the current sprint
• Long project timeframes and long feedback loops, where the project continues to build, and build on, functionality that the customer hasn’t seen
• Complex dependencies (i.e. chains of dependencies and interactions, many of which simply can’t be understood in advance)
• Design work and estimation of tasks that may never be done as planned as they are too far in the future to really understand the dependencies
• Doing impact assessments and change requests once you get to the point where you really understand what needs to be built, and generally justifying change rather than accepting it as a given.

Scrum bubbles shield the delivery team from other ‘magical’ things

A scrum sprint is also a bubble because there are a lot of ‘magical’ things that happen that the delivery team is often unaware of, but without which it couldn’t function:

• The original, and continued, justification of the investment of organisational capital required to keep the team running
• Engagement with, and management of, the range of stakeholders broader than the SMEs on the project
• Ensuring the team’s delivery remains aligned with the strategy and direction of the wider organisation
• Provision of the physical environment and specific tooling the team needs
• Management and reporting of project finances, management of any procurements required
• More formal communication than that provided by the team “radiation” of information through task boards, charts, etc.
• Planning, hiring, onboarding, training, and divestment of human resources as required, which may also include managing one or more contracts with suppliers.

Scrum Guide responsibilities and the Scrum bubble

The Scrum Guide hints at a number of responsibilities that are key to creating a protective bubble around the delivery team, including these responsibilities which are outlined on page 5:

• “The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address this with the Product Owner.”
• “For the Product Owner to succeed, the entire organization must respect his or her decisions…No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.”

However, some of the responsibilities are not mentioned in the Scrum Guide, and this is territory where a Scrum Master with both Agile and traditional project management skills can be a real benefit to the Product Owner and the project.

Why is a Scrum bubble important and why should you care?

If you’re on a delivery team you should care because understanding the wider context, and the critical role of the Product Owner as the mediator between the interior and exterior of the bubble, will help keep you focused on business value. Simply looking inwards all the time can lead to a team that thinks its existence needs no justification and/or can reinforce what in many organisations is a very old schism between IT and “the business”.

If you’re a project manager you need to understand how your role and accountabilities need to change, and how important it is that you ensure the Product Owner is fully engaged and is as well supported by you as they can be.

If you’re a Product Owner or wider stakeholder then you should care because, without the bubble and the protection it provides your delivery team, you’ll find more team time spent on non-value adding activities and less time producing software. Sprints are not just time-boxes, they are effectively locked containers that reduce complexity, and allow continuous checking, calibration, and improvement.

From a governance perspective you should care because the rules of Scrum set up a very different control framework to a traditional project. Rather than formal, written requirements and plans approved in advance, the delivery of an Agile project is controlled through the direct interaction of the Product Owner with the delivery team (so it is the Product Owner who should report to a Steering Committee if such a group exists).

Care should be taken to appreciate that the Product Owner has direct on-the-ground experience of the project and they need to be properly empowered to make binding decisions, many of which will require a much quicker turnaround than your typical monthly Steering Committee cycle.

Carl Weller is a Principal Consultant specialising in project management and Agile leadership, based in our Wellington office.