Essential Skills Every Agile Consultant Needs: Mastering Domain Knowledge, Active Listening, and Honest Communication

So what are three top tips for a new agile consultant?

Um, so I think the first thing is understand the domain within which you’re working. If you’re going to be consulting on a particular topic, um, like for example going into an organization that builds some kind of software product and helping them shorten the feedback loop and get better at delivering that product, then you want to understand what it takes to build products. You want to have a keen understanding of the context within which the teams, the people that are doing the work, are operating because it’s the people that are doing the work that are actually moving the business forward.

Um, they’re directed by—directed, that’s probably too strong a word—um, well it might be depending on your level of control, but they’re directed by above, like what direction are we going, what’s our goals, what’s our objectives. But, um, they need to um be intrinsically understanding of that context. That’s the first one: understand the context of the people that are doing the work.

Um, what would be a second thing? Listen. Probably a very powerful skill is listening to what the people that are doing the work are saying and how that what differs or relates to what leadership is saying and what customers are saying. I often do um interviews across all levels of the organization when I start working with a team or with a company to really get an understanding of what it is that’s going on. And it’s incredible the different stories that are told from the same perspective from people at those different levels.

I remember an organization where the leadership was like, “Yeah, we’re awesome, we do continuous delivery, we test everything, we’ve got automation, we’re brilliant.” Um, and the people doing the work were like, “Oh my goodness me, we’ve got no automation, life sucks, we’re doing everything manually, it’s a struggle every day to get out of bed and go work on this big pile of crap that we’re delivering.”

Um, and that fragmentation was through a lack of transparency, right? And even I spoke to some customers for that team. They managed to get a couple of customers, and they weren’t external, they were internal customers to the organization, but they were like, “Yeah, you know, we don’t tell them about every problem that we have, we actually keep a separate list of problems because we as the customer see the engineering teams as totally overloaded and running around like with their hair on fire. So we feed them things that we think of as important,” right? They’re creating a separate backlog of work and prioritising it as the customer because they see the struggle that the engineering teams are under. Yet leadership is like, “Everything’s awesome and we’re great,” right?

So that, that, that—listening to people, talking to them, finding out what’s actually going on at different levels because everybody’s story is different, um, and at every level in the organization. And if you get that difference in story, you know there’s a fundamental problem with transparency. So that’s perhaps your first focus for organisational change and organisational shift.

And now I’ve got to come up with a third one. See, you need to be able to articulate what people don’t want to hear.

So, I remember before I was able to do that, I went into an organization that had just gone through a massive reorganisation, restructure, um, in order to try and achieve agility. And they’d ended up with a test silo and an engineering silo and an operations silo, right? Same old crap.

And I was sitting in with the CEO and he turned to me and said, “Do I need to pick this apart and do another big reorg?” And I was afraid to say, “Yes, what you’ve done is wrong. It is not going to achieve the outcome that you want to achieve, and you’re gonna need to redo it with an eye to cross-functional vertical slices, value stream,” right? Focus on those things.

And I was afraid to say that because I was a lowly, uh, wet behind the ears DevOps consultant back in the day, um, and this was sitting in with the CEO of a large multinational company, and I felt I couldn’t tell him he was wrong.

Um, I’ve since learned, and in fact that, that story is one of my catalysts for, um, just saying to people when you think something’s wrong, they can always disagree with you, they can always not like you. Um, but you need to, you need to say, if something’s not right and you’re a consultant, you’re hired because you have more information, right? You’ve got more insight. Uh, you’re hired for your expert opinion. Give it, um, even if they’re not gonna like what you’re gonna say.

So that was three things.

Thanks for watching the video. If you enjoyed it, please like, follow, and subscribe. I always reply to comments, and if you want to have a chat about this or anything else agile, scrum, or DevOps, then please book a coffee with me through Naked Agility.