Blab: What benefits can you see from fantastic Agile adoption?

At Equinox IT we often get to see many of the problems that organisations and teams face when they take a half-hearted approach to Agile adoption. Luckily, when Agile adoption is done well there can be many benefits and so in this post and recorded Blab we address the question 'what benefits can you see from fantastic Agile adoption?'.

Blab topic: The big benefits that most organisations are missing when they do half-hearted Agile adoptions

We recently ran a Blab session (find out more about Blab) discussing half-hearted Agile adoption, where we worked through these questions:

• What does a half-hearted Agile adoption mean?
• What are the most common Agile adoption problems?
• What benefits can you see from fantastic Agile adoption?
• What are the biggest things you need to focus on during Agile adoption?

This post covers the third question 'What benefits can you see from fantastic Agile adoption?'. Watch our discussion on this question in the above ~ 14 minute recorded Blab. There is also a transcript of the discussion below. The last question will be covered in a future post.

Blab presenters

Our presenters during the Blab presentation were:

• Apple headphones: Rowan Bunning, Certified Scrum Trainer, Scrum WithStyle, Sydney, Australia (Equinox IT training partner for Certified ScrumMaster and Certified Scrum Product Owner training).
• Glasses: Nick Foard, Principal Consultant, Equinox IT Auckland office, New Zealand
• Suit jacket: Ray Cooke (me), Lean & Agile Business Transformation Coach, Equinox IT Wellington office, New Zealand.

Transcript of conversation

Ray: What benefits could we see from a fantastic Agile adoption?

Rowan: I think one thing that ties both of these to get a little bit for me is having an actual clear goal as to what we're trying to achieve with an Agile adoption is something really, I think, necessary for successful adoption.

I did a talk at the London Scrum Gathering in 2007 it was. It's been quite a while now. I just noticed on SlideShare that is seems to be the most popular slide deck I've actually done. The first anti-pattern I talk about, because the whole title of it was "Kicking ScrumBut". The first anti-patent I talked about were 'goalless, soulless Scrum', you know, not really having a goal in terms of what performance characteristics or what outcome you're trying to achieve through Agile adoption.

I think there's too many organisations, I'd say, have a very superficial -- either superficial view like 'cheaper, faster', or when you go and talk to them, and this is the first questions I ask as a coach or consultant coming in, "Why are you doing this? Do we have any awareness or desire of why it is we're embarking on this sort of change?" In some organisations it seems to be a very mixed set of ideas that aren't particularly coherent or there’s no really clear messaging that people can kind of unify around and sort of see how we’re progressing towards achieving certain characteristics. I think it’s a really powerful question to think about "what is it we're trying to optimise in our organisation?

Nick: How many times do you get the answer, "What we're doing right now doesn't work, we've heard this other way is faster, so we're going to try this now?"

Rowan: Yeah, that's a classic, isn't it? Faster. But I think it’s a good place to start the conversation in terms of the awareness and desire, places of change around what are our pain points. What have we experienced in recent projects and recent relationships with the business and various things that we think could be improved? 9 times out of 10, those things, funnily enough, win the Agile / Lean, you know, community, we've actually got some good ways forward on those things.

Ray: I think a lot of especially large organisations generally have value statements and mission statements that actually can quite often help with this discussion. For example, organisations that have values listed like or most conveniently 'agility', but if it's not that then 'efficiency' or 'customer focus' or a number of these values, actually they are great drivers and good reasons for doing this over what their existing structures and processes propose or encourage.

And I think, as you were saying the other day Rowan, about Craig Larman talking about optimising organisations as a whole and asking the senior management what is it they're actually trying to achieve with Agile adoptions and trying to then align or looking at their existing organisational structures and saying, "Well, okay, these are the processes you've got and the strategy you've got in place, yet these are the values you're espousing as an organisation and the two don't line up." What is it that we can do to correct that? And many of those will quite likely to find that the various the Agile principles align and therefore we can drive Agile adoption from there.

Nick: It's worth mentioning that because I've worked with that alignment to missions and visions for a long time, you know pre-Agile, that it's still possible to get a successful Agile adoption at a software project delivery level and still not have alignment to your missions and values. It's still something that the business needs to manage as part of just being a business. It's possible to have these fantastically run Agile software delivery projects that still are not delivering against where you said, as an organisation at that executive summary level, where you said you wanted to be or where you said you wanted to go. I’m just trying to paint the pictures that, again, Agile is not that silver bullet.

Ray: Yeah it depends what you're trying to marry it up to, I suppose, if the value you're trying to espouse as an organisation is cost saving or I don't know bad example perhaps. Although, the thing is I don't actually believe that there's going to be many value statements from organisations that have them that don't align to Agile principles. I mean fundamentally, they're all about efficiency and customer focus and value for the organisation and for the employees and for the customers. There’s not going to be many successful businesses that don't have those.

Nick: The problem, the misalignment, is where you have, "Yes, we want to focus on customer needs." Then at project delivery the name of the project or the goal of the project isn't actually customer delivery focused or it's not customer focused.

Ray: So a misalignment in what they're trying to achieve from a project.

Nick: Yeah.

Ray: Or what projects they're coming up with versus their goals...

Nick: The project is run in an Agile way successfully, but the goal of the project isn't aligned to what the mission said that we're going to try to achieve. I see that a lot.

Ray: They're doing the wrong projects, fundamentally.

Nick: Yeah, they're doing the wrong projects, yes.

Rowan: Yeah, I think you can have two different sets of worlds and two different sort of optimisation focuses between the project level "just get this project delivered" versus at an organisational level "where do we want to be a year from now, two years from now, three years from now in terms of the performance characteristics of our overall delivery of new initiatives?". That's a whole different ballgame, and that's I think where some Agile adoptions don't even get to that conversation or to that bigger picture than just this one project and then on to the next project, and no one’s really kind of taken that to the bigger picture of whole of org consideration of how can we kind of build this to make the whole thing flow, a whole lot better, end to end, and build that relationship.

Ray: That's quite hard to achieve because that’s effectively a local optimisation as over the optimization of the organisation as a whole. And it's very difficult to achieve that, I believe, especially when you got organisations where the business itself is hierarchical, and you've got independent business units that have their own goals and their own managers and their own reasons. They're not necessarily all communicating with each other and coming up with that shared pipeline of work.

Nick: To answer the question actually, which was one of the benefits of a fantastic Agile adoption, we've kind of been talking about this separation that's occurred, misalignment, because the business is so separate from IT and these guys down here have tried Agile, but these guys are... . When we try to have that Agile adoption that starts to bring positive customer engagement where the business and IT actually start to work more closely together, that starts to build that bridge between the two, and then those conversations about the strategic alignment can really start to gain momentum, and the business can start to understand, "Oh, hang in a minute. I think we're doing the wrong projects" where previously they weren’t talking, because they weren't doing that positive stakeholder engagement. For me, my favourite benefit from Agile is that stakeholder engagement -- seeing the stakeholder on a regular basis and getting that interactive feedback from them and seeing the smiles on their faces when "wait a minute, here's some software". I don't usually see software for six to nine months.

Rowan: Yeah, and getting the virtuous cycle going, isn't it? We're reinforcing a loop in the right direction, and I think a lot of this sort of area are we getting beyond the one project or the local optimisations is really that space that systems thinking is really there to help us with.

I was just having a conversation at the end of the course yesterday where there's a disconnect really in the kind of experience that people are having within delivery teams, with the executives who had a belief that they could push more and more stuff down the pipe, even though these teams already had more than enough, and basically change direction in any moment in time, even though they hadn't finished up what they were working on and things and...

Nick: Are you talking about and the word “no”? Are you talking about the bad "no" word?

Rowan: Yeah, there’s that. And there’s just different mental models going on with people in the organisation, right. We're not all on the same page about how this system called the organisation actually functions when these things occur. Doing things like cause and effect diagramming and really kind of talking at it, talking through it, and really see if we can come to the same understanding of what's going on currently in the organisation can be a great place for figuring out are we in a vicious cycle here? Are we pushing more stuff into teams and therefore teams have more defects, and you know that it adds more pressure to them, and it's just reinforcing loop and because there's been a bad relationship between business and development, then there's more pressure on the CIO, and the CIO puts more pressure on the teams, and the teams get bogged down and then they get back to reinforcing that whole thing again.

Nick: But you said this Agile thing was going to be better?

Rowan: Yeah and I think that expectations thing is really important too, isn't it, that this is not a silver bullet, like we're saying, but there are ways to actually get the organisation functioning better, but you do need to understand how the organisation actually functions before you mess things up.

Nick: Ray, what's your favourite benefit?

Ray: My favourite benefit?

Nick: Yeah, what's the one you like to see?

Ray: I like an ecstatic customer. I like somebody that comes back to the organisation and goes “This is brilliant. This is exactly what I wanted", get some positive feedback. Even if actually even if the feedback is "great, I'd like to see this as well.”

Nick: That's even better feedback, though, isn’t it?

Ray: Yeah, absolutely.

Nick: Because then they’ve learned something.

Ray: Yeah, and to that point, it feels like the system is growing. It's not just the system in the organisation, it's the system including the customers and the customers are also helping optimise the organisation as a whole, around them, which is what we're trying to achieve in the first place. Yeah, I guess the number one benefit for me is a happy public, so yeah.

Nick: What about trust? I come up against trust a lot in the organisations that I work with, with this mistrust, because of existing 'as is' business process. And when we start to implement an Agile transformation, we start to see the collaboration between not just the business and the IT, but also between the team members themselves and then those other parts of the organisation such as DevOps and enterprise architects where previously there was a "Oh, we've got to work with the architects. It's a black hole. We won't see any work come out of there for weeks." But all of sudden, now that we're working with them much more closely, there's a much better relationship growing there, and they start visiting each other's areas on a much more regular basis, and they may even start going out for social drinks with them or something like that. I like to see that benefit of growing relationships.

Ray: It's the employee satisfaction and the engagement.

Nick: Yeah, absolutely. I mean I think I read once, as people we feel most happiness when we feel like we're in charge of our lives and directly related to the amount of human contact we've had during the day. The more people you have in contact with you and you have an interaction with, the better you feel. I think I see that a lot when I observe Agile teams when I'm coaching. I see the high level of interaction versus the non-Agile part of the organisation that is still just emailing the person who sits opposite them.

Ray: Yeah.

Rowan: Yeah, and they're connecting people more directly. So when you're talking about delighting the customer, creating an ecstatic customer, right, it really helps if the teams creating the value, creating the product for the customer, actually feel the sense of closeness and intimacy and can empathise with the customer and really understand what's going on in their lives when they use the product and things like that. That often requires this intermediating, including a whole lot of people and roles and processes that were in between those people doing the product development and creating the value themselves and the actual customer, because often you got all these different people doing specifications or doing customer support or the account management or whatever it is in between, and the developers haven’t actually met anyone who actually uses the product or comes in as close as they could.

Ray: Yeah.

Rowan: Yeah, you put more love into it, right, if you know who these people are and you care about it.

Keep an eye out for our next question in this series What are the biggest things you need to focus on during Agile adoption?.