By Rebecca Jones
In Episode 39 of The Board, we talk about:
Agile for Non-software Teams by Gil Broza: a summary
Gavin Coughlan: Hello and welcome to another episode of “The Board.” I’m Gavin Coughlan, Agile coach, Boost Agile. Today we are going to be talking about a series of blog posts that we saw on a website called Agilitrix.
Kirstin: Agilitrix.com
Gavin: These blog posts are writing by Michael Sahota. They seemed relevant to a lot of stuff that is popping up for us at the moment. I am joined by…
Kirstin: Kirstin Donaldson.
Jesse Stegmann: And Jesse Stegmann.
Gavin: Recently, we’ve been doing a lot of work with a lot of people who want to do Agile.
Kirstin: That’s right.
Gavin: They come to us for help. Whether they’re setting up an Agile transformation for the first time, or maybe they’re already using Scrum or Kanban and having some issues with that, things are not going as well as they would like, and we go to help with that. Recently, we did a retrospective for a team, as a full day retrospective of their project. One of the goals was to do Agile.
Kirstin: Previously, the project they’d been working on hadn’t been doing Agile?
Gavin: No, no. That was one of the goals, and sure, that’s a fine goal, but it rang a couple of alarm bells. The question isn’t whether somebody doing Agile or not, and that led us to find out about this blog post, which are called, “Agile is not the goal.”
Kirstin: This agilitrix.com sums it up nicely when it talks about not making moving to Agile the outcome, but looking at what outcomes you want to achieve, and then thinking about how you want to achieve those. Quite often the answer’s quite naturally Agile taken beyond something about…
[crosstalk]
Gavin: Yeah, that’s right. A lot of times we ask people why they want to move to Agile, and they don’t really have a goal that they can put it into words. They just think it might be better than what they have done before.
Kirstin: Or, worse still, it’s being imposed on them by management, who has hit that crisis point and is looking for different way. And of course, when it is imposed on a team by management, you find the level of engagement is not ideal. [laughs] They’re not buying into the system. They’re not fully committing to it.
Gavin: That’s right. Recently we did some work with a team, and they liked using sticky notes. That was a bit of an issue for them. They felt we’re bringing them back to the 1960’s. But these sticky notes, in doing our retrospectives, they just wanted to share information on their computers, felt that was easier read, and that’s what they’ve always done.
Fair enough. They don’t want to do it. It wasn’t their choice to and was imposed on them.
Kirstin: Interestingly though, the Agilitrix.com notes that if people refuse to use Post-It notes, it’s a very bad sign. You’re probably not going to succeed.
Gavin: Uh-huh.
Jesse: Yeah.
Kirstin: It sounds dramatic, but it’s probably true. [laughs] Post-It notes are really central to the process for a number of reasons. One of the interesting things he talks about is using sticky notes properly. He’s got a little guide there on a link off the main page about this Agile workshop. It’s got all the really essential stuff like write legibly, write in capitals, one idea per Post-It note.
And one that I’d add from personal experience is write with Sharpies. When different people have grabbed a biro or a pen, they’ve written way too much and you can’t see it from very far away.
Gavin: Yeah, that’s right.
Jesse: Yeah.
Kirstin: And it sounds silly, because I’m always like, “Use a Sharpie!” like it’s the most dramatic thing on earth, but actually it does make a massive difference.
Gavin: And then the same if I see people are writing a few points per Post-It. I get them to rewrite them. First of all, it’s more legible if you’ve put less on the Post-It. You want to use fewer words rather than more words on a Post-It, which is another great thing about Post-Its. It limits the amount of words you can put on there.
Also if you have different ideas on different Post-Its, you can move them around separately, which is very important. You might want to prioritize these ideas. But a lot of people just don’t see the sense in that. They think sticky notes are just a little bit silly. They feel foolish if they’ve been not using sticky notes. They feel it’s childish or something.
But the tactile nature of sticky notes and having an actual physical Scrum board is irreplaceable. And the conversations you get around a Scrum board when people actually stand up there are just so much better than if people are sharing a computer or looking at a computer screen.
Kirstin: That’s the first steps to this workshop. Do you want to take them through how this works?
Gavin: The question is, “Is Agile the goal or Agile should not be the goal?” There’s a workshop that I think is really interesting that we should run. Our question is, “Why do you want to do Agile?” We’ve asked that forever, but we’ve never done a full workshop around it. That would be really interesting to see what sort of results you get.
First and foremost when you’re setting up the workshop, which takes about an hour, it’s getting the right people into the room. You want the key decision makers and people who have a bit of influence in a room. You ask them why you want to undergo an Agile transformation.
You give them about five minutes to write one point per Post-It. Hopefully they’ll have lots and lots of different ideas as to why they want to work in an Agile way. Why they want to do Agile.
Only then do you actually put up three flip chart posters, which are “What?” “Why?” and, “How?” You only ask the question. You say, “Why?” And then once they’ve written out all the whys you actually split them into “What?” “why?” and, “How?”
The “What?” is going to be the outcome that they want. It’s the end state, so it might be…
Kirstin: For example, I’m doing a web development project and I want to avoid wasting time. I want it to be timely and I don’t want to go through a long painful UAT period.
Gavin: Yeah. Then you have the “Why?” which tells you that the reasoning behind the decision for them to go and work in an Agile way. Then the “How?” which is how you’re going to do it and how you’re going to set yourselves up to actually do it.
Then, as we do in a lot of retrospectives, we get people to group these Post-Its into similar themes and to vote on them with sticky dots. You’ll see some priorities, some things that are really important to these people. What you find is that none of the priorities are Agile. The things that they want aren’t necessarily Agile things.
Kirstin: Project goals and things.
Gavin: Yeah.
Kirstin: One interesting thing about voting is that Sahota recommends that the voting is in reverse seniority order. The reason for that is that people tend to vote with the most senior person in the room. If they vote last, you don’t get following the leader.
Jesse: Yes.
Gavin: Yeah. I still haven’t found a way to get people to dot vote without…some people always hang back and do tactical voting.
Kirstin: Do you think that?
Gavin: Yeah.
Jesse: Yeah.
Kirstin: I wonder why they bother?
Jesse: I suppose it also depends on the group size.
Kirstin: Yeah.
Jesse: In the bigger the group, obviously the less you can vote tactically. As the group gets smaller, there are people that will hold back and can manipulate things a little bit.
Gavin: Yes.
Kirstin: Right. Obviously, not being strategic enough in those situations that it’s…
[laughter]
Gavin: No, no.
Then, by the time people have dot voted on these things, you have your list of priorities and things that are really important to people. It might be better quality code or it might be better communications between the business and development team. Those might be some of the most important things.
Then you can say, “Well, yes, Agile can help with this and this and this. And it might be something that Agile can’t help with, but it’s really get to the root cause of why they want to make that change in the first place.
It would A, be just a good thing to ask your teams that’s about to go down that road. It would be a really good way for people who aren’t convinced. If people need to be convinced, it would be a good way of explaining that to them, and say, “Well, this is what’s important to you and this is how Agile could help with that.”
Jesse: Yeah.
Kirstin: Yeah, if you can address specific points on the highest voter ones and say, “Well, under Agile we use, for example, visible work spaces which increases the communication between the business and the team, without actually needing to make a particular effort.
Gavin: Yeah.
Jesse: Yeah. I think it’s an interesting point. Gavin was talking about our clients that are having a bit of trouble with Agile at the moment. They are resisting and the team is resisting, because they don’t feel that Agile provides any benefits.
But they’re missing out because they haven’t gone through this process and haven’t said, “What’s really important to us, for example, is communication.” They’ve seen a massive jump in communication and sharing between the teams, but because they’re just doing Agile and they’re resistant to that, they’re missing out. They don’t acknowledge any of the benefits that have come through.
Kirstin: Because they haven’t identified the goals they’re trying to achieve in improving the project process. Of course, they’re not going to tie it to that.
Jesse: Yeah.
Kirstin: I think also they may not be getting that communication from the senior management. Senior management might have said to a couple people, “Oh, it’s great to see it’s happening,” but I don’t think that’s filtered down to the team at all.
Jesse: No, no.
Gavin: If Agile is thrust upon a team, because their superiors want more productivity, it’s not going to be greeted with open arms by the team.
Kirstin: That’s right. That’s quite often the only goal that team would see if they haven’t gone through something like this, right?
Gavin: Yes.
Kirstin: Like, “Well, this project’s not achieving what we want to achieve,” so they just try to make it achievable.
Gavin: Yes, and I’ve met lots of people who at the beginning, when they start using Scrum, say to me, “Oh, Scrum’s just a way to make us work harder.”
Kirstin: I’ve heard that as well. I didn’t really understand it, because I have been brought into the process quite well. Right?
Gavin: I think they mention that in Silicon Valley as well.
Kirstin: They did. They did. It was like [indecipherable 00:10:08.16] .
Gavin: Yeah. I’ve had developers say that to me as well. Scrum, it’s just tricking me into working faster.
Kirstin: It’s doing a very good job, if that’s the case.
Gavin: That’s right. But obviously that’s not the goal. Usually developers, if they work using Scrum for a while, start to see that after a few sprints. But it does take a few sprints for that to actually bubble up to the surface, really.
Jesse: Yeah, yeah. And it’s, again, understanding why you’re doing Agile. If management are saying, “Right, we’re doing this to be more productive,” it definitely can sound to people down below that, “You’re going to work harder.” It’s not the fact that we’re more productive in a more efficient way and we’re building the right stuff with less waste and it’s a better process.
So we’re not. It doesn’t mean absolutely you shouldn’t be working more hours and writing more code. You should be…
Gavin: In a way, it should make you work less hard.
Jesse: Yeah.
Gavin: In a way, because you want to work in a sustainable way.
Kirstin: Is that right?
Gavin: Yeah.
Jesse: Yeah.
Kirstin: It’s an interesting link off Agilitrix as well, another post by him talking about the fact that if Agile is the goal, there’s been a tendency to start to weaponize it, using it as a whip or a shield. You see a couple of examples here. The whip, when someone asks you to do something, you say, “Well, that’s not Agile. It doesn’t fit in with what we’re doing.” So using it as a whip to say, “Not going to.”
You know, lots of sort of nit picky rules like, “How dare you? You can’t for something in the middle of a sprint. That’s something that is talked about in the way we do Scrum. But obviously, if you are of an Agile mindset, you’ll be more likely to have a conversation about what’s happening and why and what we can do to facilitate this person’s needs in the middle of a sprint.
The shield, he says is things like using Agile to deflect blame and justify your actions. It’s saying things like, “Don’t tell us what to do. We’re self-organizing,” keeping people away from the team.
“You have to wait for the next sprint for us to work on that. That’s the rules. We don’t have to do it that way. We are Agile.” Which again is not in keeping with an Agile mindset in the spirit of conversation over the sort of contract, which is actually sticking to the rules and…
[crosstalk]
Gavin: Oh, yeah. That’s right. That’s the sort of behavior that sometimes gives Agile a bit of a bad name, as well. Yeah, some people had bad experiences because of that. I think that happens if people are really, really rigid with Agile, which I think is totally at odds with it. The point is not being really rigid with it, and being flexible.
Kirstin: But it’s supposed to be about flexibility, isn’t it?
Gavin: Yeah.
Jesse: Yeah.
Kirstin: When you go off and ask someone something, and they say, “Well, I can’t possibly do that or say that because of Agile,” it’s very off-putting.
Jesse: Yeah.
Gavin: We go to a lot of companies and they are using Scrum. We say, “So, who knows Agile values?” and people don’t. For me, obviously the most important thing to understand is to understand that and to live those Agile values.
Kirstin: Yeah, because if you can keep those in mind. If you are having a problem on a project, if you can try and look at those to relate back to it, it can quite often provide a starting point for finding an answer.
Jesse: Absolutely, yeah. Agile done badly is just as bad as any other framework done poorly. There are lots of…Waterfall done poorly is bad, but there are different places where Waterfall can work. Absolutely. Agile is the same. If you just try and apply it, and apply really poorly, you’re not going to see the benefit and you’re not going to get good results.
Gavin: Yeah, that’s really important to us, making sure that Agile is right for people. Even though it’s our job to help people with Agile transformations, we don’t always just want to go blindly in and say, “Yes, let’s just do it.” You want to make sure that it’s the right thing. It’s just not always going to be the right thing.
We’ll have run that workshop. When we do run the workshop, we’ll talk about it here again. I think it’ll be interesting to see how that goes.
Kirstin: Absolutely. So we’ll post up that link on the Livestream afterwards. What else have we been up to in the recent…?
Gavin: Well, we just did an all-day retrospective, which is why this conversation about Agilitrix came up.
Kirstin: Do you think you learned anything new yesterday when you did that?
Gavin: It’s really interesting because it was an internal team and the vendors in the same room together.
Kirstin: It’s great that they’re able to take the time to get together and do that.
Gavin: Yeah.
Jesse: Yeah.
Kirstin: Quite unusual.
Gavin: They’ve never done that before. Obviously, a full-day retrospective is a six-month project that we were talking about.
Kirstin: Particularly because this hasn’t been done in the Agile way, to get together and take time to do that when it’s not something that they’ve been regularly doing is great.
Gavin: And we don’t that many full-day retrospectives, so I wasn’t sure exactly how it was going to go, especially with a team that’s not used to retrospectives. I know a lot of those things just depend on the people who are involved. If you have people who just want to engage or get involved, it’s going to be a long day. But it was a really fantastic group and I thought they were really open, honest, and pretty courageous.
Kirstin: Did anyone object to Post-It notes?
Gavin: No, everybody dove in straightaway.
Jesse: No objection to Post-It notes. That was useful.
Kirstin: A good start.
Jesse: Yeah.
Gavin: Full engagement. So do we want to go through the agenda for the full-day retrospective?
Kirstin: I think it’ll be quite helpful to people who are thinking about doing a full day, as opposed to a two hour.
Gavin: This is just what we did. We took bits and pieces from what we’ve done in the past and from what we’ve seen other people do, as well. We started the day with the retrospective prime directive, because it was their first retro. Just to make sure that people understood that, understood why we’re going through the prime directive, and knew that it was a safe place, not a place to throw blame around.
They went through a team charter, just how we wanted to work for the day. Phones were on silent. People, if they needed to get up and move around, they could do that. There’s no talking over each other You have to be respectful to each other. I think those…just really good exercises to go through.
Jesse: Yeah.
Gavin: The artifacts contest was the next step. We gave people some homework to do before the retrospective. They had to bring in some artifacts from the project, things that they felt were significant. It could be anything from emails, from photos of prototypes and designs, or objects.
Somebody brought a T-shirt, which was relevant. People brought an email. People brought a picture of a form that was really long that they wanted to amend. Somebody brought a photograph of a little Lego person to represent the women who were not actually in the photograph. It was an all male photograph it looked like. It was all just dudes who successfully completed this project, but it wasn’t.
We did that and we gave them a box of chocolates, Butlers Chocolates, good Irish chocolates, for the most significant artifact, as voted by the group, and for the most unusual artifact as voted by the group. That’s a nice way to get people up and talking.
Kirstin Donaldson: Do you want to explain why they…?
Gavin: They just had to show their artifacts and explain why it was significant and why they brought it along. It’s like a check-in exercise if you’re to look at standard sprint retrospectives. Just make sure everybody had the chance to talk and there’s a bit of laughing as well. It was a good way to kick things off.
Kirstin: Right, yes.
Gavin: Then we got them to create a massive timeline. There’s a lot to go through from the six months, so we put it across one massive wall. Got everybody to split it up into months, the six months that the project went into. Across the top, almost like a story map, you had the milestones, so people knew what happened and when it happened.
Jesse: Those were major release dates or when key deliverables were delivered?
Gavin: Yeah.
Jesse: Once they’d done that, they had a really good sense of the span of the project, where key things happened. We went through and got every person to draw a mood line. That is mapping…we split the timeline in half, happy and sad. Then as they went through, they said, “All right. We started the project and it was really exciting.” As they went through the project, they narrated the highs and lows and how the project went for them personally.
I think we had 14 people in the room. We got everyone to do that. Really interesting to see the different perspectives of people. Some people started off a bit down about the project and then came up. People’s peaks and troughs were completely opposite, which was…
Kirstin: It’s emotional.
Jesse: Yeah.
Gavin: So one guy’s high was, “I managed to give all the infrastructure work to that guy sitting over there.” Then that guy’s low was, “Yeah, I received all the infrastructure work from the guy.”
Jesse: Yeah, yeah.
Kirstin: I guess theirs did correspond.
Gavin: The mood line was really fantastic just to get people’s feelings about things. It was the first time they had ever really done that. People were really honest and open about it.
Kirstin: There’s some moments for people to hear laughter.
Gavin: Yeah, absolutely. This was very interesting for us to see, because we had no involvement in the project before that. I think we learned a lot about it just from seeing that. Then after everybody’s mood lines were up, you had a good picture of how people felt. It got pretty crazy in one part. Everybody’s lines were up and down. It was a real roller coaster ride.
Then we got them to silent brainstorm and just fill that mood line up with events that happened all the way through the project that they felt either good or not so good about. They’d stick them up in the relevant posters. That took a while to go through. By the time we had that, we had a really detailed picture of what happened. It was fantastic.
Then we asked them to group all those items into common themes, which was quite easy to do. There were a lot of common things that bubbled up to the surface. Once they had that, they named those common themes and then they dot voted what they wanted to talk about.
Kirstin: Did you do that in reverse order of seniority?
Gavin: No, we didn’t do that. We just did it all at once. It was a free-for-all. Everybody could just vote at the same time. Obviously, there’s some stuff that didn’t get voted on, but had a couple of votes. People were, “We need to talk about that.” It was like, “Oh, well. We can’t talk about…
Jesse: That was really interesting. Once we found our top three things, we said, “This is what you guys have voted on, and so this is what we’re going to talk about. We’re going to hopefully come up with some goals around these.” After that, there was quite a bit of dissent that those were the top things that actually needed to be talked about.
Kirstin: From whom? Just in terms of the senior people, did they try to overrule?
Jesse: It actually wasn’t the senior people. It was various people across the group. I suppose there were a few topics that were quite important to them, and they were really important to talk about in context of the project moving forward. I suppose they felt that it had to be dealt with. They were trying to deal with everything, rather than just trying to pick off a few key points.
Kirstin: Did you have to explain why we dot vote?
Gavin: Yeah, we have to say, “We can only…” because there’s so many different groupings. They all had a smattering of votes on them. Spattering, smattering of votes.
[laughter]
Gavin: Just had to tell them that we couldn’t possibly talk about everything, because that’s going to take a week and we just don’t have that much time, so we had to concentrate on some certain things.
Kirstin: Prioritizing, isn’t it?
Jesse: Yeah.
Gavin: As it turns out, we got them to break out into groups, come up with goals within those groups, and then they presented those. Then they had to prioritize those goals within the groups. We stuck them all up, and we were going to come up with the goals for all those things.
But as we came up with goals, we found that if we came up with a smart goal that actually covered a couple of their ideas, so we were able to meld down. where we would have nine goals at the end, I think we ended up with five, because it actually addressed a few of the different points that they had.
Kirstin: It’s a bit like when we make the personas during user experience and that kind of thing. We say, “We’re going to identify the most important persona.” People don’t get worried about whether features are going to satisfy the other audiences as well. But actually, if you do cater for the most important ones, in this case, the most important issues, the rest does get dealt with?
Jesse: Yeah, exactly.
Kirstin: Quite a good thing to show people.
Gavin: Then we came up with the smart goals. That’s always the most difficult part. They had to come up with those smart goals, because there are a lot of different ideas.
Kirstin: Particularly over the nature of a long project.
Gavin: Yes. They came up with five, and two or three of them were really great. The other two or three, good, but we didn’t have time to…
Jesse: Flesh them out.
Gavin: …fully flesh them out and make them as measurable, achievable, relevant, timely as we possibly could. After that, we had some interesting conversations. Then we did a round of appreciations at the end. Everybody wrote down names or a name of somebody that they wanted to verbally appreciate. That’s a really nice way to finish. Got them to give each other a round of applause at the end. Then we went to the pub and had pizza and beer, which is a good way to finish a retrospective.
Kirstin: Yeah. I went to the pizza and beer session, [laughs] and it was really great to see.
Gavin: Yeah, you got into the good part of that retrospective.
Kirstin: It all looked quite fun from the outside. But going to that session, I could feel that people were relaxed with each other. Some of them are obviously good friends. They’re already working closely together. But the suppliers went along for the drinks, as well, and they’re all very easy with each other. Obviously, they’d got a lot out of the day and it was really useful. That was good to go and engage them. That helped.
Gavin: Yep, absolutely. It’s interesting because every time we put it together a retrospective, we try different things. A couple of those things that we tried yesterday were new and they worked well. They gave us an idea of do we want to use them again in the future and gave us ideas for timings and those things.
Jesse: Yeah.
Kirstin: Yeah.
Gavin: For example, the artifacts competition took about 50 minutes less than I expected.
Kirstin: Oh, really?
Gavin: Yeah.
Jesse: Yeah.
Kirstin: Like a couple minutes for each?
Gavin: Yeah.
Jesse: Yeah, yeah. Also the mood lines, which was possibly the most valuable part of the whole day was not actually…we’d cut that out in the initial planning. We thought, “Oh, we’re not going to have enough time to do it.” But because artifacts took so little time, we were able to add that back in.
Kirstin: So it was quite fortuitous, then?
Jesse: Absolutely.
Kirstin: As it turns out. Someone afterwards was saying that he had really enjoyed the mood lines, so I was telling him about journey lines as well. He was saying, “Oh, when did you guys do this?” I said, “Well, we’d had a couple of new team members doing this, so we did an exercise on them.” He thought that sounded like a great idea.
Gavin: Yeah. I think those guys would be really into it, because they’re obviously committed. They were fully engaged through out the day. It’s just fantastic to work with people like that, because if this goes so well, then you get so much out of it. They get so much out of it. I thought something like the journey lines exercise would also be quite useful for this.
Kirstin: It’s really good at the start of a project, as well. As I was telling him last night, it creates empathy really quickly, makes you think a bit more about people in such a relatively short time.
Jesse: Also it gives you a really good understanding of some skills that you don’t know that a person has, and that you could leverage during the project, as well.
Kirstin: Yeah. There are a lot of benefits.
Jesse: Yeah.
Gavin: Cool. Yeah, that’s…
Kirstin: That’s it for today.
Gavin: Yeah, that’s about it from us.
Kirstin: We’ll be back in two weeks.
Gavin: Yeah. Thank you very much for joining us and see you next time.
Jesse: Cheers.
