The Board Episode 43 — Agile training

By Rebecca Jones

In Episode 43 of The Board, we talk about Agile training.

Full transcript

Kirstin Donaldson: Hello and welcome to “The Board” number 43. This is the last one for this year. We’re fully committed to some training coming in December for a couple of organisations around town, so this is our last spot for the year. Thanks for joining us.

Coincidentally, today we’re talking about training.

Gavin Coughlan: Yes.

Kirstin: Nice tie-in?

Gavin: Beautiful tie-in, nice “seeg,” segue

Kirstin: Segue, yeah.

So, training. There is a tendency with Agile training and training in general for people to want a quick fix. Do you find that guys?

Gavin: Yes, yes.

Jesse Stegmann: Absolutely.

Gavin: Hello, I’m Gavin, Agile coach.

Kirstin: I think they know that.

Gavin: Absolutely, training is seen as a quick fix. I think there are certain types of training which are quick fix.

Kirstin: Such as?

Gavin: Such as…oh, gosh.

Kirstin: First aid training.

Gavin: I went to impact mapping with Jesse, and we learned the technique of impact mapping. That’s the sort of thing that you can take away use…

[crosstalk]

Kirstin: I guess that’s something that’s specific and focused, isn’t it? It’s building on the knowledge you already have.

Gavin: Yeah.

Kirstin: I think what I’m talking about is when people have no experience of Agile, and they do something like book two hours of training for their team, and then expect that that will stand them in good stead for fully implementing Agile across their project.

Gavin: Yes.

Jesse: Yeah.

Kirstin: Some of the things that we see arising from that are something you were talking about the other day, and gaining of a bit of the skill set, but having no idea what the Agile mindset?

Jesse: Yeah, absolutely, and people instead of going away and I suppose they put up a few scrum boards around the place. But, everything is still really driven and top-down. It’s turns into a small waterfall projects that happen over two weeks, rather than happening over six months.

Kirstin: That’s also the danger of only training a specific team. I think you should at least have a briefing with upper management, so that they understand what’s happening. Otherwise, people aren’t aligned on the way that things are going to happened.

You get that tension between the team trying to be self-managing and upper management still continuing to be command and control, deadline-orientated and talking about productivity and working overtime and making those deadlines.

Gavin: What we like to do is train the entire group — ideally, that’s everybody from the team level right up to the business level — and support them after training. That’s the ideal for us. We realized a lot of people can’t commit to coaching services after training, but at least get everybody in and do some serious training with them and make sure that everybody’s on the same page.

Kirstin: You’re saying people may not be able to commit too much. Are you thinking because of cost?

Gavin: A lot of people, it’s cost reasons, yes.

Kirstin: Interesting. This brings me quite quickly onto our MD’s latest blog post. He started a blog recently called NathanDonaldson.com. Catchy title. [laughs] He’s written on one about training.

Gavin: Sounds like talk leadership.

Kirstin: Yeah, yeah. That’s the deal with it.

He’s written a blog post recently about training as it relates to training new contractors. He’s given a great example of return on investment of training. A lot of people are concern about the cost of training the contractors, who are then going to leave probably within a short space of time, six months to a year, but also the time that they spend in training.

He’s done a really interesting cost example, where he’s looked at their time for spending two days in training, and then the cost of training, and given an example on a large enterprise project, for example if it $6 million. Assuming it was on time and on budget, and then training costs, 68k all up. But, as result, if you get a 10 percent increase in productivity, then that’s a saving of $600,000.

The same is true with coaching. If you get that increase in productivity, and not just 10 percent. It’s likely to be more around 20 percent or more.

Gavin: Yes.

Jesse: Yeah.

Kirstin: Then you can’t really argue with the cost of coaching on that basis.

Gavin: That’s right. A lot of people, when we train them and we offer coaching services, feel sometimes that we’re just trying to sell the more stuff, which definitely isn’t the case. It’s what we know to be the most successful way for them to implement Agile practices in their workplace.

Kirstin: Using our own company’s example, it took us five or six years to really hone our practice. In that time, we didn’t have an Agile coach. We had leadership that was really, really passionate about it, and did a lot of learning.

Had we had an external couch — because it always sounds more convincing coming from an external source — we would have made that transition to being the best we could be and continued to improve sooner.

G: That I like the little cartoon in the blog post, where one guy’s saying to another, “What if we train our staff and they leave?” The other guy says, “What if we don’t and they stay?” which I think is a very apt.

Kirstin: It’s really apt, isn’t it?

Jesse: Yeah.

Kirstin: You’ll find, when you talk to employees, it’s often a bugbear. “Why haven’t I had any training? Why won’t a company invest in my career and my development?”

Jesse: Yeah, absolutely.

Kirstin: Of course, it’s the first thing to go in tough times, but that’s probably misguided as well, because of the reasons we’re talking about with Agile around productivity, but obviously there are other benefits in other types of training.

Gavin: Yeah. With Agile, the training really helps you understand why you’re doing things and how to do it, but the coaching makes sure that people are being Agile, rather than just doing Agile.

Jesse: We’ve had some training at ourselves, recently, and they talked a lot about skill set versus mind set.

Gavin: Yes.

Jesse: That short half-day type of training gets across the skill set that you need, so you understand the mechanics of Scrum. You understand that you have to stand up in the morning, but you don’t really understand why.

Embedding that Agile culture in an organization doesn’t happen in a day or a half a day. It just can’t. Having someone to support you…obviously, we’re talking about coaching, but however that works is really useful for an organization. We see clients that we can help with coaching as well as training get far better results.

Kirstin: We see it here as well. When we have a new team member join, they pick up the mechanics of Scrum really quickly, because it’s not rocket science, is it? There’s not that much involved. But over the first month or so, we then start to pick up areas where we need to help them understand why they’re doing it more and how to work within a team.

These are people, quite often, who are used to working quite individually and autonomously, without collaborating, particularly, outside of their discipline. So obviously, what we’re doing here…we have a couple of our job coaches just hanging about now and then. We coach our internal team members as well when we see that they need some help.

It’s a pretty stark example when you see it in your own office, isn’t it?

Gavin: Yes, absolutely. Absolutely. I’ve been to a lot of places around town and speaking to people, and they say, “We’re doing Scrum but we’ve actually forgotten why we’re doing it.” That’s a little bit sad to see.

Kirstin: What’s your suggestion of something that can remind them of why they’re doing it?

Gavin: Possibly a few workshops and just keep having conversations with people. Maybe asking them at certain points, for example at a retrospective, to say, “Hey, why are we having this retrospective? What’s the point of this?” Just ask them why we’re doing certain things, as we are actually doing them.

Kirstin: “Ask the team,” so we say.

Gavin: Yes, ask the team. That’s like Jesse and I ran a workshop yesterday about breaking up user stories. How did you feel that went?

Jesse: I think it went quite well.

Gavin: Yeah, I enjoyed it. It was a really good conversation. Really interesting to be a part of. It was a great turnout.

Kirstin: This is a coaching session with an external client?

Gavin: Yes. There was a really great bunch of people and some really interesting conversations, but at one point decided to ask, out of curiosity, “Why do we break down user stories?” We’re doing a workshop around breaking down user stories. “Why do you think… “I know this is off-topic, but…

Kirstin: Because reducing batch size increases productivity and reduces variability.

Gavin: That’s one reason.

Kirstin: That’s one reason.

Gavin: There’s many reasons.

Kirstin: Then you need to be discrete. You need to be able to stand and finish something without dependencies.

Gavin: You passed that test. But just asking that question was interesting to see what sort of responses we got.

Kirstin: What kind of answers did you get?

Jesse: Lots of “Uh…”

Kirstin: Put on the spot.

Gavin: There was a bit of a pause at the start. Then a few people chimed in. People said, “You want to keep it small, so it can be done in a sprint,” and “We want to minimize the amount of risk involved in the story,” and “You want to minimize the amount of unknowns in the story.”

There were good answers. I thought it was interesting to see what they had to say.

Kirstin: Yeah. It is good. We’ve been working with that particular organization for six months now, so you must have been glad there was a response.

[laughter]

Gavin: Yes. As always, when you ask a question like that, there’s a bit of a pause.

Kirstin: It sort of dangles in the air there, and you’re like, “Ah…”

Gavin: You just have to be silent and see what people come up with. That’s a good example, as well, of a company that we did train everybody together, which is fantastic.

Kirstin: Including the management. It was the whole company, wasn’t it?

Gavin: Yes, exactly. We’ve been in there coaching as well. That’s absolutely the right way to do it. People just need help with Agile, because it’s really difficult to do. It’s really difficult to get right, and keep everybody on track with it. Like that paper Scrum is hard and disruptive. It’s very, very true.

Kirstin: I’ve got something from Nathan’s blog post, talking about not just the benefit of increased productivity, which is something that often senior management is very focused on, but the further benefits, things like increased alignment.

He was talking particularly in relation to working with contractors and internal teams. There can be that real us-and-them divide in that situation, so he was talking about reducing that and increasing empathy between the two types of employee.

Increased alignment. A focus on results rather than a focus on productivity, which I think is a really important distinction. Accountability and empowerment. Increases in quality, which can’t be underestimated either. Obviously, if quality is low it’s going to cost more time and money later on anyway.

What else do you have? I can’t read my writing.

Gavin: [laughs]

Kirstin: Ah, improved team morale.

Getting to market earlier. That’s something that large projects can really suffer from. They’re trying to do so much at a time, rather than concentrating on getting that minimum viable product out to market. I know it’s not always practical as massive enterprise projects, but it is something that I think they should keep focused on.

Focus on delivering value early and often. Rather than delivering features and how many — again, that’s a productivity issue — but how you can deliver value to your end users.

Gavin: That’s something that they need help with on an ongoing basis, as well, because they can fall into the trap where they take the easy route a little bit, again. They write stories which just fit into their current workflow.

Kirstin: What would be an example, as compared to the kind of stories that we write?

Gavin: I’m trying to think of a simple example. We’ve used this example in the past. As a user, I want to be able to log in so I can access the website. It doesn’t actually create any value, that story. It’s just logging in. It’s not really a benefit for the user.

Kirstin: We’d normally have, “I want to update my preferences,” and that might involve creating a log on for the users.

Gavin: Yeah. Or, “I want to log in to my Debtor Daddy app so I can view any outstanding bills.”

Kirstin: Or, even not include the web login, though.

Gavin: Well, that’s right, yes.

Kirstin: Something like, “I want to be able to administrate this account securely,” for example.

Gavin: Yes, exactly. Each story, having to create a little bit of value rather than just being the next step in your development process. That’s a difficult one that often drops out. That company we were with yesterday are great, because they’re always thinking about that stuff and always addressing it. That’s a really, really positive thing.

Jesse: Also on that value thing is having coaching and someone else to maybe challenge your ideas of value. As a prototype user interface, that you can go out and user test probably doesn’t provide value to an end user straightaway. But, in the long run it’s hugely valuable. You can go out and test stuff, say, “All right, well, no one actually wants to use this section of the page, let’s do away with it,” and never build it.

Kirstin: Yeah, exactly. It’s that whole avoiding the cost of delay of actually building that and just taking a prototype instead, and then validating your ideas. That’s really in line with the Lean start-up principles of validating before you waste time and money building.

Jesse: Exactly.

Kirstin: Prototyping, that’s not something that we do a whole heap around here?

Gavin: No.

Kirstin: Is there a reason for that?

Gavin: Well, we do, in a sense. We just did a week sprint for the Kea Conservation Trust Wildlife app, which is available in the app store, Wildlife Tracker. We did a week-long sprint there and just produced minimum viable product, which is a short…

Kirstin: I guess that is a prototype.

Gavin: It’s pretty much a prototype, yes. They achieved a lot and they built a lot of features within that week, but we’re putting it out there based on the use it gets.

Kirstin: It’s great to get it out there so quickly, for a lot of reasons. That getting-to-market-early thing was particularly important here, because that particular app is something people will use while they’re on holidays this year. Obviously, in New Zealand, this is our long holiday period that we all take off four weeks on end. [laughs]

Given that Wildlife Tracker can be used when you’re tramping to take pictures of endangered species, it’s the perfect time to get it out. We wouldn’t have wanted to wait any longer, really.

Gavin: Yes. We absolutely don’t get everything right here. I let a story slip into this current sprint, which looking at, it’s exactly what we’re talking about. Now it’s creating web API, but there’s no benefit.

Kirstin: Benefit to the end user.

Gavin: It’s just doing, like that guy was talking to us yesterday about, doing the plumbing but no output of that.

Kirstin: Should that have been something like, “I want to enable other conservation organizations to take advantage of the features of this app”?

Gavin: Actually, rather than, “I want to build a web API so I can add lots of exciting features,” it should be, “I want to take a photo of a kea and upload it to a database.”

Kirstin: Isn’t that what we’re already doing?

Gavin: No. At the moment, the MVP was just emailing the photograph.

Kirstin: Oh, just sending it. Oh, it’s to enable it to be sent directly to the database without intervention by admin?

Gavin: Yes, exactly. There are lots of different things that we can do now that we have web API.

Kirstin: That sounds like a messy story, as well. Is it?

Gavin: It’s bigger than it was originally thought to be, yes.

Kirstin: [laughs] That’s the thing. We don’t claim to have nailed Agile. We’re always inspecting the depths…

[crosstalk]

Gavin: That’s the thing. We all have coaches here, so we need help. I don’t know if our coaches have coaches. It’s like the infinite loop of coaching.

Kirstin: That’s interesting. I know Nathan has a coach. Our MD has a coach.

Gavin: The one thing we want to really get across today is the importance of training, and please do. If you’re going to invest in it, invest in it. Whether it’s with us or it’s somebody else, we don’t care. Just invest in it.

Kirstin: Well, we care a wee bit. [laughs]

Gavin: If you’re moving to work in Agile, get everybody to…it’s worth the investment.

Kirstin: Spend some time on it.

Gavin: Not only do the training with everybody, but I’d heavily advise coaching afterwards, as well.

Kirstin: Yeah, absolutely. The benefits can’t be overestimated.

Gavin: I’ve seen situations where obviously we have just trained people, went through a two-day training, one-day training, sometimes a three-quarter-day training, and with mixed results. We know that they just go off and choose bits and pieces that are possibly easy to put into place, and it’s not really having the benefits that it should be.

Kirstin: I don’t think that’s always wrong, depending on the organization. I was talking to Nathan yesterday about an organization that has a business project, rather than a development project. The person I had had spoken to had been to CSM and learned some stuff about scrum, but she didn’t want to put all that into this project, because it wouldn’t be appropriate.

She was saying, “There are some things I can pick out, because I have found that the boards are great [, but what else can I do?” I talked to her about running some personal kanban stuff and keeping it really lightweight, but getting those benefits of productivity flow by putting the in-progress limits on [indecipherable 00:18:09] and things like that.

That’s something where she doesn’t have to implement a whole methodology. She can just pick out the bits that are going to be of most use to her in this situation. Hopefully, she got some value out of that and we can go and do some training there eventually.

Gavin: We’ve also had situations where we just get to train. There was an example about six months ago where we trained two staff members from a company. They were really inspired by the training. It was a great course. We were running as the ICAgile Fundamentals course.

They went away really inspired, but because it was just two people…

Kirstin: It hasn’t really gone anywhere, has it?

Gavin: No. That must be quite hard for those two people, because they do have all these ideas and see how to apply them, and then they come back and tell everybody and that’s where it ends. But if you get everybody involved, you have a movement on your hands, very revolutionary.

Kirstin: Going back slightly to Nathan’s blog post again, with those actual numbers in there — which would show a lot of people very starkly the benefits of the training — that’s the kind of thing that we need to be looking at showing our prospective clients. Not focusing on what’s your [indecipherable 00:19:24] right now, but what are going to be your gains as a result?

Jesse: Yeah, absolutely.

Kirstin: It’s very hard for people when all they see is a bottom line that has to be done now.

Jesse: Yeah, absolutely.

Kirstin: And I think we can be fairly confident that if people are willing to invest time and some money, we can get in at least a 10 percent increase in productivity, if not more. I’d be willing to guarantee that in some situations — most situations, probably.

Jesse: Yeah, I think so. It’s not immediate. For sure, it takes a couple weeks.

Kirstin: I think two to four weeks.

Gavin: I even think that’s a slightly dangerous term, in a way, “A 10 percent increase in productivity.” For me that’s an increase in efficiency, almost. You’re working on the right stuff at the right time and you’re working in a more efficient manner. Because people, it’s not like they’re writing more lines of code, or…

Kirstin: No, at least hopefully.

Gavin: …possibly not even delivering more features, just delivering the right features first.

Kirstin: Yeah. The problem is that people love things to be quantified, particularly business people who are short of time. They like to see stats and amounts. It’s quite hard to quantify things like an increase in the team morale.

Although there are things we could do, obviously. We could say, “Look, we will measure this. We’re going to start using the smiley faces board the minute we get in there.” I guess we could look at how to measure those intangibles a bit better. But I think probably that harder task is having people understand how important that stuff is as compared to those numbers.

That probably brings us to the end for today, doesn’t it?

Gavin: I think so, yeah.

Jesse: Yes.

Gavin: What’s our one message today? Is it just, “Please do invest. If you’re going to work in an Agile way, invest in training?”

Kirstin: Either take the time and the budget that it requires or don’t do it. [laughs] It’s a stark choice. You’re better to do it right or not do it at all.

Gavin: Or if you’re not willing to invest in the training, it doesn’t bode very well for investing in working in an Agile way down the road.

Kirstin: That’s right. You need to show some commitment from the outset. Not to be too bossy about it, but that’s our recommendation.

So we’ll see you in the New Year. Thanks for joining us for this year if you have done, or seen us on YouTube. Thanks to Gavin and our newest member Jesse.

Jesse: Thank you.

Gavin: Thank you very much.

Kirstin: Bye.

Jesse: See you.