Blab: What are the most common Agile adoption problems?

When an organisation or team goes through Agile adoption in a half-hearted manner then they do not normally deliver the results that we'd expect to see in well functioning Agile development teams. We look at common Agile adoption problems in this post and recorded Blab.

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? (covered in this post)
• 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 second question 'What are the most common Agile adoption problems?'. Watch our discussion on this question in the above ~ 10 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

Ray: "What are the most common Agile adoption problems?" I think we've covered a couple of already, around just implementing some practices and playing lip service to the ceremonies and so on. I guess, in my view, one of the things we've discussed around half-hearted adoption, the most common thing is, for me, the lack of attention to those values and principles.

Nick: Sure.

Ray: The approach of just taking the Scrum guide, for example, and implementing as writ, well, as much as possible within their organisational context, which often means that therein lies some of the first problems, but it doesn't particularly talk to the values and the reasons and the why you're going about doing this in the first place. Then the kind of missing, the big problems there are missing all of those key reasons.

Rowan: Yeah, some of those values and principles, the implications of them, you know, actually take quite a bit of insight and quite a bit of even time for a lot of people to really grasp.

Nick: Yeah.

Rowan: One thing I say in Scrum training is when you start out with an Agile adoption, you know how many people involved, unless you're very lucky to have some very experienced coaches or the people from perhaps a previous adoption, are deep experts in lean product development or empirical process control of the dynamics of really good self-organizing teams and things this? That stuff is often a very different ballgame for the people involved. I guess the fantastic thing about Scrum at one level is that it’s a simple framework that if you actually take that leap of believing that these rules are there for a reason and believing that actually it does work and it has worked for thousands of other organisations if you actually implement it properly as a system where you have all those components that actually interrelate and help each other to be effective, then actually it does work.

Nick: A like the words you used there, you said the word “leap.” You are almost talking about a leap of faith, aren’t you? To trust in that framework, that Scrum framework to actually do, that there's a reason for it being there.

Rowan: Yeah.

Ray: There's an awful lot of evidence to back it up though, to be fair. It's a leap with an awful lot of theory, evidence, and support.

Rowan: What I see, going wrong in quite a lot of organisations who perhaps don't embrace a particular existing framework so seriously and then sort of saying, “We're not really a Scrum place or a Kanban place, we're more of just wanting to be Agile or do Agile”, especially when they phrase that way - it's kind of like often the attitude that we can cherry-pick the bits and pieces that we feel in the… I guess not ever trying it, haven’t tried it before, that we think are the right ones for us to adopt.

Nick: That's a good point, Rowan. The point you're making there about the fact that while we're talking about what are some of these bad adoption practices is trying to customise Scrum from day one. Saying you're going to adopt it, not getting good at the basics before you actually start making a hybrid out of it and not really understanding the as is before you change it.

Rowan: Yeah, and how will you ever know whether what you custom invented is any, if it's as good as what basic Scrum would have been if you actually adopted it properly. It might actually be a whole lot worse and you never realized that you could have done better if you'd actually just taken the basics and started with that.

Nick: So going back to your point, Ray, yes, Scrum has lots of proof that ways behind it, is that one of the failings of when organisations or companies are trying to adopt Scrum and they find it difficult to take that leap of faith, they're not going in doing the research to make sure that there's good reasons for doing it out of the box, there's good reasons for going this way. They're not going and looking at that back-up research to say, "This is a good thing to do?"

Ray: I think there’s certainly an element of that, I think, but also, this is not a logical change. It requires an emotional buy-in to make those cultural changes and those changes and beliefs. You can present as much logic as you like and as much proof as you like, but there comes a point where actually, it's what we've been talking about earlier, it's a bit of a leap of faith, and you just have to trust, and that requires an emotional component to that buy-in that you’re not going to get by reading what are the various supporting articles if the company next door that happened to be exactly identical to yours, being successful at it. Yeah, I think you're right. There are a lot of people that don't particular look at the evidence. They just say, "Oh, this Agile thing is new. It's working for loads of other people, I've heard, so yeah, just give it a go," without necessarily digging into it.

Talking to your point, Rowan, earlier about plenty of companies, the lead developer has read about this Agile thing and he's now pioneering the change of the organisation and there's no coaching capacity or capability of understanding to be able to lead that.

Nick: Oh, yeah. I once worked with an organisation, exactly that scenario, and he told me that there's absolutely no possible way we're having business analysts or people with business analysis skills in the Agile team because having a BA…

Ray: Oh, absolutely not, Scrum doesn't say BAs.

Nick: No. He actually told me that having a BA in the Agile team was an Agile anti-pattern. I said, "Really? Okay. Where have you read that?"

Ray: Well, he's a developer, right? So...

Rowan: Yeah. A lot still misunderstand that too. The developer word really means product developer. Anyone that contribute to the development of the products in any skill.

Nick: We’ve gone around, circle back to people who've misunderstood the values.

Rowan: Yeah, so I guess what I've seen with…maybe let's talk about the successful adoptions and then compare.

Nick: Doom and gloom.

Rowan: The characteristic of the ones I've seen succeed is really a person in a position of significant authority, I guess, over the group who are doing the adoption in the existing, perhaps hierarchy of existing org structure, who is perhaps not just heard it's a buzz word or heard about these things or read about it and intellectually, perhaps, he’s got it at that level, but actually experience the bit of it, has actually had an experience that has actually changed their beliefs to the extent that they actually believe in it, and that they've brought into it to the level that they're not just saying "I support it" but they're actually rolling up their sleeves and actually putting work into enable that change and to lead that change and to bring other people into it and to help them through their difficulties with it and all that sort of thing. Those sort of people, some of them are senior programming, management level or software development manager or CTO or CIO, even better if it's initially coming from the business really and someone in the business is actually clued into, "Okay, this is a great proposition for the business that we really work with the IT guys to really make this a partnership."

Ray: it does ironically... Agile and the Scrum guide and also some of the things to talk about business value quite a lot and how obviously we're trying to prioritising everything around business value. And ironically, so many times these Agile adoptions are not driven from a business standpoint at all. It is a lead developer or a technical person or a development manager or even the CIO, but fundamentally, if there's no business driver, there's one more question what the end result is going to be.

Rowan: Yeah, so yeah, do need to have that as well. I probably should say, the ones that I've seen being more successful have had that belief from the business that there's a better way and that this kind of engagement in by the business ongoing, not just at the start, creating an internal contract with IT and walking away and saying, "Now it's IT's responsibility." Actually taking on that responsibility to steer it interactively, and really provide feedback…

Nick: That's definitely one of the question being the most common adoption problem certainly backing you up there, Rowan, is let's say they did the business were involved early on and they assigned a product owner to the project, but that product owner was not available, highly available during the week. Maybe they're only available once a week for two-hour period. I've seen that in organisations where that is something that is going to be a bit of a barrier to an Agile adoption. Same as things like "Yes, we all work for the same company and we're on the same building, but we're all on different floors. We haven't bothered to actually take co-location to heart, because we haven't really understood how valuable high bandwidth communication with our teammates is." Those are just two, I can think off of top of my head, that will be barriers to adopting Agile.

Keep an eye out for our next question in this series What benefits can you see from fantastic Agile adoption?