Podcast | Calling all stakeholders to deliver an experience your users would actually love – the agile advantage

Jean
Shin

Director, Strategy & Content | Podcast Host of Mobile Interactions Now

22 min Podcast

In this episode, we delve deeper into agile practices and tools that can help you engage the right stakeholders at the right time. Drawing from his books and additional anecdotes, Mike Burrows reveals the secrets behind making the right conversations happen to keep the team on track for success.

Podcast transcript

Jean:

Mike, welcome back to the show. In our previous episode, we touched on how companies can build on the general concepts and tools of agile and improve their chances of success. In this episode, I will like to get more granular and delve into the actual process of a solution design. One of the things I love the most about the agile approach is how it's facilitating customer collaboration and experimentation. I mean, especially now we are getting better at separating the backend from the front end for prototyping and so on, which is incredibly helpful. So, let's start there.

 

Mike:

Well, the good news about frontends is that they're actually quite easy to prototype, to get an idea of what they're going to look like. And, so when I say get an idea of what it would look like, I'm not talking about months of detailed design. We might be talking about sketches, and storyboards, and things like that. We're just give a very high level impression of how it's going to work, and you trust the detail to come out in the process of evolution and testing. And, if you're clear enough about what your goals are, so it helps you be clear about what we don't need to do yet. Very few architectures designed in detail upfront survive the whole project. Now, when you want most, you understand.

 

Jean:

I know what you mean.


Mike:

Yeah, exactly. And as I mentioned earlier, complex systems that work, they've always evolved from simpler systems that worked. You embrace those sort of things. You get something that really works really well for an objective that you really understand and deliberately excluding objectives that you can defer for a later day and use that as your basis.

And, now you've got an end-to-end process, perhaps in just a matter of weeks, you've got an end-to-end delivery process that works. You've got a strategy that is developing over time. You're clear about what your overall objectives are, and the detail emerges at the time that it's needed based on the right conversations with the right users, with the right stakeholders. Recognizing the diversity of users, recognizing the diversity of stakeholders, recognizing there are lots of people with a stake in the solution. And deciding for the day, for this next sprint, for this next month, for this next quarter, where are we going to focus our efforts? What is the objective that we're going to meet, and how will we know that we're being successful?

And, if you could be really clear about those things, you will be focused, you will deliver so much faster, you will waste so much less on things that aren't needed and so on. And actually that's all great advice, whether it's a technology project, or a some kind of internal change initiative. The same advice.


Jean:

When I talk with some of the businesses who are launching new services, and trying out different touch points and things of that nature, one thing that really comes up quite often is, technology is not the main challenge because these days a lot of different technology options are there. And, actually there’re components they can put together pretty easily once you agree on what problem they need to solve.

But, I've seen cases where it plays out differently, in B2C versus B2B. Because, in many business-to-business scenarios, it's really different from making a little mock-up and then going to the streets, in pre-COVID times, and doing mall interceptions that get you a quick feedback or something like that. So, when it comes to more of a business-to-business situations, even deciding when to test, and getting that triggered is sometimes, I find, rather complicated, sometimes even political. Any advice as to how to play this out?


Mike:

There are some good news, is actually a lot easier than it used to be. And if you go back 20, 30 years, maybe a slightly longer. It's showing my age now. When you did a B2B integration in the battle days, there were technology implications to that. It meant buying into a particular technology, it meant buying into whether Microsoft based or whatever it might be. And we're in a much better place now, because we integrate now at the level of protocols, not the level of technologies.

You're not betting the farm on a technology, you don't have to exclude a solution just because it's based on the different technologies than one you're familiar with internally. And, I think we all know now is that new technology is forever, but the great thing is now that we've developed ways of isolating different systems from each other. They talk to each other over the internet, or over whatever mechanism it might be, but they talk to each other in ways that can stay relatively stable even as technologies change.

Business-wise, you've got to look at the business controls around the tests that you do, so this takes me back to my time in banking. I remember a day when I did a million pound trade in a production trading environment by accident, and that sort of thing isn't supposed to happen, but banks are well protecting the business controls. They knew within minutes that it was a mistake, and it did actually get as far as another bank, the counterpart that I had my test traded with. They say, "Where did this come from?" And in the end, actually, it wasn't that big a deal. It shouldn't have happened, and actually, we took steps to make sure that it couldn't happen again.

So you need business controls around testing. It's helpful if you've got separate test environments, that's one quite expensive way of making it happen. You might be able to segregate data even within a production environment, so you might, for example, start with a separate environment. So a test environment to a test environment, and then you might do testing in production, but where the data is segregated in some way. So back in banking, we would have some trading books we would trade in and we knew that it didn't matter. And, you could do internal trades or even trades with counterparts in these trading books, confident knowing that it wasn't going to have any material business impact.


Jean:

Where you can roll back.


Mike:

Yes, but you need your risk people, you need your finance people, you need your trading people. All these people need to know. Well, they need to know what's happening first of all, and you need to have robust tools and policies to keep that segregated stuff properly segregated. Each business, each industry will have its own norms for these different things.

But, for example, I'm using a messaging platform. Either platforms out there for sending emails and SMSs and so on, from your application that you built. And, many of those will provide a test platform and they'll send messages to test addresses. It's especially easy to configure separate environments, or segregated environments within potentially a large system. You don't have to do big bang deployments. There are often ways of turning things on incrementally.

I remember in my banking days, we did a cut-over that we're talking about billions now of pounds worth of securities. That cut-over was done over a number of weeks book by book, and it takes some coordination between technology and your business control people to do that, but it definitely can be done. Sometimes big bang is fine. Personally, if I can avoid it, I would rather avoid it.


Jean:

It's so funny though, there's a flip side of all this.


Mike:

Yeah, always is. Yeah.


Jean:

I remember the time when we were complaining about not being able to test properly, but these days I realize we have more testing environments, sandboxes and all. But, what we are starting to experience as well is that because it's considered to be very easy to test, there is a continuously rolling POC, a proof of concept stage where you solve the problem that needs to be solved, and you start adding on other feature and so on. And then you're stuck in this testing mode, and really needing someone to say, "Hey, this is a make-the-call-kind-of moment where you start deploying."


Mike:

Where was the business objective that let it happen? If you had the business objective, the meaningful business goal that needed to be satisfied within a suitable time period, then you solve that problem. You're not just forever polishing the system until someone's ready to release it. And there's a business goal to be solved, and when we sold that one, we'll move on to the next one.


Jean:

Defining the goal, I think, is really the key. And then making that visible, I think people tend to forget when it becomes a big project.


Mike:

Yes, yes visible means someone with influence is articulating it every day. And, it noticed when that goal is looking difficult and it's celebrated when it's met, and it's clear what are the steps along the way. What are the milestones we're going to be celebrating along the way? Perhaps, and ideally there are some business results that we can celebrate along the way, so if the business is winning in that process, then everyone's a winner.


Jean:

I want to talk, actually, a bit more about that. Some teams who are working on a very big project, versus something easily deployable, seem to have a harder time to make the interim stage more visible…showing the milestones and not losing the momentum. That seems to be requiring more attention as well. How can we, more systematically, get these successes more shareable and visible?


Mike:

Yeah, again, there's a few things that I've thinking back to my first... It was my second of those government projects actually, before we were ready to go live, I was telling... People were really worrying, and thinking it's going to be horrible when we're alive. We're going to have a system to support as well as having development work to do. And I was really excited and I said, "It will be so much better when we are live and we'll start to get some real feedback. And, we'll know that our hard work is actually doing some good, and there's some gratification there and all the rest of it."

And I'm really glad to say I was right, and everyone was actually really excited when we to go live. And, it really was actually really great to get feedback from real users and so on. But, there was a lot of hard work to be done in the meantime. And, there was a lot of hard work in their case to have a completely scripted way of building whole new environments and doing deployments. And it would took frustratingly long. This is in the very early days of Azure. Early enough that the platform itself was changing quite quickly, but the work was done.

And at a push of a button, we could create whole new environments. We could deploy from one environment to the next we could deploy to production. Suddenly, the path is cleared and we can make a change in one environment in our development environments. We can see it very quickly in test, we can see it very quickly move to production. That's that's game changing. So, there was like a stressful period before we got to that we're all winning. But I'd done it before, I'd seen it before and so I was able to encourage people to say, "Trust me, it sounds scary now, but it's going to be great."


Jean:

Yeah, and many people working quietly…sometimes those are the ones who are really making it happen at the end of the day. And, if the whole process is not making that visible, I think it just loses steam.


Mike:

That's a very good point. Something we used to do was we used to call them show and tells. Scrum people sometimes call them demonstrations, a sprint demo or sprint review. But every two weeks without fail, we would have a meeting where we would share what we've done, shared our learning, share other aspects actually of the process as well. Share some of our metrics, share some of our pain points, share what was in the pipeline. A lot of sharing happening, and in the case of those exemplar projects, I said there were a high profile projects. We have people from all over the country from different government departments coming to see what we were doing, and hopefully to take back some of what you're doing back to their organizations.

Now at a smaller scale, if you're doing this for the first time, don't underestimate the value of sharing widely, giving people the opportunity to see what you're up to. Give people the opportunity to contribute some great ideas as well, and that's something that can be institutionalized. And, I've talked about working to objectives and knowing when you're winning and all the rest of it. And, you start to hear what the objectives other teams are working towards and what their signs of winning are going to be. And, then you start to see those converge and align and so on. And, now the organization as a whole is moving forward so much faster. I've avoided using a jargon that's OKR [inaudible 00:14:42]-


Jean:

I understand. The struggle between uppercase and lowercase A is such a bothersome choice there. Especially audio driven experience, like what we are having right now. So, I mean, we touched on some of the obstacles, any other big obstacles that we haven't touched on yet?


Mike:

Obviously, you need to recognize quickly when something's not working well. I developed the sort of intuition, the default position that if ever I saw something not working well, I would assume it's a collaboration problem. And that was actually really helpful.


Jean:

And, you were right 99% of the time.


Mike:

I was right 99% of the time. Usually, it was a conversation that hadn't happened that should have happened. And, there was a change the process that we could make that would ensure that conversation would happen. No, it doesn't mean sticky documents, it just means quick conversations happening at the right time. A conversation happening between... For example, you are just about to start a piece of development work, and there's a great technique, it's called the three amigos conversation. I didn't invent it.

So it's product people, technology people, and test people is most common three, having a conversation at the start of a piece of work. If your problem is work gets into test, and no one knows which environment it's supposed to go to, who's going to test it? By what criteria it's going to test and what test it, and so on, really common problems. Preempt that at the beginning with the three amigos conversation. When the work gets to where it needs to get to, people know what needs to be done to it. It's kind of easy and obvious when you think about it, but that's one example of a much broader class of problem.

I mean, back in my days when I managed a global department in a bank and code reviews sometimes two weeks. I mean, there's a real failure of collaboration happening there. That just shouldn't happen to find a leadership on the part of some of the tech leads as well, that they weren't ensuring that code was getting to that stage in a good state. Frame it as a failure of collaboration. It avoids it being... I mean, I'm not being quite so judgemental about the leaders by saying, it's a thing you need to collaborate better. And, it certainly takes some of the pressure off the poor junior developer who hasn't been appropriately mentored through the process.

That kind of language changed that problem almost overnight. It's amazing how, just that way of looking at it can change those problems.


Jean:

I cannot agree more, because just recently, we were desperately looking for a frontend developer. And it came down to two choices, and my head developer picked one person over the other. And, I was curious because the other person had more experience and the skillset was a lot more extensive. And the response I got was, "Well, the other one was a lot more communicative."


Mike:

Yes, yes.

And, if you've got the aptitude and any technology, any language, anything else, those things can be learned. And that's not to dismiss its expertise, but a willingness to collaboration and a willingness to learn are two very valuable features anyone joining a development team. Yep.


Jean:

Okay, so this probably will be my last question. I would suggest that we make a list…so that we can walk away with something to check off… In terms of what we have learned in past couple of episodes... so, Mike, what should be on our list?


Mike:

Well, I'm going to narrow the list down to two, but that's who, I suppose, quite rich things. The first one is agreements and outcomes, and there are some conversations that absolutely have to happen if you can achieve anything of significance in your organization. And whether you call that discovery, or whether you call that working out your OKRs or whatever, authentic agreement on outcomes and meaningful to the right people in the room you need that. So that's thing one, and actually that's the beginning of the strategy. So it's a great place to start.

So that goes to my to my right to left book is that the whole idea of right to left. Be clear about what it means for a need to be met, and that outcome to be realized. Whose need, make sure you really understand the people that you're serving, what their needs are, what their moments of struggle are that you're going to help them overcome. And, your solution ideas are only ideas until they prove themselves meeting those needs, and if you get that and optimize your process for doing that again and again and again, you should do well.


Jean:

That is an absolutely wonderful wrap up. But actually I lied a little there, I do have one more question.


Mike Burros:

One more question.


Jean:

Yes, and it is kind of a nosy one. And, can you tell me what you use the most on your phone these days? Top three will do.


Mike Burros:

Right, so I am a news junkie, I will admit. So, I check the news a lot and globally as well. So I kind of a little ritual, I have a list of bookmarks on my phone. So I'll do BBC News, I'll do PoliticsHome, I'll do CNN, I'll do New York Times, Washington Post. And, I'll get a, "That's a bit transatlantic." But I mean, I'm not checking trying a daily or something everyday. But, at least those I'm checking multiple times a day.

And my other one is, I suppose, for the tech gossip, really. And the startup space as well, which I find fascinating as though I really interesting into play, as I said before, between the product space and the organization space, and the startup space really encapsulates that. And, so I love hacker news, it's just a place to get lots of links. Very diverse, interesting topics of generally people of interest to people in the technology space, and in the startup world in particular. Whether it's a bit of politics, is a bit of society and everything else in there. So, I do look at those a lot.

After that, I suppose it's probably Spotify. I love music. Like you, I play the piano, I listen to all sorts of styles. I grew up on classical music, I got into modern popular music in my teens. Really hardly exposed to it until my teens, and then I got into jazz. When I finally got on the Spotify, I kind of just sort of binged out on the '70s. Some great music in the '70s of all different kinds of genres, jazz and fusion, and rock and soul, and R&B and all that. So a lot of time listening to music, yeah big Spotify user.


Jean:

All right, so I must admit I didn't expect it to be so balanced. I absolutely loved it. I thank you very much.


Mike Burros:

Thank you, it was a pleasure talking to you.