A Digital Service Canvas for Government and Enterprise

First published on Scrum.org, 2 November 2018 (syndicated).

“The important thing is to remember what most impressed you and to put it on canvas as fast as possible.” - Pierre Bonnard

Lessons from a start-up

Have you ever tried to kickstart a “Scrum of Scrums” in an organization? It’s an agile activity which looks like it ought to be a no-brainer for teams…something they’d want to buy into, and of clear value to all. Yet after two or three sessions it will very often fizzle out. Only hard-core agilists, those who care about the darned principle of this sort of thing, are left to wave their flag in the breeze. Everyone else seems to have more important matters to attend to than another piece of agile “fluff”.

Sometimes you can coerce presenteeism out of these fine and upstanding corporate citizens by falsely implying that their boss is likely to be there, silently taking roll-call. Of course, that would be a low-down dirty trick to play on them. It would be the gambit and recourse of a scoundrel. I’ve found you can pull it off a couple of times before the mugs get wise and attendance fizzles out.

I suppose a Scrum of Scrums is a bit like a start-up: there has to be a real value proposition. There must be an offering people actually want, and you get a very short runway on which you can pivot. I learned early on that the value of something has to be made clear very quickly if you are to achieve buy-in. As far as a Scrum of Scrums goes for example, an appealing value proposition could be the management of immediate pain-points such as dependencies, or the sharing of knowledge which attendees need now. The essential principle is that if an audience gains tangible benefits quickly and reasonably consistently, then an offering might stand a chance of gaining traction.

OK, so what’s this “canvas” stuff then?

A canvas is an exceptionally light-weight documentary artefact, terse, and pithy. It can be thought of as a tabulation of the critical attributes which underpin a value proposition. Two variations are most commonly encountered. The original is Alex Osterwalder’s Business Model Canvas, proposed in 2008.

Osterwalder enumerated 9 building blocks which, together, describe what the proposition actually is and how an organization intends to make money on it:

1. The underlying value proposition describing the market offering.

2. Client segmentation in the market addressed.

3. The channels through which clients may be accessed in order to realize the proposition.

4. Client relationships which may be leveraged.

5. The essential resources needed to make the offering available.

6. The activities that must be performed to make the offering available.

7. The key partners involved and their motivation for participating.

8. The revenue streams which will be generated.

9. The costs that will be incurred.

Ash Maurya encountered this approach a couple of years later. He recognized that something like a business model canvas would offer great potential in an entrepreneurial, Lean Startup context. “The thought of capturing business model hypotheses on a single page seemed killer”, he would later recount. In fact, he was sufficiently interested “to do some tinkering”, as he put it, so the information on a canvas might become more actionable.

Maurya’s tinkering resulted in four of the blocks being revised. Partners, activities, resources and relationships are, he decided, of less immediate consequence to a start-up. Instead, it’s more important to consider:

• The problem addressed. Most start-ups don’t fail to provide their offering; rather they fail because they’ve solved the wrong issue.

• The proposed solution. What does the Minimum Viable Product look like?

• The metrics relied on to inspect and adapt progress. How will a start-up measure value and growth? Initially it might only be able to focus on one metric at a time.

• The unfair advantage which the proposition offers. What is it about the offering which cannot be easily copied or bought?

The last of these is especially interesting. It tells us something about how innovators think, and the disarming candor with which they can set about their aims…at least in comparison to certain other business minds.

Maurya envisioned iterating through multiple versions of a canvas as quickly as possible until a sustainable business model is found. Of course, using a canvas like this for a Scrum of Scrums would be rather artificial, since the event doesn’t really constitute a market offering. Nevertheless, it can be an interesting exercise (hint: time is money and there are various types of waste an organization could reasonably hope to avoid).

The canvas as an agile artefact

A canvas may be printed onto a large sheet of paper – A2 works well - or sketched out on instant whiteboard and used as a living document. It’s the sort of thing which ought to pass muster as an information radiator. A canvas should be well positioned to constitute an agile artefact, since it has the DNA to be used and valued in the field. It is obviously not intended to be file-and-forget documentation that ends up being shelved.

Unfortunately, however, the shelving of a canvas is the very outcome I have most often experienced. Remember the pertinent lesson from trying to organize a Scrum of Scrums? A very similar issue arises here. There’s an initial spurt of enthusiasm from stakeholders who recognize the potential for USP validation and eliciting a Minimal Viable Product, but interest soon fades away. It doesn’t seem to matter which of the two canvases you try. Whether you pitch a Business Model Canvas or a Lean Canvas, the outcome is usually the same in a large enterprise. A canvas wins in theory, but not in practice. In effect, it’s yet another sprinkling of agile pixie-dust that fails to overcome organizational gravity. Why, though? What’s the underlying problem?

Why doesn’t a canvas gain traction in large organizations?

The critical impediment, I have found, is that an assumed requirement for heavyweight documentation cannot just be rationalized away. It isn’t enough to coach an alternative which is less wasteful and better oriented to lean and agile practice. In fact, a canvas is more likely to be produced as well as the usual raft of documentation than it is to replace any of it. That’s where the seed is sown for a canvas to fall by the wayside.

We have to consider the basic use-case of a canvas. The stakeholders in a large, traditional enterprise are unlikely to recognize the iterative and emergent search for a sustainable business model. They’re more likely to think they have their value proposition nailed once it has funding and a mandate. They’ll assume that existing corporate processes will continue to hold for development and delivery, even when the warnings and indicators for business sustainability and market value are flashing red all over the board. The expectations these stakeholders have, for the information they ought to see and act upon, are not necessarily rooted in empiricism. They can be quite different to those of a lean start-up or studio.

In fact, most organizations only pay lip service to agility and they are not very innovative to begin with. Ironically, as with many other agile events and artefacts, a canvas is therefore more likely to add to the process burden than it is to relieve it. These are not garage start-ups we are talking about, and employees will continue doing what they have always done. They might draft a canvas to humor you as a coach, but they’ll still do the project and stage reports, logs, and sign-off sheets which their management culture demands. Rather than evidence value early and often, they will continue to stage-gate decisions, and to lob the hot potato of accumulated risk onwards in a crashing arc described by that same organizational gravity. Without robust sponsorship from senior executives, and a clear sense of urgency for change, any ambition becomes moulded to the organization’s current shape.

Remember that when a stage-gated enterprise initiative eventually fails, the paper trail must be good enough to shift blame onto some other party. That’s the imperative. The correct following of a process is traditionally evidenced, not empirically by value, but by the paperwork that is accrued. Whether the associated documentation spends most of its time as shelf-ware is completely immaterial. Project documentation is held to be valuable, not because it adds essential value to an emergent product, but because it covers the sensitive region of a manager’s anatomy when it would otherwise be at risk of exposure.

In comparison to this, a “canvas” looks like something from the far side of a distant planet. If you work in an organization where the incremental and empirical mitigation of risk is the exception rather than the norm, a canvas will cover nothing.

Digital Services as a potential game-changer

This is a bleak picture being painted, and it would suggest that we are powerless to improve. A simple agile canvas, which captures just enough information to develop an increment and the documentation truly needed for it to be used, does not seem to cut the mustard as a “serious” enterprise artefact. Its adoption would demand robust sponsorship for deep and pervasive change from senior management. Only they can overcome the organization’s gravity and hit the reset switch on company culture so agile practice takes off. Until that day of revolution – or final reckoning - arrives, work will continue to be stage-gated and risk will be thrown from one party to another. The accomplishment of a defensive paper-trail, as opposed to the empirical delivery of value, will continue to be paramount. All of these things remaining equal, there might seem to be little hope of the situation getting any better.

If there is to be a game-changer, it will have to come from the market, or from government, or both. One recent development - which may be sufficient to overcome corporate inertia - is the compunction to provide digital services at scale. There is even a transformational language of sorts that goes with it.

For example, the UK Government’s Digital Service Standard has promoted digital services as an enabler for “Government as a Platform”. The remit of GDS can be described as being aspirationally transformative. “Government Digital Service was established to drive service delivery to digital across government and provide support, advice and technical expertise for Departments as they develop new digital delivery models”, announced Francis Maude, the Minister for Cabinet Office, in 2012. “[W]e will transform many existing Government transactions in this way”. Other countries have adopted similar schemes, including the Australian Government’s Digital Transformation Agency, the New Zealand Government’s Digital Government Partnership, and the Canadian Digital Service. In the US, responsibility for a digital strategy and its implementation is effectively split between the United States Digital Service and 18F.

All of these schemes reference some kind of digital service “standard” against which organizational initiatives may be appraised, whether they be public or private. Some type of evaluation by an official digital agency may explicitly reference it, such as the UK’s GDS assessments for example. There are some very obvious similarities in the principles enumerated by these standards, clearly indicating a shared heritage, and essential terms of reference (ToR) for digital transformation may be discernible.

This is a major revision. The focus is squarely on the terms of reference we have identified which ought to be of significance to digital service providers, and for which an assessment might well have to be navigated by managers before a service increment can be released.

In principle, the basic use-case remains unchanged. There is a value proposition which ought to be assured, and the terms of reference for doing so – user involvement, lean-agile practices, performance analytics and so on – seem like raw meat for an agile team. In a large enterprise or government body, however, that team is no more likely to be in genuine pursuit of a sustainable business model than a Scrum of Scrums would be. Funding and procurement will not necessarily be conducted in an agile manner. Indeed, a cynic might observe that there may be no more skin in the agile game than a need to satisfy the digital standard itself. The imperative perceived by managers could just be to navigate any related stage-gates, such as the GDS Alpha, Private Beta, and Public Beta assessments.

In practice the use-case for the canvas may narrow to that of having a crib-sheet for negotiating one or more digital service stage-gates. That would clearly be against the spirit of a digital standard, given that the terms of reference emphasise agility and the ongoing elicitation of user needs and actionable metrics. Nevertheless, even though a traditional management culture may try to game or misuse the terms of reference underpinning a digital service standard, it is agile practitioners who now occupy the moral high-ground. That in itself is a potential game-changer which can assist in the promotion of agile hygiene. The inspection and adaptation of a digital service canvas may form part of a Sprint Review, for example. In an enterprise landscape where there is great organizational gravity to overcome, anything which helps to socialize agile practice represents a win.