Executing execution — a design toolkit for modern (agile scrum) delivery
The value of design can reach new heights when designers embrace its constantly morphing role in modern delivery
This article was originally presented as a lightning talk at Fjord’s Service Design Breakfast Event, as part of the 2017 DesignCanberra Festival.
Like any designer working in an environment that delivers a solution or service that people use, I often find myself handling common designer situations: joining projects and meeting great people who genuinely want to understand the design we do and discussing the value that design brings, design’s place in the process, the reasons behind design decisions, the stage of a design, why it was prioritised, how much time is needed, and so forth.
None of this is unexpected. With design increasingly becoming integrated into our lives, its value has increased exponentially, as has the impact of having everyone on the team understand it.
And just like any good professional, we designers walk everyone through it all. Constantly.
And as projects and teams scale up, the time available for these activities decreases, but the effort and value of doing so increases more and more… particularly when we consider how important design has become.
Thankfully, we’re designers, and it’s in our blood to always do better.
Let’s Talk About The New Normal
Graeme Wood’s great quote sums up the space that we’re all operating in:
Change has never happened this fast before, and it will never be this slow again.
The world is changing, and changing quickly.
People’s expectations are part of the change. Everyone wants services to be accessible at any time, on as many platforms or channels as possible, and believes everything should be easy to use and, of course, responsive and reliable.
These expectations cut across industries and providers too: from government public service agencies to local shops, people expect a certain standard to be met, and the goal posts keep moving.
To better address the speed of change, our working environments have been adopting a more appropriate methodology as well, one that embraces unpredictability by default. I’m fairly confident you know what it is: the (still increasingly) popular agile scrum.
Why is this important?
Because the adoption of agile scrum is largely a reaction to a mega trend that transcends industries, designers will increasingly find themselves working in some version of it. It is also likely that future approaches would be evolutions of agile scrum, and probably never return to a waterfall-style process.
The shift to this approach isn’t without its pains though. After all, agile scrum wasn’t originally developed with design factored in by default, so designers don’t have the luxury of time similar to a design phase in the old waterfall methodology to handle the same situations they still find themselves in.
And while I think the changes that come with agile scrum are actually awesome, the necessity of addressing these responsibilities isn’t going to disappear just because the methodology being used is tough on time.
Hence, as designers, we need to work smarter, not harder.
The Toolkit: Design Methods for (Agile Scrum) Delivery
With agile scrum as the new normal, it’s only natural for designers who are just beginning to experience it to have questions and thoughts along the lines of where to start, what’s next, how a decision bcan e explained succinctly, how a body of work can fit into a sprint, etc.
Therefore, I thought it would be good to share four concepts that have proven to be incredibly powerful when used by designers (in my experience at least) in agile scrum delivery, as well as one meta concept.
Concept 1: Product Backlog Items
If you’re kind of new to the whole agile scrum world, this is where you should start, as Product Backlog Items (PBIs) are considered standard baseline knowledge in agile scrum, and serve as a common denominator across the concepts covered in this article.
The quick summary:
- PBIs are units of work that are used to detail what needs to be done.
- The main purpose of PBIs is to establish alignment and a shared understanding of what needs to be done by everyone who’s involved.
- PBIs often take the form of Stories. The most common one being the User Story, which is stated in a “who, what, why” formula: As a <who>, I want to <what>, so that I can <why>.
- PBIs can be broken down or grouped together, creating additional context and detail. This is best explained by the two images below.
- Often, Stories and Epics are user-centric, Themes are business-focused, and Tasks are solutions. This ability creates context and allows for scale. The images below are examples of how they all work on a detailed and high level.
If you take a moment and look at the above images, the benefit of using PBIs to atomise the work needed is pretty obvious. They easily form a purpose pyramid, and the effect of having it present can sometimes have an impact that goes further initially expected.
However, it’s also important to keep in mind that the Scrum community does not officially endorse the categorisation of stories into epics, nor any additional levels. There are many reasons for this, but without some form of categorisation, the next concept may not be possible to implement.
Right. Now that User Stories (sorry, PBIs) are no longer some weird concept and you kind of have an idea of how an agile scrum team would use them, let’s just go ahead a little and learn how they can be part of other concepts.
Concept 2: Story Mapping
With the knowledge that User Stories can be grouped and broken down for additional context, arranging these relationships in a meaningful way helps communicate the high-level “plot” of a project’s vision, and can lead to a few other things as well.
This is where (User) Story Mapping comes in.
The quick summary:
- Story Mapping is the concept of arranging Themes and Epics (remember those?) to create a narrative flow — think: from point A to point B, what would a user’s journey be if they needed to send money through an app?
- Often, Story Maps are translated from Journey Maps, where the latter helps the former when prioritising Stories.
- Once a narrative flow is present, the (User) Stories associated with an Epic are listed and prioritised, with the most important (or critical) ones usually at the top.
- Story Maps are also used to “slice” across the User Story columns, creating rows. Each row or slice reflects the stories that need to be completed for a release. This is a great way to create sprint backlogs.
The concept of the Story Map is simple, yet incredibly powerful. As a tool, it can be used for a number of activities: education, prioritisation, alignment, and, of course, communication.
Right then. Now that we’ve covered Story Mapping and Product Backlog Items, it’s probably a good time to look at a few more concepts that dig into a little bit more of the details.
Concept 3: Assumption Slides
An Assumption Slide is another simple concept, one that is mainly used to communicate the status of a Story (or any PBI). It’s also incredibly simple to create (it’s just a line with a movable marker), but what it communicates is anything but.
The quick summary:
- Assumption Slides are read left to right: if a PBI is largely made up of assumptions, you place the marker somewhere on the left. As the number of assumptions decrease, the marker moves to the right.
- Assumption slides illustrate if the work needs to be done quickly, or refined, based on the status of its assumptions.
- As an example: if the problem is still an assumption, the marker is placed to the left, and the work done is considered quick, because the purpose is to validate quickly.
- Now if the problem is no longer an assumption, but the solution is, the marker moves towards the middle, because while the work is still about validation, it is not as quick, nor as refined because only a prototype of the solution will be needed.
- Finally, when the problem to be solved has been validated, and the prototype of the solution has proven to work, and there are no major assumptions, the marker moves to the right, as the focus is now on refining what has been proven.
The Assumption Slide is an excellent tool for communicating the type of work that needs to be done. What this also does is allow the entire team to determine the level of assumptions present in a Story. This brings to mind a concept that has become quite important for design’s success in today’s environment: Dual Stream Delivery.
Concept 4: Dual Stream Delivery
Jeff Patton’s quote on the value of testing before build is great way to explain why Dual Stream Delivery matters:
“The most expensive way to test your idea is to build production quality software”
Replace the word software with any form of output, and it still rings true.
The quick summary:
- Often, multi-disciplinary teams will find that there are two types of work: Discovery and Delivery, and they need to work together. In my personal experience, denying or avoiding this can lead to a workflow that could make it difficult for most teams to find a rhythm.
- Discovery means learning more about what we need to do. Delivery means refining what we know we need to do. Remember the Assumption Slide? Yeah. That’s why they work well together.
- The Dual Stream Delivery concept is a modification of traditional agile scrum, and research has showed that it is currently the most effective version of agile when it comes to incorporating different types of design.
There are multiple ways of executing Dual Stream Delivery, but what’s important is that the entire team is across both streams (or tracks), so that everyone can provide input and have a shared understanding of the entire effort, which is critical to agile scrum.
The beauty of the Dual Stream Delivery concept is in its relay-style nature. By having the discovery stream validate assumptions (remember the Assumption Slide concept?), it acts like a filter for the delivery backlog, helping reduce the chances of rectification, which would have to be done by the same developers who are building new features.
It’s also worth mentioning that there are criticisms of the Dual Stream Delivery approach, as some find it akin to a “mini-waterfall” approach. And while there is merit to this line of thought, research does support that the Dual Stream Delivery approach is generally a safe and effective choice when compared to other “design + agile scrum” ideas.
So far, so good? Maybe now would be a good time to review:
Why are these concepts important?
By taking a step back, one can see that the four concepts should cover quite a few corners of the agile scrum environment: Product Backlog Items form the base units of work, Story Mapping visualises the narrative and is a method of prioritising the units of work, Assumption Slides define the type of work that needs to be done, and Dual Stream Delivery is the platform that provides visibility over the work that is being done, and refines what is being deployed to users at end of each sprint.
But we need to take another step back, and look at them from a higher level.
Is there a common theme between these concepts? They’re tools, sure, and they’re all forms of management, too. But what makes them so effective? So valuable — not just for designers, but for everyone?
The Meta Concept: Mental Models
What the above concepts have in common is that they’re accessible to everyone. One of the greatest powers designers wield is the ability to make things clear and tangible. There are many ways of doing so, but Mental Models have the power to provide access and create a shared level of understanding that cuts across walls and levels.
What are Mental Models? They are tangible expressions of information — patterns, methods, processes, frameworks, words, illustrations, images, etc. — that can be displayed physically, digitally, and be of any size.
There’s another great statement from Andy Polaine that explains why Mental Models work well:
“Almost all the design methods we use are really because telepathy doesn’t exist. We try to capture what is in someone else’s mind and also try to explain a thought. The designer’s secret weapon is the ability to make those abstracts thoughts and ideas into tangible artefacts that can be discussed.”
In today’s agile scrum environment, designers often only have enough time to do the actual design work, so the time and effort required spent on any other type of non-design activity (meetings, showcases, walkthroughs, and the like) must be minimised as much as possible.
By creating and managing Mental Models that can be used in a modern delivery environment, designers can become much more effective in everything they need to do: from communicating important details about their work, determining the workload, as well as managing expectations.
The moral of the story is: since we designers still find ourselves in situations that require us to engage with different team members and stakeholders, we need to constantly do so in a way that’s clear, effective, succinct, and consistent. This is where “designing” on a different altitude can help. It’s a way to work smarter, not harder.
And make design speak for itself.
If you enjoyed this, and you’re interested in a few more articles around the topics of Design + Delivery, let me know by giving me a few claps! Thanks!
