Equinox IT Blog

Blab: What does a half-hearted Agile adoption mean?

We often encounter organisations who believe or communicate that they have adopted Agile, but many in our opinion are not demonstrating the behaviours or culture change and they are not delivering the results we'd expect to see from well functioning Agile development teams. We refer to this as half-hearted 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:

This post covers the first question 'What does a half-hearted Agile adoption mean?'. Watch our discussion on this question in the above ~ 9 minute recorded Blab. There is also a transcript of the discussion below. The other questions will be covered in future posts.

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

Nick: Okay, half-hearted Agile adoption. Okay. Where do you start? Why don't we do a scenario where somebody comes to us and they say, "Oh, yeah, yeah. We're Agile. We do stand-ups and we write user stories. We're Agile, right?"

Rowan: Yeah.

Nick: How many times have we heard that?

Rowan: Yeah, too many.

Ray: So, what makes that a half-hearted Agile adoption in then I suppose? Just because it's only a couple of practices.

Nick: Yeah, I think that's what it is. I think what's happened there is people have recognised and adopted some of the practices but what they've completely skipped over is the Agile values and the principles behind them. They're going through the ceremony. They're going through the actions but they're not really doing it in a way that is going to get that mindset change or the long term cultural change and transformation that we would usually hope to see. I suppose it's a bit like your best mate who's just passed his test teaching you to drive a car. Turn this, flip that knob, move the gear stick there but you don't really understand why you're doing it. It's just you understand that it makes the car go. You're going to make the car go in the direction but not necessarily get the benefits long-term. If anything, you could end up with worse driving habits than you should.

Rowan: Yeah, so with the practices, people can be going through the motions of standing up and talking to each other each morning without even understanding the intent of what they're trying to actually achieve through that.

Nick: Yeah.

Rowan: This is the classic of the Scrum zombie pattern. People say, "Yeah, yesterday I did some work. Today I'm going to do some work. No impediments, right?" Then at the end of it they're saying this before when people have finished the daily Scrum. It's like, "Thanks, guys. That's the daily Scrum for today" and people go "Oh, I need to talk to you about X and Y. I need to kind of coordinate what we're doing today" and I'm like "Wasn't that the whole of the daily Scrum? Why didn't we actually talk about what's meaningful to coordinate as part of the daily Scrum?"

Nick: And then what I've seen off the back of that is where people then suddenly start to not actually recognize the benefit and the stand-up because they're not getting it, so they then do something worse. They stop having the stand-up. They go, "Oh, you know we won't have one today. We'll do one on Wednesday instead."

Rowan: Yeah, so this is some of the more sort of obvious I guess things that have been more kind of...

Ray: The practice based ones.

Rowan: Practice level but I think it is a lot more deeply, deeper than that I guess to talk about and everything. Mindi tweeted something about "process change without addressing the culture" (referring to what she thinks half-hearted Agile adoption means). So I think there's a sort of practice adoption where it's kinda these practices you're often doing them within the status quo organisational structure with the existing roles and responsibilities still in play and with a whole lot of existing constraints around it. Yet it's one of the big challenges is really rethinking that that structure when we're moving into teams, we want them to be cross-functional and include the skills we need to go end-to-end to be able to do value adding features. What is value? What is it we should be producing as a team with the end of each iteration? That's just the start of it but there's a whole lot of things I think that go to management to really start thinking about the implications of the values and principles. I guess it's what it is that Nick is mentioning, right?

Ray: Yeah.

Rowan: On a whole lot of things which may have been around for many, many years. The way that people are incentivised and the way that the groups have functional groups set-up around business analysis and around testing and those sorts of things. Now, were trying to get people to operate in a cross-functional capacity and it really requires rethinking those organisational structures which you know ultimately structure has a really big influence on culture.

Nick: Well that's what they say isn't it? They say if you change the environment or the structure first, that will have the immediate biggest effect on that cultural change, and taking a point you just made about structure and how do we change the process without addressing culture, yesterday I was delivering a course and somebody raised the point that in their organisation, they have 175 projects currently in their existing process structure, 175 annual projects on the go. They already know they don't have enough resource to source those up but there is an Agile pilot that's going quite successfully right now in that organisation, but then if they want to and the staff that are working in that pilot are 100% assigned to the project but of course all the other projects in the organisation are currently working on those 175 projects.

Everybody is currently has four to five, sometimes six projects on the go for a single person. Now, try and go Agile when you got that amount of work being distributed across a low number of resources. Like you said, you got to change the structure first and that's really quite difficult to do to try and convince people that you've got to do less to finish more.

Rowan: That sounds like a line out of Large Scale Scrum (LeSS).

Nick: It does. It almost does.

Rowan: "More with LeSS" is one of the tag lines in it and it relates to a whole lot of things, more value with less, different roles and structures and bureaucracy essentially, yeah.

Ray: What we've been talking about here though is still all practices and granted some of them are significant practices like change organisational structure to fit the delivery model, but actually behind all of that is the culture we mentioned earlier and the ability to change people's mindsets and behaviours within the organisation. My experience is plenty of half-hearted Agile adoptions that I think are even if they go as far as changing, bits of structure within the organisation without introducing that culture of learning and without introducing the continuous improvement elements, the willingness to fail and to learn from those experiments and those failures.

Nick: Yeah.

Ray: You still don't get the long-term benefits that you're looking for.

Nick: Yeah, I totally agree with you Ray. I mean again going back to the values and the principles, you could adopt as many practices as you want but if you haven't dealt with the values and the principles, then you're just going through the motions. You're not really understanding why it's better to produce working software instead of lots of documentation. When I see people who attempt to try and do something about that without the core understanding, so going back to our half-hearted Agile thing again, that lack of understanding causes all these myths that I've been talking about recently about there's no documentation on Agile projects. Working software is the key, no comprehensive documentation. They take it literally and actually...

Ray: More literally. They can take it further than written actually.

Nick: There's just no documentation at all which obviously you know it's a bit of a half-hearted Agile adoption. If we focus around that half-hearted Agile adoption, that's pretty much for me that's where I see it. It's that lack of understanding or misunderstanding of what the values actually mean and how you go about actually living by those values which is the culture piece addressing the fact that to change our culture, we have to change our group behaviours, and to change those group behaviours you got to change underlying beliefs. To start off, you got to change people's beliefs at that value level to the point where they understand that working software is better than comprehensive documentation and focusing on what the client wants as opposed to a really good internal facing project management report that says how well we're doing as an organisation on project management.

Ray: Or your boss.

Nick: As opposed to the customer going, "I really love this software you just delivered." Those for me are what are driving these badly adopted Agile approaches.

Blab - What does a half-hearted Agile adoption mean?


Keep an eye out for our next question in this series What are the most common Agile adoption problems?

 

Subscribe by email