Pamela Paterson - Get know your stakeholders

Speaker A: Welcome back to another episode of Agile Way podcast where we explore challenges organizations face on their Agile journey. How to become great SCRUM Master, how to change your leadership style, or how to embrace agility at the organizational level. I'm Suzie Shikova, Agile Coach, certified Scrum Trainer, and author of the great SCRUM Master book and Agile Leader Book, and I am your host for this podcast. I'm passionate about business agility, organizational culture and agile leadership. And that was the reason why I decided to start this podcast to share with you my experiences and stories from my Agile journey. So, hello everybody. Let me welcome here Pamela, one of our speakers of, uh, Agile Prague Conference, which is happening 9-15-16. And, uh, I have a question for you. What are you currently passionate about in Agile space?

Speaker B: I am always passionate about stakeholders. What their business needs are, where they want to go, what their pain points are, and meeting that need. So as a business analyst and a systems engineer, my entire world is centered around stakeholders and the requirements that they need in systems.

Speaker A: So how would you define stakeholder? Because I am using the term, but I often got this question. So, um, it's good to ask the expert,

Speaker B: you know, stakeholder. It's very hard to nail down a definition, I think, for a stakeholder, given that there's so many different interpretations and leanings and nuances of stakeholder. So I completely agree with you there, Susie, and how I think of a stakeholder is somebody who has a business need, somebody who is impacted by the system, somebody who can impact the system, somebody who can influence the project or be influenced by the project, and somebody who has an interest in the project and in the system being developed. And, uh, you know, when you look at all of those kinds of factors, that's a lot of people. And of course we want to rank our stakeholders, we want to prioritize them, we want to determine if they will be part of the inner circle or part of the onion layer that we peel off and get to them later. Or maybe in a very small way, but it could be conceivably quite a large group of people that we want to consider when we're developing a system.

Speaker A: Uh, that's true, that's true. These are very diverse preferences and needs. So tell us more about how to collaborate with this group.

Speaker B: There are so many ways that you can collaborate with stakeholders, and the number one thing that we need to do is get to know them. We really can't collaborate and resonate with people that we don't know. And so that's a very, um, that's the number one thing that you should do. And it's not so difficult. I mean, it's almost like, um, think about developing a relationship with a friend. They, you can't ask intimate questions or very serious questions when you first meet somebody. But once you develop a rapport, once they be able to trust you, once you get to know them, once you know which questions to ask, which questions you can get answered somewhere else. Um, um, you know, I often use the example of an apple. You know, let's say that, I mean, it's kind of a strange example, funny example, but let's use the example of an apple. And we are getting requirements for an apple that somebody wants. I mean, somebody might grab an apple out of the fridge and say, here you go, here's an apple. But, but the person might say, you know what? I, I really wanted a yellow one. I, I really wanted a red one. And so you need to really think about what their business needs are, what their pain points are. Maybe they can't chew an apple. Maybe they need an apple that is hot and mushed up and they live in a cold climate like I do here in Canada. And they need, um, a cold, they need a hot, mushy apple. And that's going to suit their needs, but it's not going to be the needs of somebody else who lives in a, uh, maybe a warmer climate or likes the sound of biting into an apple. So once we get to know people, that's going to really help in our requirements, elicitation with them. Um, and of course using really great interviewing techniques. We've all seen news interviews where one interview goes really, really well and the other one bombed. And that, that's a, that's an art and a science in itself. But if you can do that, if you can learn how to pull information out of people, your requirements are going to be top notch in the system.

Speaker A: That sounds nice. So tell us some tips how to get those informations out.

Speaker B: Absolutely. So the best thing that you can do is research. Uh, and then the question is, what kind of research? How do I research? What do I need to know? What information don't I know? And structure. So structure having a definitive beginning, middle end, knowing what your script looks like before you walk into that room. So that interviewing script, that introduction that you have with your stakeholders, that's really important. So you are defining what that session is going to look like. Um, maybe you're going to use some techniques like time boxing. So we always have stakeholders who don't talk and then we have Stakeholders who talk too much. And it's learning how to deal with each of those stakeholders. So a stakeholder who maybe talks too much, you need to learn how to manage that. And one of them is through time boxing. So you can say, um, if you know the stakeholder and you know they're, you know, they like to talk and you don't have time for it necessarily, you can use time boxing so you can say, well, in this interview we're going to have, uh, we're going to spend five minutes on each question and then you can have a way of, of, um, of ending that in a very polite and diplomatic way so that they know, um, you can also interrupt with a compliment. Okay, so it might be something like, Ralph, I really appreciate your comments on the security aspects of this system. And it reminds me that we haven't yet talked about reporting. Okay, so that's a nice bridge into another topic. You have acknowledged their contributions, you've thanked them, and you've also acknowledged that you need to move on into another topic. I think that's really important is to appreciate stakeholders, appreciate their time, and let them know that they are appreciated.

Speaker A: Appreciation works like a magic. That's true. Now, um, let's say you do really good interviews and you get all those various different ideas and wishes and needs. Now what to do then? Because you cannot do everything for everybody because you need to prioritize and decide. So any tips?

Speaker B: Isn't that the truth? So we have somebody's wish list and we need to prioritize. We need to allocate it to sprints, we need to allocate it to a next version of the system. And it's difficult. The thing I found works the best is mitigation in any of those difficult spots. And what do I mean by mitigation? I mean that if you get the project team to agree on certain criteria that we are going to use requirements. So for example, maybe, um, the criteria might be, um, regulatory. So those are deal breakers. Those are, those are musts. Regulatory, um, um, timely, business needs, financial, whatever criteria you want to use to top rank requirements. And you have this grid figured out and agreed upon with the project team before you walk into those meetings. It means that you have a very objective framework within which to judge and prioritize and rank those requirements for implementation into the system. And then it doesn't become a battle of I need this, I need that. Because you're judging every requirement against this grid that you've already predetermined in a very objective way and had Agreement with your entire team.

Speaker A: Oh, that's cool. It sounds so simple. So what was the most tricky or the most difficult uh, situation dealing with stakeholders? Can you share some experience, uh, from you?

Speaker B: Well, the most difficult, um, the most difficult situation I ever had was somebody who had a very severe mental illness and it was not known at the time that he had a. And you know, more than 3% of our team members are affected by mental illness. It's a very serious thing and it's a very real thing and it's something that everybody in their life in one way or another needs to deal with. So we had a team member who had a very serious mental illness, but nobody else knew it. We saw different behaviors and interruptions and a, uh, lot of anger outbursts and things like that and didn't know why. And so one of the strategies that I always adopt when I work with people is publicly praise and privately help. And what does that mean? It means that in, in public and with the team, you always want to find a way to praise somebody's idea, make them feel acknowledged and appreciated. And, but privately, if somebody is sensitive to criticism, privately, you help them and you say, you know, what, what do you think of this idea? Do you think this might make your idea better? And so what they see is public support. They see you are backing them, you are strongly behind them in front of the team, and they also feel how much you're helping them. This is the technique that I used with this particular individual because it, it became such a, um, such a difficult situation that people refused to work with him. People said they were going to quit the project, they were going to quit the company. I mean it was very ser. Kind of situation. But when I use this technique, and it's a people relationship building technique of trust and rapport, I saw over time some changes. And within a, uh, relatively short amount of time he confided in me that he had a very serious mental illness and that was really causing him a lot of angst. And of course it was not his fault. It was something that he also had to deal with and uh, and that helped a lot. So that that technique of, of publicly praise and privately help goes a long way in any difficult situation.

Speaker A: And that's very true. So building trust is important and all those things. Now you are in agile space for a while. So uh, if you look back to your journey, what was your biggest aha moment?

Speaker B: I think at how fast something can move, you know, because I came from a waterfall environment and I did a lot of federal Government work. And of course the projects go really quite slow in the federal government because there's so many considerations and so many stakeholders. Sometimes we had 50 stakeholders that we had to address all of their needs. So it was very complex and there's a lot of security and this kind of thing. And I think that when we moved into agile and we started using user stories and we started having, uh, very, very quick turnarounds and sprints, and I think that it caused a different interview style for me because you also need to adjust your interview style to be more agile, to be more quick, to be more nimble and be able to, instead of maybe a waterfall kind of interview is coming with a long list of questions that are predef and you are asking the interviewee these questions and that's what you've made up your mind, these are the questions that you're asking. But in a more agile approach, you need to be very in tune with your user and based on their response. I mean, it's almost like physics. You know, every action will get, get a reaction. You need to be on your toes and based on what they say, you need to be nimble enough to be able to change your approach. And I, uh, I think that's the biggest thing that I saw in terms of my role of a requirements engineer.

Speaker A: Very interesting, Very interesting. So, um, if you now look into the future, what do you think is coming? Your space? What's the future in Agile space?

Speaker B: Agile space in the future. Leaner, meaner, AI faster. I mean, there's so much coming, uh, I think, and with AI and being able to leverage requirements and not only, you know, kind of going into the archives and leveraging what's there, but leveraging them and shaping them to that particular audience. I mean, we used to have a lot of legwork involved in developing questions and requirements for users, but now, uh, you know, in leveraging these AI tools, um, putting in the parameters of the project, the type of project, the industry, the names of the, not the names of the stakeholders, but the, the names of their roles and titles and their interest. And you will get the questions created for you, um, you know, which are very, you know, they're starter questions, but there's just so, it's so exciting, all of this technology and the blend of technology and human psychology and interviewing. It's exciting seeing what the future look,

Speaker A: it is exciting. Um, surprised, pretty much, uh, every day with some new things and uh, you need to accommodate for all of those changes. Well, um, it's time to invite our listeners to Agile Prague conference. So it's going to be in September 1516 in Prague, Czech Republic, and Pamela's gonna have a talk with us. So can you tell us what's the one thing why people should attend your talk?

Speaker B: My talk is about how to make stakeholders talk. And as we know, requirements are the number one reason that projects fail. The number one reason? There's lots of factors. It could be management, it could be budget. There's lots of factors. But poor requirements are the number one reason that projects fail. And what is that based on? It's based on elicitation. It's based on did we get the information from stakeholders that we wanted to, that we needed. So this talk, how to make your stakeholders talk, is all about getting and pulling information out of our stakeholders, helping them, the ones who don't talk, or the ones who don't talk too much or don't give enough detailed information. It's all about getting information that you need to create great requirements.

Speaker A: Thank you very much and I'm looking forward to see you in Prague in September.

Speaker B: Thank you very much for having me.

Speaker A: Thanks for listening to this episode of the Agile Way podcast hosted by Zuzi Shakova, um, author of the Great Scrum Master Book and Agile Leader Book. If you love listening to this podcast, ah, please leave us a review. If there is any topic you are particularly interested in and would like to hear another episode on it, let me know. For more information about me and my agile classes, Visit our website Sohova.com S O uh, C H-O-A.com thank you for listening.