Have you ever been in a team when you know things could be done better, but other people aren't keen on changing? Have you ever been in an organisation where you want to question the status quo, but the typical response is "that's just the way we do things here?"
These are cultures that brace for change, rather than embrace it.
Many of us are familiar with experimenting, testing assumptions and the build, measure, learn cycle for building products. But how do you apply this same thinking to the teams building the products?
The most motivated and high performing teams embrace change, experimentation and continuous improvement. They are always seeking better ways to work together in order to build great products.
They have a culture where they are willing to try things out, and follow the identify, execute and learn cycle.
This session will look tools and techniques that help teams, individuals and organisations foster a culture of continuous improvement. And give you some new ideas to take back to your teams.
1 / 55 Use ← → to navigate
Auto-generated transcript - may contain errors.
Tap a timestamp to jump the video.
I'm going to talk to you today about embracing change or bracing for change, fostering a culture of continuous improvement in product teams. First of I wanted to explain why this title. So I spend a lot of time with teams, often referring to the Agile Manifesto, which talks about embracing change.
And lots of teams say, yeah, yeah, we embrace change. Change happens all the time and we deal with it. And I started to make a distinction between embracing change, like really looking for things and really looking for change to happen, or bracing for change, which is just kind of it happens to you and you just kind of put up with it.
So that's my kind of my big distinction between the two, and it's a term that I've started using with teams. So my clicker's gone, so I'm just going to do this manually. My name is Emily. Emily Weber. I am an agile coach, agile consultant, so I'm not really a product person as such.
I deal a lot with organizations. I used to work with Pete Hurleyhy at Government Digital Service a few years back, and now I work with quite a number of government departments and some non government people. Once you're in government, that's kind of it, you're trapped.
And I work with lots of organizations that are looking to adopt agile ways of working or new ways of working kind of for a multitude of reasons that they want to get benefit out of. So I'm going to talk to you about change kind of in product teams and in organizations.
I'm going to give you some tools and techniques that you can take away with you, going to get you involved. There's going to be some interaction here. It's going to come from you as well. So hopefully, some things you can take back to your teams.
So the first thing, this might be a challenge if people don't have pens. So get yourself a pen and a bit of paper or a device, something that you can write something down on. So if you've got a phone or laptop, that's great.
And I want you just for a moment just to imagine that your team or your organization, if it's not necessarily in the team, is the best that it possibly could be, and things are fantastic and going really well. What I want you to do is just write down a couple of things of what that looks like.
So what does that team a couple of things, kind of vision for that team. I'll give you about twenty seconds. When you finish, if you can just put your hand up so I know who's done. People. You're all vision people, aren't you? So you've got these kind of grand visions for everything.
Alright. Just a few more seconds. Put your hand up when you're finished. A few around the room. Okay. So we're going to keep that for a little bit later, so don't lose it. You can add to it in a bit as well. And we are going to come back to that.
So I don't you're product people, so I'm assuming that you know this. We're quite used to in products thinking about lean start up, the build, measure, learn cycle, and learning, you know, learning from what we see, learning from the way that you users do things, and changing products accordingly.
What I'm going to hopefully do today is is kind of introduce some ways that you can use that kind of thinking with your teams and your organizations as well. It's not just something that you need to that you can apply for product to products, you can apply it to other different different situations as well.
So the lean start up, I'm gonna talk about a few experiments during this talk. So the lean start up really comes from the scientific method. So this is the scientific method. We ask a question imagine you're a scientist, imagine you're in a white coat ask a question, do some background research, construct a hypothesis, test that hypothesis, and analyse data and draw conclusions from that hypothesis.
One thing that's really important in a scientific test is that you only have one variable, so you're only changing one thing because it's very difficult to see what else what affects the change if you're changing lots of things at all the same time.
And, again, you're all product people, you're very familiar with hypotheses. So this is a hypothesis statement because I think this is true. I think that doing this will mean that something will happen, and you will know in some way. And that measurement bit is really important.
If you can measure if you if you can understand what you'd expect to see when things change, you know whether you're doing well or not, and that's working. So as I mentioned, this is not just for products. You can use this in your teams too.
So it's a question that you kind of sometimes you have to ask yourself when you think about change and embracing change. Is there a reason why your teams or your organizations aren't already embracing change? Is there something that's stopping them? So do you actually have the right culture in place in order to in order to change?
Some people just like the status quo. I'm sure you'll recognize this picture behind me. Some people like the things the way that they are, and change offers quite a lot of threats to them. So we will actually often People think, yeah, organizations, you know, everything should change, things should be better, but it's quite a hard thing to do for yourself, and it can be quite a daunting thing to do.
So we need to understand what's blocking it. And if you hear I think this has been mentioned a couple of times in talks today already. This is just how we do things around here. So this is a cultural statement. This is often somebody referred to some kind of policy or some kind of security procedure that this is how we do things, this is what we've built up over time, and assumptions are made about the way things have to be done, constraints are put in place, and people think that's just the way things are done,
and they won't change. So why is this? So I'm going to give you now five reasons why people resist change, something that you can think about and give you some things that you can you can do to help combat some of those reasons, and try and understand the motivations people have around not changing.
So uncertainty can cause more stress than inevitable pain. So this is a statement taken from a scientific study that was done by the Medical Research Council in March of this year. And what they did, they wanted to test the hypothesis about how much stress uncertainty caused people.
So they got a bunch of people in a room, they hooked them up to monitors to check things like their stress levels, their cortisone levels, things like that, And they also hook them up to a potential of having a painful electric shock. In the study, they had them play this computer game, and what they did is during the computer game, they lifted up and sometimes under the rock there was a snake, and sometimes there wasn't.
And when there was a snake under the rock, they got a painful electric shock, and this caused quite high stress. It's fiftyfifty chance that you're going to have a a painful electric shock or not, and their stress levels went quite high. They then tested this same thing again, but they changed the percentage.
Ninety percent of the time, people got this painful electric shock. And what they found is that stress levels came down. So people were less stressed when they knew they were going to get an more likely to get an electric shock than when they had a fifty percent chance of not getting one.
And what it showed is that people find uncertainty really stressful. So as much as we love agile, we love being agile, we also kind of want to know what's going to happen at the same time. So one thing that you can do to help deal with that is to get into the habit of changing.
So get into the habit of that uncertainty and feeling that stress, and those stress levels will come down if you do that on a regular basis. So the second reason is change means learning new skills. So particularly if you're in an organization or maybe you're new to a team that's trying out new ways of working, that might mean that the skills that you had before aren't relevant and that you need to learn new skills.
I spend I've spent some time with project traditional project managers in the past, and they they've spent a lot of time getting to the point where they are learning the skills that they have, and now there's this new way coming in, and they they kind of don't know where they sit in that, and there's an awful lot to learn.
So you need to be willing to support people learning new things through that change. If you have someone, for example, new on your team that has a new way of working, that might be shadowing other people. Excuse me for just a moment. It might be pairing with people, it might be some training that they need.
It's also worth not throwing out all the skills that they had previously. So the next reason, this this is a sad panda. It's one of my favorite pictures on Flickr. So there's a condition called learned helplessness. Any of you that have worked in large organizations may be familiar with this, or you may have experienced this yourself.
So it's a condition where people realize that they can't make any change, they can't do anything different because they've been told in the past that they can't, or they've come up against problems time and time again. So it might be a traumatic event where they've kind of been given their little box, and if they step out of it, get in trouble.
This was a term that was coined by another scientific experiment where a scientist had a dog in a box, and they were testing out conditioning. So they were ringing a bell, and every time the bell rang, the dog had an electric shock through the floor.
These scientists, they basically love giving people things electric shocks. And so they got the dog used to this idea that the bell rang and they had this electric shock, and they opened up the box and had another area where the dog could jump to where they wouldn't get the electric shock.
And what they found was that the dog didn't jump. It just stayed where it was. It heard this bell and it kind of stayed where it was because it just learned that this is this is just the way things are. And some of you may have seen this in people, in places.
So it's really important to create a safe to fail environment, to let people know that it's okay to fail, to give them the empowerment that they need to change, celebrate things, you know, let people tell people they're not in trouble, and give them a chance to ask for help.
So reason four, people don't like change because it could mean throwing away the hard work that they've already done. So the reason there's this wonderful I'm sure many of you have seen these instructions for a billy bookcase. There is a cognitive bias called the IKEA effect.
It's many biases, and this is one of them. And the IKEA effect says that we attribute more value to something if we've built it ourselves than it's actually worth. So it's great for IKEA because, you know, all your all your IKEA furniture means more to you because you built it yourself.
So if you're throwing away people's hard work, you might not think, you know, other people might not think it's valuable, but but for them, it's really valuable, so throwing it away is quite a difficult thing to do. So it's always worth building on what already exists and not throwing things away, kind of moving people through that slowly.
And the fifth reason is that people don't always understand the reason for change. They don't necessarily understand where it is that they're trying to get to. We all obviously have visions for the products that we work on. They don't understand the vision of where they want to get where you're trying to get to, and they may be being pulled in different directions, so they don't really want to change.
So it's worth having a vision for the future state, where it is that you're going, much like we did that first exercise at the beginning, which we will still come back to. I just wanted to make a point about evolution versus revolution. So one way of getting through some of these issues with change is actually making small changes.
If any of you have done any organizational change, you might be familiar with this Virginia Satir change curve, which is sometimes called the J curve two. This is that anyone that goes through kind of big change, they start in a state of status quo, something happens, a change happens, and they go through some resistance.
Then it goes into chaos, and you get this dip in productivity. So that's the big red bit that you can see. And big dip in productivity and performance whilst everything's up in the air and people are trying to grapple with the new way of doing things before you start moving up into integration and then eventually the new status quo, which is kind of much better than the old status quo.
And what happens quite a lot if you really want to destroy an organization is once it starts going into chaos and performance dips, is that people think, oh, this isn't working. We need to change again. So they change again, and then it dips again, and they change, and it dips, and it dips.
And they kind of get into this kind of constant state of performance going down. So sequential j curves. So avoid chaos unless you need a revolution. So sometimes a revolution can be a valuable thing to do, just throw everything out. But if you're looking for people to buy into change, particularly in your teams, you wanna make small changes.
So I would not be an agile coach if I didn't have some Japanese words in my presentation and references to Toyota. So this is Kaizen. So Kaizen means it actually literally translates as change good, and we use it to mean small continuous improvement continual improvements.
There's a social scientist called BJ Fogg that talks about baby steps and success momentum, and the idea, and this is both kind of for yourself changing and other people changing, that if you start taking small steps and you get success, and you start to build this momentum where things keep being successful and you can take bigger steps.
There's a video, he talks about this where he's talking about how he does fifty press ups a day, and every time he goes to the loo, does some press ups, and then that kind of builds and builds. It did make me wonder that if if you ever see anyone doing press ups in a public toilet, then maybe it's BJ Fogg building this habit of change.
So there is a tool that you can use. One one of the tools I'm gonna give you is the Toyota Improvement Carter. Now anyone not familiar with Toyota? They went through a huge kind of boom through changing the way that they did things without much money, and they created fantastic, well, high quality cars cheaper and quicker than anybody else.
And they have this thing called the improvement carter, which is for teams, and something that you can use, you can have on your wall. And it goes through these four steps. So the first step is about understanding the direction of the challenge. So this is the vision piece, this is the bit that we did at the beginning, understanding where it is that you want to get to, where is your perfect team.
The second step is grasping the current conditions, that's getting the baseline of where you are now. So you will never know if you've improved if you don't understand where it is that you are now. Third step is establishing the next target condition. So you can relate this to goals.
You have your vision, which is your direction of travel, and your goals, which is your next target condition. Once you've established that, which you do on a regular basis, the executing phase is experimenting towards that target condition. So much like we do with our products, experimenting, going through that cycle.
So the improvement Carter is all about small changes, vision, habits, and building on what we already have. So this is back to our hypothesis. So during that experimental stage, you can hypothesize about what you think is going to improve your team. It might be team morale, it might be things outside your team that are blocking them, it might be performance in general.
Those are things that you can hypothesize about and try out on a regular basis and see how they're working, much like you do with your products. So there's also a wrong way to go about change. You can't just tell people to change. They don't react very well to it.
When I was writing these slides, it reminded me of the joke, how many psychiatrists does it take to change a light bulb? Anyone know the answer? The light bulb has to want to change. Yeah. Just one. So there's this great video. There's there's a channel called the Behavioral Science Guys.
I won't play you the video. I will show you some slides from it. And they did this experiment where they were trying to get smokers to think about stop smoking. So they got a couple of twelve year olds, and got them to go up to smokers and say, Hey, you know, smoking is bad for you.
And the smokers were like, Oh, yeah. Yeah. I know that. Who doesn't know that? Everyone knows that. So they said, would you like to get know where you get get some help? What do you think their answer was? Nah. Interested. They're not interested in being told that what they're doing is wrong.
And they switched that round to questioning. And they gave the kids some cigarettes and got them to go up to the smokers and ask for a light. So twelve year old coming up to you asking for a light. They said no, of course. So the kids were asking, why not?
Obviously, they told them that, you know, it's not good. You won't be able to breathe. You'll get emphysema. You know, all the bad things. Which actually then in turn made them reflect and say, well, actually, I don't want that either. So I need to I need to quit.
And this experiment was tried out in Thailand. I think calls to the line went up forty percent when they did this. People were suddenly getting this kind of internal motivation and wanting to change themselves rather than them being told to change. So it's all about motivation and bringing people along with you.
Okay. So more tools. We're going to talk about identifying what it is that you should change. So, hopefully, you're gonna come away with some things that you'll take back and you'll want to change in your teams. First question is around agile retrospective. So the agile retrospective is a chance for the team to get together on a regular basis to look at what's working, how they work together, and looking for ways to improve.
So question. Hands up if you have ever been part of a retrospective. Few. Not bad. Hold keep your hands up. Keep your hand up if that was in the last six months. The last three months. Still some up. It's good. Last month? Last two weeks?
So all of you that don't have your hands up, you need to do some of this. It's one of the most valuable agile exercises, meetings, events, whatever you call them, that you can possibly do. So would I would say you should start doing them on a regular basis.
And what I'm gonna do now is give you the chance to try that out. We're gonna do a thing called the thirty second retrospective. Now the thirty second retrospective is a chance for those of you that don't retrospect very often with your teams to get into that habit of doing it.
For those of you that are doing regular retrospectives, to kind of rebuild that muscle, you may have found that your retrospectives start getting repetitive, few of those happen, give you a kind of a chance to really focus. So what I'd like you to do is just grab another person, not not too hard, Just find a pair.
You can be person a and person b, just work that out very quickly. Has everybody got a pair? Good. Alright. So this is an experiment. I haven't done this before. I'm sure it's gonna be fantastic. So what we're gonna do, you're gonna have thirty seconds and what I want we're gonna we're gonna have thirty seconds each.
So I want person a to be talking to person b. So thinking about the vision that you had earlier, so you can refer back to that. What's the next big improvement that you want to make, that you want your team to make? What one change could you make towards it?
And how will you know if it's worked? And if they're useful stuff, obviously take some notes. So we're gonna have a countdown clock on here. So person A to person B, off you go. Stop. That noise means stop. Okay. So hopefully hopefully some useful stuff there.
I'm gonna ask you to swap. So person person b to person a, remember, you know the rules. Off you go. Alright. Stop. Just just quickly, anyone find something out useful there that they might take back? Couple of hands. I won't ask you to call it out just now.
Make sure you write it down and you don't forget it. And you've got this tool, can use it when you want. So with retrospectives, if any of you are looking for new ideas, there's this book called Agile Retrospectives. These slides are gonna be available later as well, I believe, so you can grab it from there.
And the retrospective wiki and the internet's full of really great ideas. Some other techniques you can use for finding out things that you need to change for your team. So mapping out pain points. So mapping out the process that you use and identifying the points where stuff takes a really long time or is really painful and concentrating on trying to remove those things so that your team can work better.
Reviewing your blockers, so if any of you have physical walls or use Trello or cards or anything like that, when you remove a blocker, take note of it, record it somewhere, and then at a certain time you can get back together, cluster them, see where the kind of main problems are and use them to make things easier.
Retro Slack channel or retro wall, so it's really hard when you get into a room after two weeks to remember what happened over the last two weeks. It can be useful if something is frustrating or something goes well, putting on a Post it note, sticking it on the wall and saving it for a point where you can come back to it later.
One of my clients uses a Slack channel to do that, they just dump notes in there, come back to it later. One to ones, not everybody is comfortable in a group environment sharing everything that's paining them, so one to ones could be very useful.
And things like five whys or root cause analysis, really trying to understand where problems are going wrong. Actually, generally asking why and not just accepting that status quo. So points to remember, change is hard. It can be frustrating when you go into a place and you go, the answer is really simple.
It's not the answer that's the hard bit. It's actually bringing people along with you. Understand which direction that you're heading in. Have a vision for the future state, use experimentation and the scientific method, so a team that doesn't experiment isn't embracing change. Make small changes, don't kind of throw everything out on a regular basis, That's the evolution versus revolution.
And get get into the habit of experimenting. So do it on a regular basis with the team. Get that success momentum. And remember to embrace change, not not brace for change. Thank you.
