- Hi, I'm Chris Baynham Hughes, Customer Innovation Advocate at Red Hat's Open Innovation Labs. And today, I'm here with Tim Beattie, our Global Head of Product. I'm here to get an insight
into one of the residencies that we're running with one
of our automotive clients. Now we get to work with an
amazing array of customers across all economic sectors. And what we see is that the differentiator between the high and low performers is rarely about the
technology and it's more about the organizatio
n's culture and practices. So at Red Hat, we believe that open unlocks the world's potential. So to help our customers change the world, we came up with the Open
Innovation Labs residency. What that does is we
take our customer team and we immerse them in our
open culture and practices and we pair them with
our technology experts. So they get the very best out of Red Hat. Now we'd rather show than tell, so today we're going to use
one of our practices, walk the walls, to get an
insight into this
residency. Tim, could you tell us a
bit about walk the walls? - Yeah, sure, so at Open Innovation Labs, we really believe in the
idea of visualizing our work in a very transparent way. And the idea is that we can
literally walk the walls with a stakeholder or someone
who's interested in this team or this product, and through having a good old fashioned conversation and looking at the artifacts on the wall, that person should be able to get whatever information they're looking for. So it's reall
y, really powerful. - Sure. Okay, well, let's get stuck in. So let's have a look at the wall. So, okay, first thing that
really pops out at me is, not only the work's
visualized and up there so I can go and have a look at it, but it's the colors as well, really pulls in the energy. So what's up first? - It is a practice called
the social contract which is something we
tend to do with teams in day one or day two of the residency. This is a contract that the team members put in place with each oth
er about how they want to work
together, how they want to behave. And this team came up with
some really great ideas when they put together
their social contract. And so things like mob
to learn, pair to build, I love that as a principle. Or share the knowledge,
really really important, or even, it's okay to be wrong. And on all of the team members have signed this social contract so they can keep each
other accountable to it and keep each other honest. And they tend to hang it and display it in
a very public area. So it's very transparent
about their behaviors. And it's a living, breathing artifact, so that means the team can
adapt it as they go along. And as they learn more and more about working with each other and
what's working and what's not, they can improve the social contract and keep that living and breathing. And another practice that we
do in the first day or two is all about aligning and
agreeing on the target outcomes for the residency. So the engagements here are
between
four and 12 weeks. So these are the
measurable target outcomes that we want to achieve during
that four to 12 week period. And the three outcomes that
this team came up with, actually pretty typical of
the residencies that we do. So there's one around
increasing adoption of DevOps across the business. There's one all around
having an application. In this case, support articles up and running in production. And then finally, there's one about having the team feel happy
and excited and empowered
about working this way, and
working with this product. So again, it's something that we radiate, we hang on the wall and it
reminds us why we're here and what we're trying to achieve in this time working together. - Great, okay. So we've got, how are we going to behave and how are we going to work together? We've got, what we're
actually trying to achieve. Ah, brilliant, impact mapping, this is certainly one of
my favorite practices. I just, I love the way
it brings everybody in. And it can gene
rate not
only purpose for the people who are delivering, but
also alignment across so everybody's clear
on what we're building. Tell us a bit more about this bit. - Absolutely. I mean, even the act
of having a wide group of stakeholders together
on agreeing and aligning on the goal of why we're here, and often this will come
down from some strategy, but just to be able to write it up and have everybody have
that shared understanding. In this case, the goal
was all around improving the consumer's
experience, having better informed technicians and improving the support approach. And the stakeholders came up with some really great measures that they could use then to determine whether they were meeting the goal. The second part of impact mapping is then getting everyone
aligned on the actors. You know, who are the people
that can help achieve this goal or may impede the goal
and what do we call them? Because, you know,
sometimes people have got different terminology that they use. So this
is about getting that shared understanding and alignment. And then we determine
what are the impacts, what are the measurable
impacts that we want to achieve on those actors to help achieve the goal? So for example, decrease
the need to create cases or increase case quality. These are all things
that we can measure now and we can measure in
the future as we go along to again, determine whether
we are achieving our goal via those actors. And then finally, we come
up with all of the outputs, all
of the deliverables
that we think could help achieve the outcomes or
the impacts on the actors. - Yeah, fantastic. So, essentially we end up
with these sort of hypotheses as to how we're going to
achieve these goals, right? And so that's really important when we're trying to
solve complex problems because you have to take
an experimental approach and it has to go that way. - Absolutely, so we can read
this from right to left. We take an example. We hypothesize that if we build
a single sign on s
olution, it will have this impact,
reduce the time to create case on these people, the case
agent, to help achieve the goal. And during impact mapping,
we'll then facilitate some dot-voting or investment simulation so that stakeholders can vote, where do they want to place some investment? Where do we want to place some bets? What do we want to run some experiments to prove or disprove those hypotheses as we get into the residency? - Awesome. The other aspect I love about this, is the way that i
t really
just surfaces assumptions that people have made. So, you know, the example you
gave for the single sign on, if we spoke to the case agent, we might find they say, well,
this isn't our problem at all actually, our problem is
really somewhere else. So we can start to sort
of test those ideas out and make sure we're building
the right thing up front before we even hit the keyboard. - Absolutely. It's so collaborative and just having all of this information and everybody looking at the same
thing really creates that alignment
and shared understanding. - Yeah, great, I love that inclusivity. Fantastic, so what's next? - So next is one of my favorite practices, it's event storming. - Okay, brilliant. Well, let's walk that wall. - Cool, let's do it. Okay, so event storming is a practice that brings to life the idea of domain driven design. It was created by a guy
called Alberto Brandolini. And he came up with this
wonderful color coding to visualize business processes in a way that w
e can iteratively and incrementally deliver value. So when we run an event storming session, we bring everyone together. We bring technical people, developers, infrastructure people, designers,
business domain experts, even end users. And when they all collaborate to generate these event storms, and there's three examples here. We always start our event
storms with the term, the one where. So, the one where, someone
logs into the application or the one where, support
articles are managed. And th
e first step of the event storm is to come up with all of
these orange sticky notes. Orange sticky notes are events. These are things that
someone cares about happening and they're all written in the past tense. So something like, app
opened, auth page provided, custom claim received. And even the act of getting
everybody on the same page as to how these business
processes fit together really provides that alignment
and shared understanding which is hugely powerful to do up front. We then start
to evolve the event storm, and we bring in some of these other parts, like the commands, the
aggregates, the policies and the screen layouts, to bring even more
information onto the wall. - Again, it's awesome, I love it. And I love the color. It sort of really gives a lot of energy. It looks like it's a
lot of fun to produce. And I love the inclusivity angle again. So getting that rounded problem, so we're really tackling
what's going to make a difference and really have that impact, building t
he right thing, I guess really. - Absolutely. And what I love about this is the things that fall
out of the event storm. So there's something for everyone. You can see here some
of the UI screen designs and some of the ideas coming up here and, you know, UX designers
can then start to run experiments and research
with the information they're getting from the event storm. The way to event storm is presented, allows us to build these
kinds of little areas, these little bubbles of functionality and
they can be built in microservices, and deployed into containers. So it allows us to build
out the application in an iterative and incremental way because the logical architecture emerges from the event storm itself. So, it's awesome, it's
something for everyone. - Yeah and I love the language, the language is all sort of plain English. So, as you say, someone from
the business can join in and have a real impact
on the architecture, that doesn't happen often, right? - Yeah, and these actually
w
ill become features on our product backlog, so
the business then start to see how this translates into
software development. - Fantastic. Okay, so speaking of the business, sort of looking to see the impact and to understand what's going on in this. Often when we work with customers, they have really a complex
series of handovers that's sort of in a bit of a black box called the IT department, and it's not really clear or exposed what goes into actually
releasing a product or getting it there. S
o how do we expose that, And how do we look to make
improvements from that? - Yeah, that's a great question. I think one of the biggest challenges we often see with our customers, it takes them a really long
time from an initial idea or an initial request from a
user or business stakeholder to actually having software
running in production. And we often get asked how
can we bring that time down? And the practice I love
using to visualize that, is called metrics-based process mapping. - Okay. - W
hich is the next practice
on our walk the walls. And again, I love this because
it allows us to visualize all the things that happen
between the initial request from the user or the customer all the way to that running in production, everything that needs to happen. - Wow, so that whole sort
of asks to gets is there. So these different swim lanes, what does this represent? - Yeah, so when we ran this, we learned that to release software, we were having to use
lots of different people from differ
ent departments
in the organization. So every time we cross one
of these horizontal lines, it's actually a handover or a handoff, or we're having to raise a ticket on another team to do something. And that's actually quite inefficient. It's a lot of wastage, it's
a lot of time being delayed between those steps and those handoffs. So we try to remove those where we can. - Yeah, sure. And anybody can come and
walk up and look at this and see there are
efficiency gains to be had, I guess, right? Bu
t what do these numbers mean on the- - Yeah, so for each of
the things that happen between the initial request
and the delivery to production, we take three key metrics. We take the amount of time
it takes to do the thing. Then the actual lead time, so how long between the
previous step finishing and the next step starting, including all of the wait
time and the delay time and then the completeness
and accuracy percentage. So, you know, how accurate, how complete is that particular task when it
happened? Or how often do we have to revisit it? And like you say, when we
surface this information we start to see opportunities where we can optimize and
improve those metrics. - Well, yeah, I mean, if one in 10 is actually coming through correctly and there's also a week lag between actually completion
and sort of moving on, or the overall time rather, that's an obvious place to start, right? I guess you can start picking out where you want to, where you're
going to have the most impact. - Ab
solutely. And when we total all of these things up, in this case, I think,
you know, we could see it took something like 35
weeks to deliver a release. So we could see why there
was only one or two releases a year happening to production, and there are clear areas that
we could look to optimize. - Sure, wow. Okay, so we know where we want to, what we want to optimize,
we've got our architecture, I guess we now need to sort
of do the sprint planning or the iteration that we're
going to run for de
livery. So, is that next? - Yeah, so basically the impact map, the event storm, the
metrics-based process map, this is giving us lots
of great ideas of stuff that we can now go and
do during our residency. So we use a practice to
organize all of those ideas into small slices of value and the practice is called value slicing. - Right, it sounds awesome, let's go. - Cool. All right, so value slicing is a practice where we can bring all of the ideas, all of the features, all of the learnings that h
ave come out of
the previous practices and allow them to at last,
to organize by value. - Okay, so where have
these pieces come from? How does this all work? How does this come together? - Yeah, so you remember,
there was three outcomes that we set out at the
beginning of the residency? What we've done is we've
put those three outcomes along the spine of our value slice. So the increased adoption of DevOps, the application, which we've broken down into slightly lower level spine. And the happy,
excited,
and empowered team. And what we've done with all of the items that have fallen out of
the previous practices, we've made sure that
it is going to take us to one of those outcomes. So it's categorized
under one of those items. - Awesome, okay. So what are these green lines about? What does this represent? - Yeah, so what we do is, we work with our customer's product owner and maybe their stakeholders
will come in as well. And we'll ask, how can we slice, how can we deliver increments of
value during this residency? We don't want to just focus on
delivering the application because we heard that you want to
increase adoption of DevOps and you want to have a happy,
excited, empowered team. So we hand this board
over to the product owner and they work in producing
horizontal slices of value so that we tackle those
high value items first and we can deliver
increments of the solution that's always delivering
value as we go along. - Okay, great. And I guess that gives
us a point to ce
lebrate each sort of step change
of the value delivery. - That's right, we don't
want to just have one big bang celebration at the end, We want to be able to
celebrate lots of releases as we go into a world
of continuous delivery. - Yeah, keep that happy,
excited, empowered team, right? - Absolutely, yeah. - Okay, so then we're taking it to what looks like a product backlog. - Yeah, that's right, So, we literally copy the items at the top of the value slice board, and we put that to the
top of o
ur product backlog and then the next slice and
the next slice, and so on. This was the product backlog I think, after we'd done about
three sprints of development. So we've got a lot of
stuff that had been done. We've got some stuff in the fourth sprint. And the product backlog is a
living, breathing artifact. So we can always be updating it, we can always be refining it. We can always be putting stuff by updating the previous
artifacts as well. - Okay, great, so what
are these numbers on that r
epresents that? - Ah, so the numbers here, this is a practice that
this team chose to use around relative sizing. So their story points,
allows them to discuss and align and agree on the
relative size of complexities for delivering that piece of work, according to the acceptance criteria of that feature in place. - Okay, great. And how do they come to those numbers? Is that, so one person decides, is that the product owner or? - No, it's a really collaborative exercise and there's lots of little
tools, things like planning poker and estimation ladders,
that our teams use. The real reason we do it is
to get conversation going and get alignment and
shared understanding, so that it becomes a team problem and a team response to
delivering the solution. - Sure, okay, great. So I'm seeing another backlog over here. - You are, yeah. Yeah, so obviously this
is our product backlog that our product owner builds
using the practices before, then every week in a
residency, we run a sprint, an itera
tion, and this
is where the team pool the top items from the product backlog and they create a sprint backlog. And this was actually
the sprint for a backlog in this residency. Where the team had a goal around
completing the user journey for creating an article and
refining the responsiveness, and authenticated users. So, in the sprint planning session, they decomposed a product backlog item down into low level tasks. So this is all of a development task, the coding, the testing, the infrastruct
ure
improvements that they do during the sprint. - Okay, so that's why I'm
seeing the big tickets mapped to here, but the smaller tickets, they're tasks within to
deliver that bigger ticket. - That's right. So we're providing the traceability of what the low level tasks are to deliver the valuable features. We can go further, we
can see where that sits on the relative value slicing board. We can think about where that sits on the event storming board and where it fits into
the business process.
We can even trace all the
way back to the impacts that we want to have on the
actors in the impact map. - I love it. I love the idea that I could walk in, see all of these up on the board, not disturb anybody from the team and I could walk my way through
and see that progression. There's a logical flow to it that allows me to see where we're up to and to really get a feel
for what's going on. So what about the
different colored stickies, are they represent anything or- - Yeah, so, we work with
c
ross functional teams. So the teams are typically made up of all of the skillsets needed to deliver a full increment of the product. So we'll have front-end tasks,
which will be one color, backend development tasks
which will be another. Infrastructure or data
tasks which will be another. Even things like, you know,
documentation and workshops which need to occur to
deliver done software. So the fact that we're
using different colors here shows that we've got the
cross functional aspect in the t
eam to deliver
value in the features that they're building. - Excellent, okay. So, how about sharpening the saw? How about sort of continuous improvement? What do we do around that? - Continuous improvement's
a part of our DNA and we have some great
practices to help us with that. Another of my favorite
practices is the retrospective, and that's the next part
of our walk the walls. - Lead on. - Cool. So the retrospective practice
is something that we do at least once a week
during our residencie
s, as we really want to drive
continuous improvement into the DNA of all of our customers
and all of our teams. So we have lots of different formats of retrospectives that we run. This one's called the three L's. So at the end of sprint
three, the team came up with, what did they like during the sprint and what did they learn during the sprint. And what did they long for,
or lack during the sprint. And this is just a short timeout to reflect on what's worked well and how can this team make
thems
elves even better in the following sprint. So they always come up with
some retrospective actions. They will always pull those
into the subsequent sprint and they will always revisit
at the next retrospective to see the impact of the
retrospective actions that they've put in place. So, such an important practice. This is just one of many,
many, formats that we do in our residencies. - Yeah, I think the retrospective is just one of the most useful, and I'm always astonished at
how frequently it's
overlooked and people just don't do it. And they carry on making the same mistakes or not addressing the
issues that are there. So what's this, what's this big picture? - It's exactly that, it's the big picture. So this is something we
create during every residency. And it's all about the
continuous integration and continuous delivery
infrastructure we put in place using automation at the
beginning of the residency, and we improve it during the residency. So we put it on a big visual
like this
and you know, these fun little drawings, so that team members and stakeholders can have a conversation
and share their learning and understanding about what happens behind the scenes when we commit code. So, you can see here, these
pipelines that are built by our push button infrastructure. You can see the continuous builds, the continuous baking of containers, the continuous deployment into OpenShift. In this particular case, we had some automated end-to-end testing and automated security scann
ing happening in the pipeline as well. - Great, what's this
colorful sticky at the end? The green one, the green one, the build? - Yeah, so these are
some of the enhancements that we do to improve
the CICD infrastructure by putting things like
build monitors in place and lots of information radiators, radiating what's happening
in the CICD infrastructure. So really important to get
that real-time information to the teams. - So that will be up on the
wall projected in live realtime? - Yeah, we've
got lots
of screens and projectors in our lab spaces to
radiate this information. - Fantastic. I mean, I think whenever you
look at something like this, you realize just how complex it is to perform these actions and to really get the pipeline going. They had a lot of products here. - It is, but I think
with a visual like this, you can explain to someone,
even someone less technical, what's actually happening and what all of the automation is doing and why all these wonderful
open source produc
ts really help us to work
in continuous delivery at a sustainable pace and
build these containers running in our container platform, which is the the end
result of our pipelines. - Up in OpenShift, great. Okay, so now you've got me intrigued, what's this top bit here? This looks familiar, this looks like something
we had earlier on. - Yeah, so you remember the
metrics-based process map and we had lots of handoffs and handovers because of all of those different
parts of the organization. Well, we
like to repeat that practice towards the end of the residency. And here you can see it's all on one line, 'cause we've created a new dedicated cross functional product team. So we're not handing
off to different parts of the organization, we have all of those
skills within the team. So we run the same metrics again and we actually can take metrics
from a lot of this tooling around how long it takes to run the builds and the tests, and the
deployments, and the scans, and things like that. And yo
u can see here, some of the times are down
to minutes and seconds, where previously it was
taking days and weeks. So when you total all of this up, you can see now we can get into
much faster release cycles, much faster lead times, much higher frequency of deployments. - Yeah, and that organizational change to move it into a cross functional team means they own it end-to-end. So from asks to get, it's theirs, right? So you really see the impact and the efficiencies that
you can gain from that. -
That's right. And part of that is made
possible from the technology, part of it from these
practices and ways of working, and part of it from the
organizational change of a cross functional product team. - Cool, okay. So we've seen a huge number of practices. How do we sort of bring that all together? Can we visualize that in some way? - Yeah, well, I guess the
final information radiator I want to show is this. So this is called the Mobius Loop which we use to connect
our discovery practices to
our delivery practices
in a continuous flow. So you can see some of the practices that we've talked through
today, such as impacting mapping and metrics-based process
mapping and value slicing. And you can see the delivery practices that we use in sprints. Now we've actually
extended the Mobius loop and we've built this foundation. And these are all of the
cultural practices that we use to create autonomous self-organizing teams in a space of psychological safety. And our foundation also has al
l of these technical engineering practices brought to life by the big picture. Yeah, exactly. So all of these practices
you can read about in our Open Practice Library which is our open source
repository of our growing list of practices and tools
that we use on residencies. - Great, so you mentioned
that we've extended this, so where does it originally come from? So the Mobius Loop is
an open source community which we have forked. The Open Practice Library is also an open source community that a
nybody can contribute to. We keep all of our practices
up-to-date in there. - Fantastic. Okay, well, thank you very much, Tim. That's been absolutely fantastic to get that insight from you and really understand what's
going on in this residency. Been really helpful, and
fantastic to see the way that the practices build
and that starts to engender with the teams themselves
and they adopt those. - Yeah, it's been a lot
of fun walking the walls, and you can read all about these practices and many,
many more at
the Open Practice Library, which you can access at
www.openpracticelibrary.com/learn. - If you would like to
experience this for yourself with one of your teams, please get in touch with your
Red Hat accounts executive, and ignite that lasting change and deliver a real business outcome. Thanks for watching.
Comments