IBM

Blockchain Design Thinking_4

 Blockchain Design Thinking_4
Male: So modules, the fourth section, which is the longest in the presentation, but we’re
doing okay on time. This actually talks you through – I’m going to talk through
here how each of the four modules are constituting our Blockchain Design
Thinking Workshop. And for each module I’m actually going to say what
elements - what standard Design Thinking methods and elements we use and how
we infuse Blockchain into there to ensure that we’re constantly testing the
hypotheses that Blockchain is the right fit. And then also talking about some hints
and tips to make that particular module a success. So that’s going to be the
standard section – the standard, if you like, framework for me taking through this
module section of the presentation.

Design Thinking Workshop, usually over two days and there are four half-day
modules. The first one is all around ideation to find the right use case for a
customer. I’ll come and talk about if the customer has already chosen his use case.
That just needs to be shifted a little bit, if that’s the case. Then we actually focus –
we break out into persona-oriented groups and we focus on the user. We look at
how the user does their job right now and we look at opportunities for
improvement in doing their job. Which then allow us to focus in on the
articulation of hills, which are a clear statement to development intent, a clear
view of where we’re going. Which are then prioritized and/or merged to go into
the going agile phase. And the best way of looking at this is, this is effectively a
segue, it’s like a logical bridge into the first agile development situation. So it’s
the bridge from Design Thinking, into the project.

This is drilling down to the next level and I’ll show you a little bit more of this as
we go through. We’ve put timings on here, which are all approximate. My goal,
my stretch goal as I’ve facilitated Design Thinking Workshops, is I try and get the
needs statement, or even, indeed, a first drafting of the hills done by the end of the
first day. That has a great advantage that all the delegates can sleep on that
overnight, come and refine it in the morning, come and look at it with a fresh pair
of eyes. And so I found in that instance we usually get a higher quality output as
we go through the second day. However, it’s more important to take all the
customer delegates with you, not to lose anyone, than just to rush through this at a
rare old pace. So the approximate time scales in there, but really provided for
guidance only.

So the first section, the use case. This is effectively an ideation session and we’re
assuming here that the customer knows how to spot a good Blockchain use case
because they’ve done Blockchain Engaged and Blockchain Explored, they’ve
done the Hands-on sessions. So we do this by going through a classic
brainstorming process, classic ideation, thinking about as many use cases as
possible, writing them up on a whiteboard, then if necessary, doing some voting
on them to select which ones the customer team want to focus on, using these
sticky thingys and voting. We then put the use cases onto a grid, which looks at
business impact and how hard or how easy it is to do the use case, and we use

1
 Blockchain Design Thinking_4
this, actually, effectively to look – and again, to try and focus down on the use
cases that the customer might want to take forward.

Now once we’ve chosen the use case, we actually go into quite a lot of detail to
expand that use case and we do that – we do all of this in a plenary session, still,
to make sure that everyone in the room really understands and buys into the
expansion. Because they’re all allowed to ask questions, to clarify and the goal,
really, is to get down to the next level of detail on the use case, but at the same
time, take everyone along with us.

At this stage we then do another Blockchain fit. We actually look at whether

Blockchain is a good way of rendering this use case. Hopefully because the
customer has had the right information all the way through, it should be, but we
double-check at this stage.

And then we also map out the business network. We actually look at who’s core
and who’s peripheral to the business network, because that will actually allow us
to choose the right personas to move through the rest of the Design Thinking
Workshop with.

So those are the five steps. If the customer has already got their business, if
they’ve already got their use case chosen, we basically skip the first two steps.
Very important to go through these steps, because, again, it might be you might
not have all the participants been involved in the use case choice. We need to get
them all onboard with the use case and get them to the same level of
understanding. So skip those two, but do not skip the second or the numbers 3, 4
and 5.

What are the Blockchain specials we’ve built into here? Effectively, it’s two main
bits. First is Blockchain fit. We do this by making sure that there’s a business
network involved and making sure that trust is important across that business
network by looking at these four words of consensus, provenance, immutability,
and finality. Again, if you do not understand those, please do go back to the
earlier Blockchain education modules, because they make them very clear. These
are used as a fit use case test. We must have a business network and one of these
– one or more of these four words needs to be really important to the customer for
it to be a good Blockchain use case.

We also do a lot of work on the network analysis. Obviously, because a business

network is central to a Blockchain use case, we need to understand who are the
core and peripheral players in the business network. Who’s involved in actually
validating a transaction is real? Who’s just looking at the end results of a
transaction and looking into the end results of the consensus process? Where are
the islands of sensitivity, pieces of – effectively, subsets of the business network
who might want to just share sensitive information within that subset? Those are
all the things that come out of this step.

2
 Blockchain Design Thinking_4

Hints and tips. I mentioned the show of hands. These are really useful to calibrate
early on in the workshop who knows what. So show of hands, who’s done
Blockchain Explained, who’s done the Hands-on workshop? It’s useful to see
how many people are familiar with Design Thinking and agile, because this gives
us a clue about how quickly or slowly we should go through the Design Thinking
explanations. And also it’s useful to see who’s from technical or who’s from
business, just again, through a show of hands.

Agenda management, I’ve mentioned this already. Really trying to move through
the agenda, but not too fast that you do not lose anyone. A good understanding
and agreement is more important than pace at this stage.

The car leasing demo. Car leasing demo, we’ve showed this a few times through
the week. This is a golden thread through the Design Thinking Workshop. All of
the Design Thinking work products, we’ve got samples work products that have
built around just showing the car leasing demo. So if people are having difficulty
understanding what we’re talking about, we can flip back to that and show them.

The key point at the end is we need to photograph each artifact as we go through.
Because effectively, the Design Thinking report will be the sub of all those
artifacts. But also it’s useful to nominate a backup photographer, because iPhones
or Smartphones can be really good, but they can also fail on occasions and I’ve
had mine run out of memory while we’ve been doing Design Thinking Workshop.
So it’s useful to nominate a backup photographer.

When we form the teams to examine each of the different personas, guidance here
between 4 and 6 people per team is ideal. Maybe you could go up to 8. Making
sure that the participants dictate the persona numbers. That means that,
effectively, if you’ve got 15 participants in a Design Thinking Workshop, you can
probably only analyze 3 personas, because that’s 3 teams of 5. So you’d really
need to sort of like think about how many people you’ve got there. That will
determine the number of personas that you can cover. If more personas are
needed, extend the workshop, or actually do later iterations round.

We need to make sure that the teams, when we do the breakout teams around
personas, are balanced. We need to obviously balance IBM with the customer, we
need to balance business with technical and we also need to make sure that each
team’s got Design Thinking expertise to try and manage and guide things through.
If we’ve got multiple organizations – if we’re doing the Design Thinking
Workshop for a business network, we also need to make sure that we balance
those business – balance the different participants around the teams as well.

Working method as per standard Design Thinking - minimum talk, maximum

write, maximum read, maximum think. It’s very easy for these groups to go into a
corner and have a really good chat. If they do that, the chances are they’ll maybe

3
 Blockchain Design Thinking_4
have a nice time, but we won’t get to what we need to in the Design Thinking
Workshop. And it’s really important, I’ve found, to establish this etiquette early
on. If people get into the role of actually writing on the stickys and putting them
on the whiteboard, putting them on the chart early on, the workshop will flow
much more smoothly.

The second step is all thinking about the user. We start this by first of all giving a
short overview of IBM Design Thinking, then identifying the personas in a little
bit more detail, doing classic empathy mapping for each of the personas in the
breakout group, of course, and this is done in breakout. Looking at the as-is
scenario in breakout and also looking at the focus outcomes, which specific(?) as-
is scenario could really be improved as we move forward?

So this is the – this is, if you like, the road through this user section of the agenda.
Blockchain specials in here. My favorite slide. There are no Blockchain specials,
this is just standard Design Thinking stuff.

Hints and tips. When we do the as-is scenario, I would suggest a maximum of five
time-ordered steps. I would actually – we can speed things up by reusing the
stickys from the empathy map into the as-is scenario. People tend to like this
because it means they do not have to write again, they can just move things over.
The other side of that is make sure that you take a photograph of the empathy map
before people start to pull it apart, because otherwise you can’t really go back and
reconstruct it.

I like to use the holiday planning example of constructing an as-is scenario.

People just tend to get that. I find it really good. And also, it’s useful to point out
how people should be looking for improvements steps as per these four points I’m
listing here.

To highlight pains, I sometimes find that dots are good, I sometimes find that
marker pens are good. Probably more dots than marker pens, I must admit. We
extensively use playbacks. After each of the Design Thinking artifacts is created,
we play it back to the rest of the group. This improves the quality and it actually
shares obviously the thinking of one group to another, hence, improving the
involvement of everything - everyone in the workshop.

I had one Design Thinking Workshop where like halfway through the user
analysis, I had one group wanting to jump to a solution. Ah, we’ve got a great
solution. We’ve been thinking about this for ages, it’s bound to work. It’ll be fine.
We need to really avoid that, avoid it at all costs, because we need to thoroughly
understand the problem before we actually look at how the technology and the
solution would be applied.

And also, avoiding too many areas for improvement when we’re looking at how
to improve the as-is scenario. Encourage people to look for one, two or three.

4
 Blockchain Design Thinking_4
Prioritize, if necessary. If they come up with six, look at the top three. People can
usually go through and then think of lots and prioritize them.

The next section, hills. Now we tend to creep up on hills a bit by getting people to
think about needs statements first. We use these to inspire our hills. We do
comprehensive playback of the hills, including – usually we video customers
explaining the hills, and then we prioritize the hills to move forward into the rest
of the project.

So Blockchain specials here. We bring the test in again. We actually make sure
that as we go through the hill formulation process, we’re still thinking about
something that’s going to derive benefit from using Blockchain. We start thinking
about what are the assets, what are the transactions or the participants as we move
through the more thorough understanding of Blockchain. But also start looking at
what’s stored where, what’s going to go into the smart contract, what could be in
the ledger state of world store – oh, sorry – ledger store of world state? What’s
actually going to be on the Blockchain? So all of these things we start to consider
as we go through the hill formulation.

Hints and tips. I’ve actually found at this stage it can be quite useful to quickly
rerun the vehicle leasing demo. Maybe sort of help people to formulate and
inspire their hills. Maybe in the break, do it quickly, show them the real demo. It’s
pretty quick and it can actually really focus people in on what’s a good solution,
what would be a good example.

Refinement, really clearing people’s minds, whether it’s sleeping on things

overnight or whether it’s actually hiding the hills to write them out again. This
can be – or can be useful in techniques to improve. And also, the Blockchain tests.
I often find a sticky, a Post-It-Note with just the four attributes written out can
actually be useful to help people focus in on what would be really good hills that
could be rendered with Blockchain.

Also, I think it’s useful – it’s useful all the way through the Design Thinking
Workshop, but no more useful than in this final section - to ensure that the
playbacks really do challenge and the groups are encouraged to improve what
they’re doing, based on feedback from the playbacks. This basically ensures the
quality of work product increases as we go through the two days.

If we’ve got access to the products’ owner, occasionally I’ve actually had the
luxury of having the product owner take part in the workshop. Also, on other
occasions, I’ve actually had the product owner who we couldn’t get to in the
workshops, so we need to arrange to do a playback to him afterwards or get
someone who could represent his point of view in the workshop. So if they’re
there, let’s make sure that we take that into account and also we need to challenge
thoroughly the Blockchain fit and be calling out if we’ve got something that
maybe can be rendered by more mature technologies.

5
 Blockchain Design Thinking_4

The final section, as I mentioned, Going Agile, is all around forming a bridge
between the Design Thinking process and the Agile Development process. We do
that to start with by rendering the to-be scenario, looking at what would be the - if
we were able to render or execute the prioritized hill, what would it look like? We
then explain to our customer what the First Project will look like. We show them
what’s going to go on in these planning sprints, Sprint Zero. We spend a little bit
of time looking at non-functional requirements, and then also time doing the
action planning. As I say, that’s the - the content could vary a little bit from
project to project, but these are effectively the phases we go through.

Blockchain specials, this is very much similar to the previous stage. We’re
reapplying the tests where we’re drafting the to-be scenario. We’re checking,
understanding the business network. We’re checking what’s where in terms of our
information storage approach to the project. Again, getting – as we get closer to
the development, that becomes a bit more key.

Hints and tips. If the development team are there, if the scrum master is taking
part in the workshop, it’s great to get him or her to lead this final part of the
project. Because again, it’s part of handing over the lead into the project team.
Continued access to the customer product owner, albeit at a lower level, is
important in this section and also as we move through the project. As-is, it’s really
important too, to get complete clarity on who’s going to be available when to
support the project once it’s up and going. So these careful explanation of things
like what tools we’ll use; whether we’re going to be collocation or
videoconferencing; how we’re actually going to use collaboration tools to support
the project as it runs through. And so all of these things do need to be considered.

And this will also make sure, again, during this stage we can make sure that the
user interface person gets a real fast start into the project from their point of view,
by really understanding what from a user interface is going to be compelling to
the customer.

END