Resurrecting the Much-Maligned Scrum of Scrums

I have encountered many in the Agile community who love Scrum but seem to hate on the practice of Scrum of Scrums. Others describe their Scrum of Scrums as an overarching meeting of Scrum Masters, or as a meeting for a Product Owner team.

In my experience, however, a Scrum of Scrums is a great way to scale the principle of the Daily Scrum, with the purpose of re-planning development work. If done properly, it’s a great practice that implements Scrum’s core principle of bottom-up knowledge creation.

Back to Basics

Let’s consider the Daily Scrum first. As the Scrum Guide™ describes, this is an inspect and adapt event for the *Development Team*. It is of the Development Team, held for the Development Team, and run by the Development Team. Only the Development Team members participate in the Daily Scrum. The Scrum Master helps out by teaching the Development Team to have a proper and effective Daily Scrum, reminding them of the purpose of the event, keeping it focused, and sticking to the time-box. The event itself is for the Development Team, and nobody else. The Daily Scrum’s purpose is for the Development Team to inspect and adapt their way towards meeting the Sprint Goal and delivering a potentially releasable increment that delivers value to stakeholders.

Although the Scrum of Scrums is a way to scale the Daily Scrum, the event itself is not a mandatory part of Scrum. It is not defined in the Scrum Guide, and the Scrum Guide is the definition of Scrum — therefore the Scrum of Scrums is not part of Scrum itself. It is considered “complementary”, meaning the practice is not part of Scrum itself, but can be used in addition to Scrum. It is an extension of Scrum for a certain context, respecting Scrum’s underlying principles. Doing a Scrum of Scrums, if it makes sense for your context, is in line with the “ScrumAnd” line of thinking. Actually, you can do it even if it doesn’t make sense, and Scrum will help shine transparency on whether the practice helps or not. Having said that, I recommend you try to honor Scrum principles when you implement complementary practices.

Principle-Based Scaling

If we consider that the “Scrum of Scrums” is a way to scale the Daily Scrum, why would the Scrum of Scrums be only Scrum Masters? Why wouldn’t it be Development Team centric?

I’ve heard of organizations practicing Scrum of Scrums as if it’s just a status meeting of all the Scrum Teams in an organization, regardless of what product they are on. This doesn’t strike me as a “principle-based” scaling of Scrum. It seems much more like a legacy/waterfall status rollup meeting in my mind. I subscribe to Ken Schwaber’s view that the Scrum of Scrums is for teams who are working together, on the same, integrated product.

I believe and have experienced that a Development Team-focused approach honors the principles behind Scrum, honors the principles of the Daily Scrum practice at the team level, and results in more value being delivered sooner to customers. In my experience, an effective Scrum of Scrums, for and by the Development Teams, leads to a big boost in the Development Teams’ self-organization skills, impediments being removed quicker, higher quality products, and higher valued products delivered sooner.

It would appear that the most credible sources in the industry agree that the Scrum of Scrums should be Development Team focused.

Let’s start with Scrum’s co-creator, Ken Schwaber. In his book, The Enterprise and Scrum, Ken describes the Scrum of Scrums this way:

“Scrum of Scrums are short, daily Scrum meetings at which an engineer from each team working on an integrated product gather to… keep track of progress between parts of the product so that they can more closely monitor any dependency or timing problems.”

Mike Cohn, who has probably trained more Scrum teams than anyone on the planet besides the Scrum creators themselves, has this to say:

“Each team would then also designate one person to attend a scrum of scrums meeting. The decision of who to send should belong to the team. Usually the person chosen should be a technical contributor on the team—a programmer, tester, database administrator, or designer, for example—rather than a ScrumMaster or Product Owner.”

Craig Larman and Bos Vodde, who have extensive experience coaching Large Scale Scrum to 500 or more people working on the same product , describe the Scrum of Scrums as a Development Team “coordination technique” that people scaling Scrum should try. They suggest that you avoid turning the Scrum of Scrums into a status meeting or a Scrum Master coordination meeting:

“Avoid…Scrum of Scrums being a status meeting to management… This is where the ScrumMasters meet each other and report their team’s progress to a program manager or a similar role. A Scrum of Scrums—like the Daily Scrum—is a synchronization meeting and not a management status-reporting meeting… Another smell: Scrum of Scrums is a meeting of ScrumMasters at which the ScrumMasters take responsibility for the cross-team coordination. In every case in which we saw this, the ScrumMaster mutated into a project manager within two iterations…”

It’s worth noting that they do go on to suggest that the Scrum Masters meet regularly in a Community of Practice to learn and overcome obstacles – but not to coordinate or synchronize the teams like traditional project managers.

Professional Scrum Trainer and Agile Coach Jesse Houwing confirms the experiences of Larman and Vodde in an email to me:

“Using the Scrum of Scrums as an ‘aggregated status meeting’, whether you’re reporting status to management or just each other, is an ineffective practice. It shouldn’t be about reporting progress against a plan – those are wasteful legacy habits. The important topics for the Scrum of Scrums should be what the Development Teams are doing that might impact others, what they didn’t deliver on time or what they did deliver, but not as agreed previously. It should be about what they’re planning to do and what they need from the other teams. Let’s also not forget that the Scrum of Scrums is also about inspecting and adapting towards reaching the Sprint Goal – just like the Daily Scrum is for each individual Development Team.”

In contrast, there is a scaling approach out there that suggests almost exactly the opposite of what these titans of Scrum suggest. According to their advice, they suggest that Scrum Masters be the attendees at the Scrum of Scrums. I wonder how many Sprints it will be before those Scrum Masters pull a “werewolf” and mutate into old school Project Managers? As a reminder, there is no Project Manager role in Scrum. Further, in my experience, Project Managers typically find it very hard to coordinate technical and other dependencies because they lack the depth of context required to do that effectively. Usually, in my experiences, they just become bottlenecks to progress.

When I coach Scrum teams, I put a strong emphasis on honoring the foundational principles of Scrum when scaling. I encourage Scrum Masters, if they attend the Scrum of Scrums at all, to stand “outside the circle” of Development Team members, and to avoid eye contact with Development Team members as they are collaborating. Because I believe in principle based scaling, it’s probably no surprise to you that I coach the same technique for Scrum Masters at the individual Development Teams’ Daily Scrums too. I want the Development Team members to be empowered to truly self-organize in their coordination and collaboration efforts. Yes, of course I coach the Scrum Masters to be servant-leaders and facilitate as wanted or needed — but I also encourage them to fade to the background as soon as the Development Team can have an effective Scrum of Scrums on their own.

In Conclusion

A Scrum of Scrums is probably not the only “scaled” Scrum event or technique that you will need on a multi-team, one-product effort. Each of the other optional/complementary “scaled” techniques is worthy of a blog post of its own. On the other hand, maybe not every scaled Scrum implementation needs a Scrum of Scrums event. Your mileage will vary and you will have to inspect and adapt as always.

Ignore the haters and the people who like to treat the Scrum of Scrums as a punching bag. Don’t be afraid to try for an effective Scrum of Scrums. My advice is to assess your own context, to look for practices that you think might work to scale up, but to do so by putting principles first and your best foot forward.

I wish you well and… Scrum On!

Read More

Measuring Success, Measuring Value

The aim to deliver valuable software is a great, core principle of the agile movement. The difficulty however is that ‘value’ in itself is hardly quantifiable. Yet, I do believe it is imperative to think in terms of value in software development and therefore overcome some fluffiness attached to ‘value’. If we don’t find actionable ways to deal with ‘value’ it might remain meaningless; another buzz word, another way of getting people to think it’s time to move on to the next hype. It is not only difficult to quantify value, it is not even necessary, maybe even undesirable. It is better to measure whether we are delivering value (effectively).

What we thought defined success

For many years we were tricked into believing that software development can be considered a success if we meet 3 criteria: deliver (1) all promised requirements (2) within the planned time (3) for the allocated budget. It is reflected in the famous iron triangle of software development.

That in turn tricked us into believing that, in order to be successful, we had to exhaustively analyze, detail and describe all requirements upfront, and get formal approval and sign off over them before the actual programming can be done. The underlying motivation is to secure the first element of what we were told defines success, the ‘requirements’.

This beforehand gathered information then becomes the input to careful and exhaustive calculations for the delivery part, often with the addition of some ‘contingency’. The underlying motivation is to set and fix the other two elements that we were told make out success, time and budget.

The result is poured into a plan, often complemented by risk mitigation strategies and other exception procedures. When this plan and all its components and clauses are approved and signed off, implementation can -finally- start. And then, obviously, it is just a matter of following the plan to be successful. Deviations from the plan, seemingly happening sometimes, are unlikely to cause any real problems, because it’s what ‘change request’ instances are for (meetings, documents, approvals, and sign offs).

Unfortunately, this was (and at many places still is) believed to be the only way we can ensure the ‘success’ of software development.

Yet, things aren’t that easy. The installments of the mentioned extra safety nets are already an indication that, despite our firmness, this approach isn’t really giving us the certainty it claims to have. And despite the safety nets, the detailed preparations and the seemingly perfect plans, many projects are plainly cancelled (29% according to the Chaos Report by the Standish Group of 2011) or in the end still fail in meeting the widely accepted success criteria of scope+time+budget (57%).

Some however are actually successful in delivering according to the three predictions (14%). But then, success doesn’t take into account that often quality was lowered to unacceptable levels in order to live up to the success criteria; reason why it’s good to add that as a fourth variable to the iron triangle (see figure). Success doesn’t take into account that the elapsed time might be according to plan, but may business-wise be extremely slow. Note that it is not unusual for projects to deliver software no sooner than 12-24 months after the start! Success doesn’t take into account that by the time the software actually becomes available for use, nobody really sees much ‘value’ in the features anymore; at all rendering them useless or in the functional way the features are implemented. More innovative ideas for them have emerged, or improved technological ways to implement them are discovered. It connects to the finding that 64% of features, produced in this way, are rarely or never used.

The three factors they told us defined ‘success’, fail in doing exactly that. And even if they are met, they still only reflect how successful the ‘delivery’ of the software to the market is, not how the software is being received or appreciated on the market place, let alone that the approach helps us addressing changes or new requests from the market place. The three factors fail in showing how valuable the software is; it only says that a version of software got out the door at certain predicted conditions.

What we say determines success

Agile overcomes the fallacy of traditional, upfront predictions and descriptions with collaboration, communication, incremental progress and continuous improvement. All risks taken are limited in time through time-boxed iterations. Time-boxing allows adaptation and adjustment within the process.

The agile movement stresses the importance of active business involvement as part of cross-functional development work. The agile movement stresses the need for frequent releases to the market place to learn what actually is appreciated. There is no better risk mitigation than regular feedback from actual users.

Scrum, as leading framework for agile software development, is designed upon the foundation that software development is too complex for a predictive approach. Scrum implements empiricism in software development, thriving on frequent inspections to decide on the best possible adaptations. Inspections however are pointless if the inspected information is not fully known, opaque instead of transparent, and if the inspection is not done against known and agreed standards and definitions.

The target of the adaptations is not only the software being produced, it is also about the tools, the engineering practices, the relationships, the process and the three elements they told us define success, i.e. budget, scope and time. Scrum does not care about the abused notion of ‘project’. The concept of ‘project’ generally only serves the idea that success is possible if software is delivered on time, within budget and has all the predicted features. Scrum focuses on the software product (having a role and an artefact for its owner and its backlog) and incremental sustenance of the product. The foundational belief to this is that the success of software development is defined by the capability to satisfy and impress the consumers of the features, at a reasonable price, at a cost that has an effective return, with creation happening in a way that is sustainable for all people in the ecosystem of the product.

Yes, we can…measure

The success of an organization, in terms of survival, prosperity and leadership, increasingly depends on their ‘agility’, i.e. their overall capability to deliver value in a context of constant change, evolution, innovation, improvement and re-invention.

The difficulty in establishing the value of software or software requirements is that it depends on context, time, technology, market, business domain. It also cannot be reduced to one parameter only. Predicting value doesn’t make much sense either, since it can only be validated by the market place.

But if value defines success, how can we then measure whether we are successful?

Scrum.org has developed the Agility Path framework to help organisations increase their agility and move toward a value-driven existence.

Agility Path focuses not on the illusive goal of calculating and predicting value or similar magic. With Agility Path the outcome of an organization’s work is measured with metrics to help them think about the way that outcome is achieved. Organizations get a clear indication on whether they are delivering value or not. If from the metrics it seems they are not, they have many areas and domains to inspect further, and do adaptations by installing, removing or improving practices, tools and processes. It is how the Scrum framework is used to manage the change process, the transformation of an organisation required to increase their agility.

The metrics provide the transparency needed to identify the areas where adaptation has the most impact. Think in terms of business metrics like employee satisfaction and customer satisfaction, revenues, investment in agile, etc. Think in terms of delivery capability metrics like cycle time, release frequency, defects, etc.

All metrics are consolidated into an overall Agility Index for the organization. This Agility Index is an indication of how effective the organization is in delivering value. One Agility Index is bound to time, place and context. The exact figure is of no importance. The evolution is of importance. The underlying set of metrics is of importance. The insights gained from the metrics, as a source of improvement, are of importance.

No magic, just hard work

There is no magical formula to calculate value, and even when trying to calculate value to steer development priorities, it is a prediction, an assumption that remains to be validated (or contradicted) when you actually go to market. You can never be sure.

The best we can do is to capture the results of our actions with metrics, and do those measurements regularly. We detect trends and patterns (and prefer that over a naked, singular figure). We relate that back to how we work, change how we work, and measure the change in outcome of that assumed improvement. We do that endlessly and relentlessly. We continuously improve by learning and adapting. We get the most out of what we do.

This flexibility primarily helps organizations respond better and faster to change, it implements openness to change over ignoring or blocking it. Once the thinking gets ingrained and new ways of working are installed, organisations discover that there may be different options to respond, thereby embracing change as a source of information. And, finally, organisations start innovating, be ahead and cause change (for the others to follow). Thus an agile approach harnesses change for the customer’s competitive advantage, and the organization’s agility.

 

Read More