Getting Great Agile People

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale. Hello and welcome to the next episode of Definitely Maybe Agile. And uh today we've got uh an extra special session with a guest star from Nada Buhendi. And we're going to be talking about getting great agile people. I'm quite looking forward to this. Uh and of course, you've got Dave here as well. And uh so let's get it started. Uh so Nada, would you like to introduce yourself and uh get us started?

Sure. My name is Nada Buhendi. I'm an agile and technical career coach, and I love helping people land jobs that they're absolutely passionate about. And I've had over 15 years of experience uh working in consulting and different agile roles, uh, whether it's through Deloitte, Accenture, and Slalom, and super happy to be here.

Awesome. We're happy to have you.

Yeah, it's great. It's so um it's interesting as you're just describing that because immediately that you start describing that, I'm just thinking of all the conversations I've had in organizations about the role of the scrum master or the role of the product owner. And I'm just intrigued from a like you do this for a living versus Peter and I that we do talk about scrum masters and product owners, but there's normally other context in there. What are organizations looking for? What do you see?

That is very interesting that you bring that up. And uh when I'm helping people, it's mostly through the job seekers' perspective. And this is a puzzle that we're constantly, constantly solving. As I've looked over 3,000 job postings in the past year, and I struggle to sometimes understand truly what it is, the business problem that an organization is trying to solve when they hire people. Because I tend to see laundry lists of uh skills that they list rather than really trying to articulate what is the bleeding neck problem that they're trying to solve. And instead they get into the how and list all the skills instead of focusing on the what.

Can you give us some examples of some of the worst ones of those that you've seen?

Yeah. Oh my goodness. Well, you know, when we look at scrum master roles, for example, that talk about how they're looking for someone to create reports and to do stand-ups and all kinds of things. And in my head, I'm thinking, well, first of all, you know, this kind of conflicts with with you know a Scrum Master role. And second of all, do you is it really that you need someone who will hold stand-ups for you and create reports instead of maybe articulating that you want someone that's going to increase your team cohesiveness, right?

Yeah, so so that's uh I I always struggle with it. And it we'll we'll talk about product owners in a in a moment, but the more and more nowadays you see the agile project manager role, where agile is kind of thrown into a traditional project manager job description. Um most recently I've seen a wonderful one where they just added one bullet that said uh responsible for the happiness of the team added into a project management description. And and of course, this is this is so frustrating, not least because if you're that team, that's not really the way it's going to work. But also we're setting somebody up with expectations which are wrong, right? They're walking in and they're honestly they're confused or conflicted because there's clearly an organizational requirement for visibility and transparency into what's going on for some sort of project management piece, but then there's also this we've got to play some sort of checkbox side on the agile scrum master part. How do you what do you see changing there? Or or how do you kind of address that?

How we address that is you know, there are tells when it comes to looking for a fit from an organizational perspective. I tell my job seekers to do some research on the organization. There is that reality that job postings, the way they're written sometimes, is they're written in a rush, they're copy and pasted, and not a lot of thought is put into it. So I tell my um, you know, uh mentees to instead rely on organic conversations with organizations, talk to people who work there, um, go to company events, look at their website, look at their case studies to really understand things better. Um, however, it's really a combination of my experience in the field that I fall back into in terms of what I've personally done. Conversations that I constantly have with hiring managers in different organizations to get a gist of that. Um, but there are sometimes ways that you can tell that maybe this is not the right organization, just based on the vibe that you get from the way the job posting is written.

What happens once they get the job and they get inside of those organizations and they find that uh it isn't quite what they expected, or or even what's if you're in the organization and you now get told, oh, you have a new job title. We're going to call you grandmaster of scrumminess and we're gonna have you look after this this group of people that we're we're gonna give some name which uh classifies them as a group who are going to work on things together. And uh and you're now gonna go off and do those things. And maybe if you're lucky, we'll uh give you some training or some coaching to go on the way. Uh what have you seen in organizations once that starts to happen in terms of investing and supporting them, people through that journey?

It's a very tough situation, right? Um, because the nature of agile and scrum master roles is that you're looked upon as a trusted advisor coming in to help the organization. And sometimes, you know, organizations are looking for that role to guide them, and they're not even sure what it is that they're looking for. So it's a bit tricky in that sense. So the way I coach my clients is to take on more of an entrepreneurial stance when they go in, um, do their own research in terms of, you know, um improving their coaching skills, improving their knowledge, you know, just like a doctor. You know, a patient goes to a doctor with a problem, and they're expecting the doctor to figure out how to fix it. The patient doesn't tell the doctor what tools they need to use. So I coach my clients to be proactive. And you never know what to expect when you go into an organization, you never know what problems that it that you're gonna face. Um, so you have to be ready to be flexible and to and to approach it in a very agile way.

I I really like the the way you're putting that, just because as as you're describing that, what I'm thinking is um agile roles that are different to the traditional roles that organizations have sought in the past. There's there's a lot of autonomy around whether it's a self-organizing team and how they deal with things, or whether it's a scrum master or coach or or a product owner, all of these different roles, DevOps roles, all of this. They're they're titles that barely scratch the surface of what we're really trying to do. In an organization, you're trying to get problem solving becoming a part of the DNA in many cases. I mean, that's a one way of thinking of agility. And so you can't go on titles and job descriptions. That's the beginning of the conversation rather than a box to be filled. Um so I really I mean that entrepreneurial spirit, the the the kind of view of how to how to go in and identify and solve problems rather than worrying too much about titles and job descriptions. Um but perhaps recognizing, of course, there are many organizations that live and breathe the titles, job descriptions, roles and responsibilities piece. I mean it's needed to sort of understand context, but we uh maybe have to go beyond that. I I kind of like that idea.

Yeah, we see this uh piece. We were talking about that in the the run-up when we were discussing what we would talk about today, around the how do you support people in those roles and their growth and their growth in the organization. Um, if you're not treating them inside of that normal hierarchy, then what are the right ways to go about ensuring that you're investing in the growth of your employees and supporting them through the the journey and ensuring that they have opportunities to learn and grow and uh improve in their in their chosen field or career?

Now, we've not talked about product ownership because we you know there's a there's that scrum master project management piece, but product owners are I almost the most it has to be one of the most frustrating roles in larger organizations. If I have a single team and I'm the product owner and I'm working on a single product, that one's kind of straightforward. But what have you seen some of the challenges of understanding product management or product ownership and how to build careers in that area?

Yeah, um, product owners, I tend to say are the closest to entrepreneurs, and they tend to have a high need for freedom when they come into organizations. So when you are putting them in a box, that really, really makes it frustrating for them. Um, they definitely do not like to be micromanaged. Um, I had a little story with one of my clients who said to me that he was working at a large financial institution. He was extremely joyful in his role of being a product owner. He loved the ability to make decisions. Um and he ended up leaving the entire profession to become an agile coach, which wasn't really something that you know aligned with him just because he was micromanaged and he was put in a box. So really giving people the space, you know, to make decisions, giving them some freedom, not putting them in a box, allowing them to solve problems in a way that makes sense, um, and focusing more on being clear about what the problem it is that you're trying to solve rather than the how. That's what would make things successful. Um, so in terms of challenges, I would say is um yeah, going into solutioning mode. If we go into the you know micro level of agility, right, when we're building a product, we often say that your user stories shouldn't be prescriptive. That's one of the most fundamental things that we talk about. Because if you do that, you're limiting um developers' creativity. So imagine someone who's a product manager, who's more of a leader, who's more of an entrepreneur, trying to build a product, trying to figure out the direction of the product. If you are fitting them in a box and you're telling them exactly how to do their job, what skills, what tools, and going into that granular level, then that's going to be extremely challenging for them. So I think one of the biggest things really is the trust as well, and finding people who um fit into the organizational culture.

That's a nice transition into uh the whole uh shift in mindset that comes as you start to look at these changes in roles and how uh the organizational uh way of looking at uh agile and at roles and progression and growth needs to change. Uh so what have you seen in that space? How organizations uh uh how organizations' mindset needs to change, what sort of things have to occur, and what sort of indicators do you see in organizations?

Yeah, there's a lot of talk right now around, and what I'm seeing is work-life balance and how work needs to be separate from you know our personal life. Um I but I see also like on LinkedIn, I even see that is there's a lot of personal stuff that's starting to appear as our lives are starting to blend because of COVID, and there's a lack of separation between work and life. And my opinion when it comes to that is I actually do take work personally. Um, I think that um in, you know, when we look at our lives, there are multiple pillars. There's, you know, our finance, financial health, our physical health, um, our personal lives, and our work. And if we invest too much time into any of these, you know, pillars, there is imbalance and there's codependency. So in any relationship, I feel there needs to be balance. Um, and we don't need to go into one extreme where we're saying that we need to completely separate our lives from our work, but there also needs to be an understanding that our professional life is our is part of our identity. So when I look at organizations, I think of them as mini-societies that are being created. And if you want to have a successful, healthy society, you need to invest in your core, the molecules that form that society, which is your employees, right? So their need organizations need to take interest in the um professional identity of their employees, their desires, their needs, and their wants, in order for them to meet their organizational objectives.

I I find it interesting what you're saying there, Nada, because um I think Agile and Scrum, Scrum is probably the primary kind of role-defining framework out there, but there are obviously many. But what's interesting there is they have a tendency of flattening hierarchies and saying, for example, if you're um a product manager or a business analyst or whatever, you know, this, that, and the other, if you're in the product ownership role, you're a product owner, squashing out that side. If you're a developer or a QA um quality assurance engineer or um an architect, when you're on the developer team, you're a developer. So we're squashing out those titles and those hierarchies and so on. And what you're just saying, that the interesting thing is that's exactly what we shouldn't be doing. Now, I want to treat the development team as a group of peers, for sure, but there are people in that group, for example, who have many, many years' experience and are senior in whatever that role is that they do, and they need to have a career growth and a recognition of where that is, both within the organization as a senior member of a team, perhaps, even though that is a team of peers on the developer's side, or uh in the real world, back out, because if they, for whatever reason, move on, they need to be able to slot into the different career paths that are elsewhere. And I think that one's a really interesting one because I've I've been in an organization I remember recently where people were leaving Scrum agile teams because they couldn't see where their career was going to go. They they actually enjoyed being there, they got a lot out of the kind of problem-solving side and so on. But when they came out, like ultimately, as they looked ahead, they couldn't see what their career path was going to be. Peter, I don't know if you've seen similar things or have a different perspective.

I I've seen similar things, and uh having been in a an organization where there's this idea that we can uh remove everybody's titles and we're everybody's the same and we're gonna that which comes into this. It's uh it's almost this at that point, then what is my growth path? Am I now just part of Borg? Am I just now like uh another part of this creature without my own individual identity? And I think this perhaps ties back to what Nado's saying there around acknowledging the individual identities and ensuring that you're providing those opportunities for people to be able to um see how their role and their growth will come from this, so there's value on both sides, so both the organization and the individuals are like benefiting from this. Um, I we're we're unfortunately running out of time, but I think we could talk about this for a very long time. And I was kind of wanting to think of the the uh going up higher up in the organization and uh how this affects leaders and the change in mindset, and so perhaps we need to uh have a follow-on conversation at some point. Uh, but uh as we as we start to wrap this up, I was wondering, are there any particular references that uh that you would provide to say, hey, go read this or look here for more information about this topic?

Yeah, what I'll say is I think we need to understand that um you know, people in organizations, people in teams, it's all they're all relationships. And with any relationship, right, you have two individuals, multiple individuals, working towards a common goal. Because if you don't have that common goal, um, if if me and let's say a romantic partner do not have a shared goal, right, it's not gonna work out. We have to be invested in that goal. But at the same time, that does that does not mean that we need to um not have our own individual identities and personalities. So that's a tricky part. And if those things are you know in balance, then people are happy. And it's also okay for people's goals to change, you know, there's a lot of stigma around people, you know, leaving organizations. And just like in a relationship, sometimes people's circumstances, goals, dreams evolve. And it's okay to end these relationships. So that's you know my sort of end note on that.

So so Dave, uh, do you have any particular references, anywhere that you would have people go look for more information about this kind of thing?

That's a good question. Because I don't I can't think of a book that I would dive into and look at. What what I was struck is I think there's some really interesting points that we're touching on around like understanding roles and role clarity, understanding like the purpose. And I thought Nada's point to break away from looking at detailed roles and responsibility descriptions, which are valuable. I mean, we want to see something there to give some idea, but to really understand the problem that a role is trying to solve and what that sits in fits really well. Um I also just in the last part of the conversation, I just wanted to pick out, because I think this is something we see a lot as well, is the or we should see a lot more of, and isn't there, is that support for individual career development. I thought Nada's point about two things struck me. One is we better look after that personal career development. And and I've just begun having conversations like that in organizations where that's on the table as part of a transformation initiative, which quite frankly was just not there before. Um but then this the second thing is recognizing that that career development might mean somebody leaves the organization and that might be the right thing to do, and how how that goes through. I thought that was an interesting point that you brought up.

Yeah, sometimes it might just be the right thing to uh to part ways and uh and go in a different direction. And uh yeah. Uh I I think uh as we as we wrap this up, I think some of the places that I've seen the most interesting information on these kind of things is around uh Google's Project Aristotle and the rework space. And and uh the there's a book by Lazar Bloch, who was the people operations leader for uh Google for a while, called Work Rules, that uh I I enjoyed reading it. It had a lot of very interesting information about uh growing organizational culture as the organization scales, and a lot of the things that they discovered as they started to uh look at um look at work in a different way, which was uh I thought quite interesting. Um so so if we if we sum this up in three things, I think we've gone to a journey here on our uh getting great agile people. We've talked about role clarity, um, something some about investing and supporting uh and and something some stuff around the mindset the organization needs to develop. Uh so uh what would your your last closing statement be, Nada?

I would say is sometimes we overcomplicate things and and we don't model things into what goes on in real life, like true relationships and um, you know, and the other part that I wanted to say is I totally would recommend. Um, I have an interview on my YouTube channel with um an amazing guy called Tim Clark. Um, he was a professor of entrepreneurship, and I totally recommend the book Personal Business Model You, in terms of how to model your career just like a business. I think that would be an interesting um book to read for sure.

Awesome. And Dave? I'm not adding anything more. What I wanted to say, I think this has just been a great uh conversation across uh touching a number of different topics. So uh what I will say is as always, there's a bunch of notes uh with the references that have been mentioned. You'll also find out a little bit about Nada and what she's up to. In that, I highly recommend you check that out again. Uh, thank you, Nada, for joining us. It's been a great conversation, Peter. Good to talk to you again, and uh we'll talk soon.

Awesome. And if anybody wants to reach out and contact us, we're at uh feedback at uh definitymabyagile.com and that'll be in the show notes too. And uh thank you all for listening. You've been listening to Definitely Maybe Agile, the podcast where your hosts Peter Maddison and Dave Sharrock focus on the art and science of digital, agile, and DevOps at scale, and we can do it.