1. Home
  2. Training Library
  3. Self-Organising Teams and Collaboration [A3]

Stakeholders and Customer Engagements (Video)

Start course
Difficulty
Beginner
Duration
38m
Students
58
Ratings
5/5
starstarstarstarstar
Description

This section explains the importance of self-organisation and how teams can use Agile to tackle complex problems. 

Transcript

Moderator: In an agile environment, stakeholder and customer involvement early, often, and continuously is one of the key ways you'll find success in your projects. Hi, I'm Dave. I'm joined by Jags and Paddy once again, and in this video, we'll look at some of the ways you can look to get your customers and stakeholders more involved in your projects. Alright, so the next topic I'd like to talk about now is really about stakeholders and customers and specifically about why in the agile world, engaging with our stakeholders and customers is considered to be so critical.

 

Jags: Good question. Let's talk about what is a stakeholder. A stakeholder is someone who has an interest in the outputs or the outcomes of an initiative or may be directly impacted by the change. So stakeholders could be both external and internal. And what we're trying to do now is engage with these stakeholders continuously, not a one off exercise, but continuously to figure out what their needs are. We talked about earlier about how we need to be customer centric. We need to identify what their needs are as an organisation, as teams, we need to deliver against those needs. And we need to do that incrementally, so we can get feedback and we can learn from that feedback and make incremental improvements. That's the definition of a stakeholder. Paddy you’re gonna give some examples, are you?

 

Paddy: Yeah, so having been a business analyst for many years, it's a topic quite close to my heart. So if I go back actually to around 2004, I'm showing my age now David. So when I sort of first had my first flavour of agile, we were building a product, a software product for our international sales force, so this is within a telecoms organisation, and we were following a framework like Scrum and we pretty much followed it to the letter of the law. It was very much a textbook example, I would say, of how we adopted scrum. We followed all of the scrum events. We had the roles in place. And we had great product owners, so product owners were the guys that were giving us the right priorities, telling us if what we had built was in line with their thinking. And we worked on this programme for about two years. And we didn't actually release the product to the end users because we were hoping we were going to do it as part of a wider roll out within the organisation. However, we constantly sought feedback from our product owners. Andas we went through this journey, as we got towards the end, we decided to have a big celebration at the end. So when we went live, the teams all got together and the technology teams had a big celebration. It was a huge relief to get this product out there to our real users. But what was interesting was within a couple of weeks of our users using this application, they rejected it. They refused to use it. Which was a huge shock for us because we had sweated blood, sweat and tears to get this application out there. 

 

Moderator: Done everything you thought you know, followed all of the scrum practises. Well, you thought you had. 

 

Paddy: Absolutely, absolutely. And as we then reflected and did some more digging, what we found was the people that were advising us, the product owners, they were people that hadn't been performing that role in the business. So the role that the real users were performing, the sales role, they hadn't performed that for a number of years. So their experiences were totally out of date. And what ended up happening was although we had followed their guidance, it was actually the wrong guidance. And so a big lesson learned. And going back to Jags' point, big lesson learned is engaging the real users and the real customers as quickly as we can. And not just assuming someone else knows all of the answers, because they're probably not the real stakeholders. Although they represent the voice of the stakeholders, we should constantly be looking to seek the opinions of the real customers and the users so that we're validating these opinions that we're being told are the right ones. 

 

Moderator: But it must have been a really bitter pill for you guys to swallow at the time because you'd done everything right except for that key part of stakeholder and customer engagement. Whereas if you had just been doing that throughout that process, that two year process of development, you probably would have found that maybe it would have only taken you potentially even a year, or maybe have taken you three years now who knows how long it would have taken you, but you would have that assurance because you're dealing with your customers that when you get to the end, you actually are delivering a thing that they want because you've been talking to them the whole time. 

 

Paddy: But just to add to that point, I was then drafted in as a product owner for phase two of this project to resurrect the project. And I'm not lying, we did this project in six months. And what we actually used was a spreadsheet. So this was like a €50 million programme the first time round that failed to deliver and failed to go live. When we did it the second time, I forget the exact budget, but it was six months’ worth of work and it was of a fraction of that cost. So as you mentioned, just goes to show sometimes the solution doesn't have to be complex. It can be something so simple as long as it meets the needs of our customers and our stakeholders. 

 

Jags: The agile manifesto, what we value, we value individuals and their interactions. We value customer collaboration and customer collaboration needs to be rich collaboration it cannot just be a piecemeal approach, you know, we need to actually engage with them and continually engage with these stakeholders. There are a whole range of techniques we can use to figure out what stakeholders want.

 

Moderator: Cause you often think well maybe you know what is value for the business? Well it's gonna have every bell and every whistle. It's gonna be the shiniest toy in the shop right. But actually it turns out that when you deal with your customers, well they actually just want the Excel spreadsheet, that's all they needed all along. And so delivering that is what delivers the most value, right. If our focus is on value, and understanding what our customers and what our business value, if we can find that balance, that's what we need to deliver. It's not about delivering the shiniest, most beautiful, most pristine, most amazing thing, it's actually about delivering what people need. 

 

Jags: And a good thing because the challenge when we can go with our stakeholders, our stakeholders changed their minds! 

 

Moderator: They do, yes. 

 

Paddy: Absolutely.

 

Jags: As they change their minds, we need to make sure we capture that and reorder, reprioritise work so we are delivering value that meets their needs.

 

Moderator: So that's I suppose the second part really isn't it that by engaging with our customers and our stakeholders constantly when they decide actually we thought we wanted that thing but now that we've been able to play with it because you've delivered some increments, well it turns out that actually that doesn't quite do what we need to do, right. So you're able to identify it early and be able to action that change. 

 

Jags: And the key thing is we need allow our stakeholders, our customers, to inspect our work and therefore after that inspection we get feedback, we therefore can adapt. Yeah. So inspection, adaption, are absolutely critical continuously, not a one off exercise.

 

Moderator: That transparency, right. 

 

Paddy: To add to that, I'm just going back to that point about being able to change your mind. So if we put ourselves in the shoes of our stakeholders. So let's just have a have a have a bit of fun with this. So imagine, Dave, we're going to build a new website, a holiday booking website. And I know you and I were talking about international travel just recently. It's something that we would all love to do. So if you were my stakeholder and Jags and I were going to build this product for you, how long do you think you need to define some requirements for this holiday booking website? Something like Expedia or something similar to that.

 

Moderator: Probably not too long. I mean, I kind of know what I want, right? I wanna be able to book holiday easily. I wanna be able to probably read some reviews. I'd like to be able to get the best price. So I’ve probably got a few kind of core things that I'd like. You know, I'd like to be able to maybe see some previews, some photos, maybe a map. So there are probably a few key things. I could sit down for a morning and probably tell you, well, this is what I want. 

 

Jags: You could sketch something out.

 

Paddy: Okay, about a morning. Tell you what, I'm going to give you a week. So I've upped your time straight away, but what I'd like from you though David, after that week is to give me all of your requirements fully signed off. And you're not allowed to change your mind. Would you be comfortable with that? 

 

Moderator: That's quite a lot of pressure. I would say probably no. Because, I'm probably gonna miss something. 

 

Paddy: What? You said you wanted a morning, and now I've given you a week!

 

Moderator: Well, in a morning I would have probably got a lot of what I would want. But then maybe once I've seen a thing or seen how those requirements have been auctioned, I might be able to kind of change my mind or I'd have some further insights, right.

 

Paddy: Absolutely. And if we think about it in the traditional sense of projects, we often expect our stakeholders because they're the SMEs, they're the experts in that knowledge area, that they should be able to sign something off and sign something off in blood, and not really change their mind because it's going to disrupt our project plan later on. So, as soon as we start thinking like stakeholders, then the agile way of working actually seems quite appealing. And it's actually quite friendly for stakeholders as well to be able to change their mind, but in a controlled way. So, we embrace change, but we embrace it in a disciplined way as well.

 

Moderator: Fantastic. That's a brilliant answer. I think we've probably covered stakeholders and and customer engagement pretty exhaustively now. So let's end the segment there.

About the Author
Students
29741
Labs
125
Courses
1419
Learning Paths
37

A world-leading tech and digital skills organization, we help many of the world’s leading companies to build their tech and digital capabilities via our range of world-class training courses, reskilling bootcamps, work-based learning programs, and apprenticeships. We also create bespoke solutions, blending elements to meet specific client needs.