We had the chance to sit down with agile consultant Ben Linders to discuss the power of collaboration and feedback on agile projects. Ben has an excellent blog, and a new book that are both worth checking out by anyone working with agile, whether you’re an agile expert, or are new to the practice.
Noel Wurst: Hello, this is Noel Wurst with Skytap and I am speaking with Ben Linders today. Ben Linders is an independent consultant helping people with process improvement, agile, and lean. I came across Ben’s blog and some of his writing online and just thought he had some really great ideas about agile and continuous improvement, and retrospectives specifically, and wanted to speak with him today. Ben, how are you today?
Ben Linders: Very good, thank you.
Noel Wurst: Great. Thanks so much for speaking with us.
Ben Linders: You’re welcome.
Noel Wurst: Great. One thing I usually like to ask people who are focused on agile is, I’m always really impressed when people find new ways to implement agile in other areas, obviously it was originally designed for software, but I’ve seen it used in ways to kind of increase the quality of data analytics, even in the marketing strategies, manufacturing, of course. I’ve seen how to use agile in the home when raising your children and connecting with your spouse, even. I was kind of reading your blog and saw where you’ve pointed out that you can actually use agile to become agile. I was kind of curious as to how you do that and how that works, generally.
Ben Linders: Basically, the reason I think that agile is being adopted in so many different areas is that if you look at the ideas behind agile or the principle behind agile, then I don’t think that many people would object to them. The focus that I put on people in the organization, focus that I put on collaboration and on the customer needs, and being in contact with your customer and using feedback to continue to broaden yourself, I think, basically, people love that kind of thing and they wouldn’t object to that. I think that’s the reason that they look for ways to do agile in the ways that they are doing already.
That’s also the way that we started using agile as a way to become agile in our organization to do process improvement. So, where you previously had to deal with large improvement programs which took a long time to head up, we have many discussions, usually more involving management, now we leave it to the people from the work floor to see what the changes are that they would like to be doing in the organization. We decided that it would be much more interesting to start doing short- cycle changes in the organization and getting the people in the organization involved in that.
One of the big benefits that we saw from doing it in an agile way is that we actually developed a product backlog of changes that we wanted to do in the organization and spelling out the changes that were needing spelling out, whether the stakeholders will be involved in that, what we expected from them. We used that to check every two or three weeks with our stakeholders, see if we would still be on track and if our priorities of the changes that we were doing were still derived by origin there. So, actually this product backlog of changes became a very strong tool because the stakeholders could see that changes that they were aiming at and they could see the results coming out of that, and could influence the improvement program along the way. This is a big benefit for them.
Noel Wurst: That’s cool. I’ve never thought about that before, as far as there just being so many principles and methodologies within agile that are kind of hard to argue against, like, focusing more on your customers needs, and then figuring out how to address those needs and to reach those by using those short iterations. It’s almost like it’s been able to expand into so many areas. You can take the customer needs and, like I said, using agile in the home, you can translate that to your family’s needs. Maybe looking at your data analytics, that’s maybe perhaps the needs of your own business. If you’re looking at your own data, it’s like that word “customer” can almost be replaced with each of the things that people are using agile to make happier or to improve. I wonder if the originators of the manifesto had any idea when they were writing it that this was going to be applicable to so many areas?
Ben Linders: It’s difficult to look into the heads of the originators.
Noel Wurst: Right.
Ben Linders: I’ve met some of them and talked with them, and had some idea on what they were thinking about when they were doing the agile manifesto. My assumption is that I think some of them would have the idea that this could be applied much broader than just in software development. But, first of all, they saw the need in software development to address issues that were there; project was simply not delivering the products that were needed by customer, so they were not living up to the expectations. So, there was a clear need of something in there which made it much more interesting for them to originally target agile and the agile manifesto on the application of software development. If you want to do something like this, you don’t want to be implementing it in all kinds of different areas. You want to focus upon areas that you think there’s need in there and you can get the benefit out of it.
Noel Wurst: Right.
Ben Linders: I think that’s why they originally focused on software development. I’ve seen similar things, for instance, with the People-CMM model, which is an accompanying model for the CMMI and which is focusing on the management and human resource management within organizations. I’ve been talking with many people when we were working with the People-CMM model and they’ve said that what’s in there is not purely addressing a software need, but it’s addressing basic needs to manage people in the organization, be it software development or any other kind of product development or any other kind of knowledge work, whatever, or hospitals, the things in there would be applicable.”
Then, we got into the same discussions why is the People-CMM not being used in there, and the reason I hear mostly because people don’t know it. I’m having the same similar discussion right now with the agile retrospectives that we’re working on, several people said, why only agile retrospectives because of things which are in there are also applicable outside of agile and could give benefits to other organizations. I think that’s true. I agree with that, but basically, there’s a need right now within agile and within software development to do something with this. So, let’s focus upon that and let’s get some benefits.
Noel Wurst: Exactly.
Ben Linders: These are much broader.
Noel Wurst: Right. I was going to say that I have a little bit of a pro-cloud computing bias working with Skytap, but one my favorite aspects about the cloud from what I’ve seen, but agile as well, is that there’s this collaboration that just comes naturally from both. With agile, it’s focusing on getting dev and test teams together to work together for this common cause and a lot of the aspects of the cloud enable that by making these environments sharable to maintain. It kind of makes it, I think, eventually, I don’t believe that agile or the cloud are going anywhere. It almost seems like eventually, they’re going to go so hand in hand that you almost, not that you wouldn’t have one without the other, but that it would be kind of pointless to do either one without the other. I was curious if you see a similar kind of cohesion between those two.
Ben Linders: I certainly see cohesion between the collaboration, which is key in agile, both within agile team but also the collaboration with customers, the collaboration with managers in the organization, with the stakeholders in the organization. I think collaboration has lot to do with exchanging information and making sure that people know what’s happening in there. Collaboration also has to do with collecting feedback from people. I think tools which are there right now in the cloud, all kinds of facilities that are there in the cloud are helping people to collaborate, to get feedback on products, to share things much earlier than they would have done normally because of the usual way to do it, basically. I think, in that sense, I think the cloud computing and the facilities available in the cloud are helping collaboration, and in that way, are helping people to become more agile in there.
Noel Wurst: That’s true. You’ve got that collaboration made a little easier by having these environments be able to cloned and shared, and that kind of thing, but you brought up the feedback, which I would say, maybe the feedback is probably something that you do still have to remember to do on top of sharing these environments, these development and testing environments for mobile apps and enterprise software and all those things, but you do still have to give that feedback after you’ve shared this stuff, which, I know a lot on our blog and some of the writings that you’ve done that you focus on retrospectives. That’s something that I’ve written about in the past and kind of like those who haven’t yet done agile or haven’t tried it or have some skepticism about it, I’ve always found it really interesting—those who either don’t want to do retrospectives or they think that they don’t need a retrospective at this stage in the SDLC, whether it’s at the end, or the product hasn’t been fully deployed yet. I was curious as to what reasons do you think people have or did people think they have for not needing retrospectives?
Ben Linders: If I look at the teams that I work with and reasons I hear, and the reasons I hear when I’m talking with colleagues, retrospective facilitators being scrum masters or agile coaches in the organization. One of the reasons I hear is that people say, “Well, we don’t have the time to do them. We’re so pressed with getting the product out of the door. We’re so pressed with doing all the work that needs to be done and we don’t have time right now to sit down and do a retrospective and do some actions coming out of that.” First of all, I think the statement alone is very valuable because it also makes way that people say, “Well, if we do a retrospective, there will probably be some things that we find in there that we want to change in the organization.” If you don’t feel that there’s any room to do changes, then why do a retrospective?
Noel Wurst: Right.
Ben Linders: I’ve seen changed programs which came up with gazillions of things and largely a list of things that need to be done in the organization just to find ou that there wasn’t any room to do any improvements at all or just a little bit of them. I prefer to re-focus upon doing small kind of improvements and doing them continuously. That’s giving more benefits in the organization. One of the things I tell to people that just say, “We don’t have time do that,” then I ask if they’re familiar with the concept of technical debt and most of the teams are and say, “Yeah, we’re familiar with that. We know that if we take shortcuts in product development, that we’re building up technical debt and sooner or later, we’re going to have to repay that and we’re going to have to go into a discussion with our product owner to say that we need to do things differently, we need to change the architecture or we need to clean our code because of the technical debt that we’ve built up is hampering us in doing our work.”
If you look at retrospectives, you got a similar concept in there which you could call process debt, because if you’re not changing your way of working and if things keep on bugging you, you keep on running into the same problems in the organization, then you’re also building up a kind of debt which is hampering you, or which is going to slow you down. So, sooner or later, you need to take time to clear those debts and to address that, and that is where retrospectives come in. What I always try to do with teams that say, “I don’t have time to do that,” I say, “Well, is there any change that you think is needed because you are having a problem right now and let’s see how we can do that in the least amount of time that is needed for that,” both to be investigated and both to do the actions, instead of bringing on large scale retrospectives into the organization.
Noel Wurst: Yes.
Ben Linders: I think another reason that I hear from people who say that they don’t want to do retrospectives any more is if they’re doing retrospectives in a similar way throughout the project because then, sooner or later either of those retrospectives are going to be turning into dull sessions or they’re not going to find the right improvements or actions out of that because the teams have changed and have matured. Those teams I always advise to do a retrospective in a different way. There are tons of ways to do retrospectives and that is actually the thing that the upcoming book of mine on getting value out of retrospectives will be addressing; by giving different exercises, how you can do those retrospectives and by just taking a different exercise, you can get much more value out of the time you’re investing in the retrospective.
Noel Wurst: That’s great. You mentioned being able to do them in different ways and I was curious to ask you as well, do you feel that a retrospective should involve … do you think there should be separate ones for maybe the developers or maybe ones for the developers and testers, ones that involve everyone including IT, as well? Do you see more benefit from having retrospectives that involve everyone, or smaller ones who maybe don’t involve everyone every single time? I was curious, you mentioned when people say they don’t have time. I would imagine that some people feel like, “Well, if we bring in IT or if we bring in the testers also, it’s going to make it too long or it’s going to make it longer than we have time to do.”
Ben Linders: What I usually see in the organizations is they need a combination of that. They want to have retrospectives primarily to focus upon the teams that are working together on a day-to-day basis. Usually, those retrospectives just involve the technical people, the designers, the testers, the scrum master from the team, and most of the time, the product owner is not attending those retrospectives because there’s enough there for the team to focus upon. But if these are issues that the team is dealing with, which involve the product owner or any of the stakeholder that they have in the project, then I think it’s interesting to do a retrospective and involve them in there. Usually, if the issues are there and you go to your product owner and say, “We want to work this out,” or “We want to solve this,” then those product owners usually want them to make time for that because they also want to have those problem solved.
Noel Wurst: Absolutely.
Ben Linders: What I’ve also seen is that if you’re in an agile project which involves multiple teams into your project, then you it would be very interesting also to have a retrospective of retrospectives. We can usually do one when you release a new version of your product, so, say, something like every two or three months, and then you would sit together with people from a different team looking on how you can use improvement from different teams and do them on a larger scale into your project or what you can do to really improve your delivery, your release of products at the bigger level in your product. So, I think a combination is valid. If the organization teams are new to them, then please start with the retrospectives in the teams and build up on a level of trust and build up a level of empowerment within the team, so the people find out that they are able to change the ways in doing things in the teams and are able to change their way of working in there, and then scale them up and bring in other kinds of retrospectives in there.
Noel Wurst: Do you think that there’s ever a hesitation from companies to do retrospectives if perhaps, maybe, I don’t know, not everything goes well on every single project? But, I’ve spoken to people before where they say that sometimes they find some hesitation where if they don’t feel like any major problems came up that they think this last part rather went really well and let’s just do the next one exactly the same, and there’s not, you know, we don’t need to have a meeting because there’s not going to be a whole lot of changes necessary.
Ben Linders: I think it depends a lot of the culture of the organization that you’re in. Many organizations I’ve seen which really have a culture embedded in there that they want to be the best in a certain area, they would be focusing in the retrospectives also up on the strengths. They want to know what went well and they want to exploit that in their next iteration and they want to get better in that. I’ve actually worked with some managers actually who told me that I shouldn’t be working on my weak points but I should be working on the strong points and getting stronger in that. Then people would have to live with a few weak points that I would have, and I think that can be the same for teams. They can even get better if they focus on the strong points that they have in them.
So, it depends on the culture of the organization and the importance of really being the best in a certain area, in a certain way of working, then those retrospectives would have value. I’ve seen several teams where doing the … even the basic questions, like, “what went well,” “what could be improved,” “what did you learn” and “what’s puzzling you” brought out issues that they could improve things that they were already very good at, but which are really bringing them benefits in the next iteration. So, those teams benefit from looking at strengths that they had and become stronger in that, instead of looking at the problems that they had.
Noel Wurst: That’s true. I was just thinking that as you were saying that those teams that are “doing so well” and had so few problems, are probably having retrospectives that’ll contribute to their success, so there’s probably not so much hesitation to have them when something went really well because more than likely, they’re not going to go really well unless you’re having those retrospectives along the way.
Ben Linders: Exactly. Exactly. I had one team where I did a retrospective. Actually, it was a project we’ve just taken, not really an agile iteration retrospective, and first I, in retrospective, mentioned that we were surprised that they were able to finish the previous project on time because when they started, nobody believed that they would be able to do deliver on time.
Noel Wurst: Right.
Ben Linders: But then, they started the project and said, “Well, we’re going to do it anyway because we don’t want to lose any time debating and getting another month, and we’re not going to get it anyway.” We did a retrospective focusing upon what’s made it possible for them to deliver on time, how they managed to do that, and what were their strengths, what were their skills and the values that they had as a team to do that. By making that visible within that retrospective to the people that were in there, they’re able to use that in the projects that they were working right now and improve the ongoing project by just reflecting back on how they managed to do the previous one on time.
Noel Wurst: That’s true.
Ben Linders: They’re reusing their strengths.
Noel Wurst: Yeah. That’s great. That’s fantastic. Thank you so much for speaking with us today. Again, everyone this is Ben Linders. He is an independent consultant, but focuses on the areas of agile, lean, and process improvement. Ben, if you wanted to share your website and blog with everyone, I know I’m a huge fan, there’s a lot of good information on there.
Ben Linders: Okay. Take a look www.benlinders.com. There’s lots of information in there on becoming agile, lean, doing process improvement in there. We’re working right now also on releasing our first book on getting value out of agile retrospectives.
Noel Wurst: Great. Thank you so much again.
Ben Linders:
You’re welcome.
