Well, actually, if you look at evolving Agile we are reflecting back on what has happened with Agile, from how it started and a lot of Agile started already before there was an Agile Manifesto. So, it started years before that. To see how things have been working out in the Agile world, we are reflecting back on what kind of practices are in there, what kind of methods have come up, how have people been deploying Agile in the world and where it has been successful and where not. We had to look back on what we can learn from this. I think there is still a lot to be learned, even though there are about 13 years now having the Manifesto in there. There is still a lot to be learned and we still are learning every day from better ways to do Agile practices in organizations.
3. Any highlights for you from the sessions that you are coming on that track?
Some of the highlights in there is, I think, a renewed focus on technical practices. I think some of the organizations have been focusing too much on the processes part of Agile and looking at implementing the processes in a more or less technical way. I think it is also important to look at the people aspects and look at the technical aspects – how people are working together in organizations and what kind of technical things they are deploying, what technical practices they are doing in organizations. I think that this is what makes Agile work. At the end, it is about developing, building software, building high quality products and technical practices are important in there to do that in organizations. And I think there is also the people stuff which is still very important, that is looking at ways that people are collaborating in organizations, looking at ways that people themselves are able to look at the way that they are working and find improvements in there and continuously improving themselves. I think that is very important in Agile. And I think that is still not sufficiently recognized in there.
Shane: Now, I happen to know that one of the areas that you have looked at extensively is in helping people to examine their practices and examine their processes through the use of retrospectives. In fact, you have written a book about retrospectives.
Yes, that is right. I actually wrote a book about retrospectives and I did it together with Luis Goncalves. It is a book which is mainly focusing on the exercises of the retrospective. So, we collected a couple of exercises in there and we aim to help teams all around the world to find better ways to do retrospectives. And we have actually been doing a lot of translation work on that also, with teams all around the world. There is paper edition already in the Dutch and French version, but there are much more languages in there which are available because our aim is to help teams all around the world to find better ways to do Agile retrospectives and the best way to do that is to actually help them do exercises and to learn it in their own language.
Shane: The book is also available electronically as a download from InfoQ, too.
That is right.
4. What are some of the problems that the teams are facing that good retrospectives can help with?
I think some of the main problems that teams are facing in there is the way that they do those retrospectives. I still hear from a lot of teams who just have found one or two ways to do retrospectives and they keep on doing retrospectives in the same way. There are two problems with that: one problem is that they are not really finding good new actions in there because they are reflecting in a similar way time after time. The other thing is that people tend to find it boring to do the same exercise over and over again. So, they say: “OK. This is not helping us and we are not finding good improvements in there” So, then they wonder “Are they valuable and why are we doing them?” So, I think the trick in there is to try out different exercises and if you have a good facilitator, the facilitator knows which exercise to pick depending on the situation at hand, depending on where the team is, depending on the potential which is there to look in there. I think there is also a second thing in there which is something that teams are struggling with, that is a facilitation of the retrospectives. It takes different skills to facilitate a retrospective. It is about communication, it is about reflecting back and seeing how things have gone in the equation and how things are going in the organization and helping teams to really explore. A good retrospective facilitator also needs to sense the meeting and sense how people are doing in there and then, by simply seeing what is happening in the meeting, knowing what to do to get the best out of the teams and I think facilitation is still something that not many people are really good at. Actually, if you look at the Agile training, it is not really taught in there – there is some mentioning there that we should be doing retrospective and then they give a standard profile in there, but there is not much in any Scrum course, unless you are really doing an advanced form of facilitation. I think this is what makes a difference in retrospectives.
Shane: So, if we think of Scrum, facilitation should be one of the core skills of the person in the Scrum master role, for instance.
I think it should be and I think that it should be in the Scrum master role or perhaps if teams are starting up, maybe in the Agile coaching role, because initially, the Scrum master is also learning to work with the teams and to find a way to support the team in there. So, when the Scrum master is trying to find their own way to do the work and is also facilitating the meeting – that can be quite challenging. So, initially, I would even propose to have an Agile coach sharing the retrospective meeting or bring n an external facilitator or a Scrum master from another team perhaps, so that the team can focus on the whole collaboration, including the collaboration of the Scrum master with the team members or with the product owners. And once team gets more developed in there, then there is something that the Scrum master can do. And if there are more advanced teams – I have worked with teams in which basically everybody could pick the role of the Scrum master and we would rotate facilitation of the retrospective. We didn’t have a real Scrum master, anybody could do it. When we did the retrospective, we would just agree who would be facilitating that one and do the meeting, because everybody would have the skills to do it. So, once you develop the skills, they are much more flexible in there.
Shane: So, becoming true cross-functional teams and Agile maturity and so forth happening.
It is cross-functional, but there is cross-functional in a different way. Usually, if you look at cross-functional, then people would say “OK. We would need to have some developer skills in there, testing skills in there, somebody who has a feeling for explaining the business part in there and then we are looking at Dev Ops.” If you are looking at cross-functionality from a retrospective point of view, you look at some social skills, communication skills, reflecting, really trying to figure out what is happening in a team- that kind of skills. And, usually in teams, there are people who have those skills. There are, but you need to develop them further and you need to make sure that those people would then facilitate the retrospective and that they are really focusing on the meeting. I also think that the person who is facilitating the retrospective should primarily be focusing on doing a good retrospective meeting, finding out what happened, discussing that and finding out which actions to take in that situation with the team. And they shouldn’t have a stake in what kind of action that will be – they will be purely focusing on the process and on having a good retrospective meeting in there. And that can also be difficult if you are also a member of a team, because they might have their own opinion.
Shane: That neutral facilitator to help the team come to valid conclusions in their own context.
Yes. I think this is the focus on how really helping the team to find the things which would really be helping them to improve at this point in time, where they are right now. So, it is not that much the neutrality, but it is really being focused on getting a good outcome from the meeting. I think that this is what makes a difference in there.
Well, there are different exercises in there. Actually, things like the sail-boat are in there which is familiar to a lot o people, but then it has been extended with an anchor also to see which things which are blocking teams. By the way, a sail-boat could also be a very good exercise start off for the team, even before you did the first iteration to put a goal in there. Another thing in there would be a constellation and which is an exercise for teams which are a little bit reluctant to talk about things, because initially, in the constellation, you would do it silently. People would just take a position based on questions and then they would reflect on the situation and see what is happening in there and that is when the discussion starts. Another thing is the retrospective of retrospectives, which is something that you can do in projects where you have multiple teams and where teams can learn from each other by looking at what things have come up in other teams and would it be something that will be beneficial for them and also could align their way of working, for instance, working towards deliveries in projects.
There are all sorts of exercises in there which teams can use and there is some supporting material in there looking at the benefits of retrospective and the business value that you can get out of retrospective. We put one chapter, just one tiny chapter on introducing retrospective in the organization. We did not want to do too much about that. There are other books which are covering that. We really wanted to focus on the exercises and to have hands on materials for teams to start working with this.
Shane: So, practical tools.
Practical tools that they can read and that they can do in the next meeting. It is actually also what we see happening. We see people getting the book and then one or two weeks later, we get a message back saying “Hey. We tried this exercise. This is how it worked out for us”. And I got a couple of blogs already on my own blog from people who have been using the exercises, describing how they did it and how it worked out for them. So, there is great feedback that we are getting.
I think that one of the things that Agile teams are struggling with is really finding how much they are allowed to change in the organization and to self-organize. I mean, that is a difficult thing for teams. Most of the teams are not used to being self-organized in the organization. That is not a culture there of self-organization so they are trying to figure it out and what I see happening in some of the organizations is they just switch over from one way to the other, from being a very controlled, command and controlled organization to saying “OK. …...We are self-organized, so go figure it out for yourself”. And teams can do that. They really have to develop the skills to self-organize and to find a way to do it in there and that is something that they need some help in there, to be able to do that. I think teams are really, really struggling with finding their autonomy and finding out what are we allowed to do and what are we not allowed to do and this is something where, I think, the conditions for teams should be getting much more emphasis in the organizations to really help them to get started.
7. What are some of the things that organizations can do to support teams in there?
Well, I think that first of all, they can be very clear on things. So, if they say: “These are the borders within which you, as a team, have your autonomy. This is something that we expect from you and this is the amount of self-control that you are having and if you are going over this border, then consult with us”. So, I think that is an easy thing to do in there. I think there is also accepting that if you want your teams to be Agile and to be changing, I think as a management, you should be doing the same. So, I think that it is important for management to be in constant contact with the teams and if teams are finding barriers in the organization, some way or the other, that they can go back to their managers and say “Hey. This is something where we need some help from you. We found a barrier here. There is something in the organization which is blocking us and you want us to be Agile, you want us to do things. Please help us to remove this barrier in there” So they should be supporting the teams in there and helping them to remove those barriers in the organization. I think the other part is really focusing on the business part and making clear what is the goal, what the aim is that they expect from their teams and they look with the teams on how they can be contributing to that. So, instead of telling them what to do, telling them what is the aim that they should be working at and help them to clarify anything that they have questions about.
Well, the technical practices – I think the challenge in there is to really develop them and to have developers talk about their technical practices. They are used to doing that, but they find it difficult to exchange their experience in there and they are used to working on their own in many cases. So, I think it is creating an environment where people feel safe to talk about how they are doing their work and to discuss that with their co-workers. And it can be something as easy as doing a lunch session or a brown-bag session where people tell how they do certain things in there and to exchange that with each other. I think that is the kind of things that an organization should be facilitating and helping developers with.
Shane:We come back to that very, very first value of the Agile Manifesto – individuals and interactions.
That is true. The action is in the collaboration. Actually, you are having a team of people and the better people in teams can collaborate and work together both in the team and as a team with their stakeholders, the better the result will be. So, I think if I look at the things that I see coming out any continuous improvement action whether it is a retrospective or a root cause analysis or any other way that you look for continuous improvement, even when I was working with CMM & CMMi, it usually had to do with communication and collaboration. So, if you focus on that kind of thing; you focus on giving people the skills and setting the right culture for teams to improve, then it will work out.
Shane: Great. One last thing: one of the hats that you wear is an editor on InfoQ. Tell us why you are so engaged there because you produce a tremendous amount of content for us.
I think the engagement comes from being willing to share knowledge, but even more, willing to share experience with people all around the world. And this is something that I have been doing basically all my life – I have been looking at ways to improve and I think knowledge and experience is something that helps people to improve in there. So I have been doing this in the teams that I work with, to help them to reflect and to learn from each other. I have been doing that in organizations to look at knowledge sharing sessions in there, I have been sharing the Dutch network for Software Process Improvement for four years, looking at how we can help the industry in the Netherlands and even abroad on finding better ways to do software development. For me, InfoQ was the next natural step to do this and to share experience in there. If I look personally, what I like about InfoQ is that I get to talk and to work with people who have great ideas on how we can do things and challenging ideas, in some situations but, really ideas to say “This is how we can do something in there” and InfoQ really opens doors to talk to people all around the world, to hear about those ideas, to learn about that and then to share it to the community and help other people around the world to find better ways to do things.
Shane: Great. Ben, thank you very much. It is always a pleasure to talk to you and enjoy the rest of the conference.
OK. Thank you very much for having me here.