Conflict Management in Distributed Agile Product Development

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today I'm sitting down with Dr. Ashay Saxena, who is a researcher at IBM. Ashay, welcome. Thanks for taking the time to talk to us today.

Ashay Saxena: It's lovely talking to you, Shane, and I'm always happy talking to InfoQ audiences.

Shane Hastie: We appreciate it. Now you and I have met before, but there's probably a fair number of our audience who haven't come across you. So tell us a little bit about your background, who's Ashay?

Introductions [00:34]

Ashay Saxena: Sure. So for everyone, I'm Dr. Ashay Saxena. I hold a doctorate in information systems from Indian Institute of Management, Bangalore. Currently, I'm working with IBM. I'm working as a product owner, so a large part of my responsibilities are looking at agile projects, looking at enterprise transformation, which is done in an agile manner. So there are elements of research that I conduct at IBM, but predominantly I perform my role as a product owner with IBM. And apart from that, I'm a regular at conferences. I love to talk about agile, discuss agile with people across the globe. So I'm quite regular at some of the practitioner conferences as well as academic conferences. So that's something that I do more as a hobby.

Shane Hastie: So one of the items of research that caught my eye is some work you did around conflict management in distributed agile product development. Tell us a little bit more about this. What was the background to that research and let's delve into what came out of it.

Ashay Saxena: This was a fairly long research project which was carried out during my PhD and we ended up publishing a journal article. So the journal article came out last year in Information Technology and Management, which is a springer based publication. And there's been a lot of appreciation coming from the community around what this research was all about.

Research on conflict management in distributed agile product development [01:54]

In a nutshell, we were trying to study distributed agile projects. So this was about looking at large software development efforts that are executed by global MNCs. And what we were trying to study was pretty much agile and distributedness from first principles. So as all of you're probably aware, agile talks a lot about embracing change. Embracing changes in requirement so that there is more business value that can be delivered for customer. So there's a lot of flexibility that agile demands from the teams, whereas if you think about distributed teams, there is a need for stability in any distributed setting.

So predominantly teams require clarity in terms of what work they're doing. They want a big picture project definition of what they're focusing on, and they pretty much want to cast things in stone before they start out on their project work. So as you hear me say this, I'm sure you're wondering this isn't direct competition. There's a conflict that we are talking about. agile is about flexibility, distributedness is about stability, and when these two come together, the research was all about understanding this conflict better and then obviously what can companies, what can managers, what can any agile team member do to balance this conflict, so that project can be delivered successfully. That's the research in a nutshell.

Shane Hastie: When you say distributed, this research was completed shortly before the pandemic, but I'm sure a lot of the context is still valid, but what was your definition of distributed for the research?

Ashay Saxena: That's a great question. It's important we clarify what was distributedness for our cases. So for us, distributed teams stood for something where teams are co-located at a given site, but they're distributed at a project level. So for example, there could be a software development effort that is spread across India, New Zealand and somewhere in Europe. And then you're looking at say three teams that are based in India, a couple of teams that are based in New Zealand and a couple of other teams that are based in say France.

At a project level, you're looking at seven teams that are working on a project with a split across France, India and New Zealand. So that was the definition of distributedness where teams are co-located at a site, but they're distributed more at a project level.

Shane Hastie: So many of our audience will be familiar with working in that type of environment. Today I would say more of those teams would not necessarily be completely physically co-located, but time zone co-located and working remotely. And again, from your research perspective here to get the other dimension, what are the characteristics of agility that you were looking at?

Dimensions of distributed agile development [04:39]

Ashay Saxena: From an agile perspective, for me, any agile project, it's important that we are looking at how customer is involved in the software development effort. Again, if we go back to the agile manifesto, there is a specific element around customer collaboration being prioritized. So I was fundamentally focusing on what is the level of customer engagement on the software development effort. And pretty much there were two kinds of projects that I was looking at. One, where there is direct customer involvement, these are your services project where you have the client vendor a relationship where client is directly interacting with the vendor and trying to get the project completed.

On the other hand, I was also looking at indirect customer involvement. These are your typical product development efforts where the software development team doesn't necessarily talk to the end user, but there are market representatives who present that picture to the software development team. So these were the projects that we were looking at. One where we had direct customer involvement versus indirect customer involvement. To keep it simple, the research classified this as either product development or services engagements.

Shane Hastie: So we've got our agile teams with high customer engagement, rapid feedback, lots of learning, wanting to be able to change direction. So living in a space of fluidity, living in a space of learning, and then as you said, to work in this distributed way wanting more of that stability of that certainty. What conflict does that bring to the team?

The conflict between flexibility and stability in distributed teams [06:15]

Ashay Saxena: You got it right Shane. We are looking at this flexibility and stability as a fundamental conflict in any distributed agile project. This research tried to explore the nuances of this conflict. So when I spoke about these dimension of agility that we were looking at, we were also looking at a certain dimension of distributedness for the project, and that was more around the configurational dimension of distributedness. So either teams could work in an autonomous way where teams said that look, at a given site, we like to operate in a self-contained mode. These are more the feature teams as the software industry talks about, or the distributed teams could be working in an interlinked kind of a mode, which is more the component teams. That's a classic term that people talk about.

So we were trying to look at this kind of a two by two in a research matrix, but on one hand you have your agility dimension of product development versus services and on the other dimension we were looking at autonomous teams versus interlinked teams, and I looked at pretty much cases across this grid to understand the conflict better. Now when you asked me how was the conflict different, it varied across all of these dimensions. Just to give an example to the audience here, from an agile perspective, when I say direct customer involvement or services project, we observed that software teams had a more committed handling of any changes in requirements, because you are looking at a customer who is pretty much involved in the entire development activity.

Whereas, if I cut to indirect customer involvement, the product development that we are looking at, their teams were more focused on absorbing changes up to a feasible extent. So for instance, they're working on a next version of a product that has already been released. Now they will focus on what is the timeline, how much change can we absorb? And there will come a point where the teams will say, no, saying that, look, we can only absorb X amount of change for a certain duration and then we'll come back to the next set of changes after we release the next version. So fundamentally, the way the dimensions were, the conflict started playing out slightly differently.

Now if I bring in the distributedness angle, suppose let's look at the autonomous teams, then that is where teams wanted to work in a self-contained mode, and at the same time they had to absorb changes in requirement. So we observed these nuances in the way conflict was playing out.

Shane Hastie: So the conflict is there, the pressure is there, and I'm sure that many of our audience will recognize the conflict, that pressure. What did the research find? What are the teams that are doing this well, doing?

The concept of contextual ambidexterity to balance performance and social elements [08:53]

Ashay Saxena: Exactly. So when I look at how can teams manage the conflict, and this is where there are a lot of interesting findings for agile practitioners, and I'm sure a lot of individuals who are listening to this will find it helpful. We looked at a certain element of ambidexterity. So ambidexterity is the answer to how do you handle this conflict? Ambidexterity, again, in literal terms stand for being able to use both hands to equal effect. There are individuals who are ambidextrous. This concept has been extrapolated at an organization level.

So for organizations to be ambidextrous, that's where we are looking at distributed agile projects becoming successful. So we looked at a specific form of ambidexterity, which is contextual ambidexterity, and that provided guidance on how teams were managing the conflict versus those who are not able to handle this. So again, I mean if I were to explain this slightly more, the elements we are talking about is in any project setting, there are certain performance elements which allows individuals, which allows teams to handle their responsibilities, and there are certain social elements which allows teams to handle cross-site relations. So it's a mix of both these things. When these performance elements blend appropriately with these social elements, that is when setting offer these ambidextrous approaches, which allows teams to manage the conflict and be successful.

Shane Hastie: So what are some of those things?

Examples of performance and social elements: role clarity and boundary spanning [10:20]

Ashay Saxena: I can give an example to explain this better. So let me break down performance and social elements a bit more. One of the performance element is clarity in role specification, like how are individuals categorized? For example, there could be a team where they're very clear roles that are defined. So there is a scrum master, there is a product owner, there is a developer, there's a tester, there's a QA person. All of these are well-defined roles that we are talking about. Whereas, there could be a setting where roles are not very clearly defined. So when I say developer, there could be multiple layers of developers on a team. There could be a senior software developer, there could be an entry level developer, there could be a technical lead. So these are all variants of a term called developer.

So clarity in role specification is a performance element, and that interplays with how boundary spanning is done, which is a social element. So for example, teams could say that, look, we give freedom to all our individuals to talk to individuals on the other side. Whereas teams could say, look, we don't want everyone to talk to everyone on the other side. We have a designated individual who talks to a designated individual on the other side to handle the dependencies, handle the coordination.

What this research found was, if there is complete clarity in the way roles are defined, every individual could be given freedom to interact with individuals on the other side. Whereas, if there is lack of clarity in role specification, then we do require designated individual who talks to a designated individual on the other side to manage the coordination, to manage dependencies. So this was one example of how the interplay was happening between performance and social element, which was allowing teams to manage the conflict.

Shane Hastie: So that role clarity coming into it. So you've explored, you've identified, you've seen things that work and things that didn't. What do we take from this? If I'm a developer, an engineer working in a scrum team, so what?

Advice for agile Teams and Technical Leaders [12:19]

Ashay Saxena: So what this research does is it provides guidance to individuals who are working on a distributed agile project. So this is not just about say managers. So this is not just about managers, leaders or coaches, but this is also about individuals who are working on a distributed agile project. The key takeaway for them would be they need to do some element of diagnosis in the current settings that they're working on. Because as I said, in any distributed agile project, there will be a fundamental conflict between flexibility and stability.

However, the way this conflict will play out, it is contextual. Like we cannot generalize it for any distributed agile setting. So the key takeaway for any individual working on such project is do some element of diagnosis, like how is the conflict playing out for a particular given setting? And then look at what practices that are being adopted by teams. How can they be done differently if the individual feels there are some issues that are being experienced if the project is not meeting the quality expectation or the performance expectations, then there are certain elements that can be changed in terms of how practices are being performed by individuals.

Shane Hastie: Now what can I do as a leader, as a technical leader in a team? Somebody who's putting these teams together, what can I do? What should I take from this?

Ashay Saxena: The way I look at it, that's the most ingredient block. If I'm setting up a team to work on a distributed agile project, I think that is the most important phase. If we can get that right, a lot of things that follow in terms of the process, practices, all of that can then be defined in a manner that the teams are successful. So if I am a technical leader who is trying to set up agile teams to work in a distributed manner, I do want to understand the context very clearly. Like what distributedness we are talking about. Is it the way I defined it for my research or is it something else?

So it's very important to understand what is the dimension of distributed teams that we are talking about, at the same time, how are we looking to practice agile? What customer involvement are we talking about when it comes to the agile element? Once a technical leader has clarity on both these levers, then the research that I have done that can provide some guidance in terms of how we can set up the practices. So there is a managerial framework that the research gives out which can be leveraged to look at practices. And again, I'm talking about managerial practices, not the technical practices, but for technical leaders to understand what managerial practices we want to put in place.

Shane Hastie: So let's go deep. What are some of those practices?

Ashay Saxena: Again, from a managerial practices standpoint, let me again give one example to make things simple. There is an element of time management of meetings. I mean, agile has a lot of ceremonies and there is this element of doing things in a time box manner. It could be your sprint reviews, it could be planning, it could be any agile practice that you're talking about. On the other hand, there's also this element of making work progression visibility for all the stakeholders. So there are these digital walls that we can talk about that could be, or the visual charts that we can talk about that demonstrate visibility of our work is progressing.

Again, one of the practice that I will talk about here is the interplay between both of these elements. Consider a scenario where teams are extremely transparent in terms of the way work is progressing. So if a manager or a leader decides that we want to be completely transparent across sites in terms of our progress on the work, that'll make it absolutely possible to have time box meetings the way teams are conducting it, because there's complete visibility anyhow. So there is no need for anyone to spend a lot more time on giving updates to stakeholders or even in terms of when the reviews are happening to go into a lot of functional details of how product is being built.

However, the other way practices can be looked at is where teams don't want to provide complete visibility in terms of how work is progressing. They want to keep it very much site focused. Then there's a need to be a bit more relaxed in terms of how agile meetings are being conducted, because there'll be a lot more questioning, there'll be a lot more probing around what work is happening, how are we progressing? So the coordination effort will increase. So in a nutshell, this is what the research talks about. Need for interplay between performance and social element, and this should drive the way practices are defined.

Shane Hastie: What other advice do you have for agile teams, development teams and thinking of the situation we are in today where a lot of the time the teams are spread around the world, but people are also distributed, they're working from home at least some of the time.

There is no one-size-fits-all solution for distributed development [17:03]

Ashay Saxena: I completely agree that I mean the world is changing. In fact, if there's one thing that pandemic has taught us is that we need to embrace change in terms of our settings. I mean there is evolution in terms of way the work gets performed. Coming from a research perspective, the one thing that I will want to say to any agile team, it could be any mode of distribution that we are talking about, hybrid, completely distributed remote work. But it's very much important to understand your project in terms of the dimensions that we are looking at. Because every project will have certain dimension of agility, certain dimension of distributedness. Whether it is fully remote, hybrid, or the way I define it as autonomous interlink. But the teams have to put in that extra effort to understand their context and then work with their managers, coaches to define the right set of agile practices which will enable them to be successful.

Again, I will go back to the state of agile report that comes out pretty much every year. The state of agile report 2022, it does provide a pointer on the success rate of say, agile being practiced at large scale, and the numbers are not looking that great. There are a lot of projects that are not being successful when practicing this distributed agile mode. And the way I look at it, the fundamental reason is that teams are trying to adopt a one size fits all kind of an approach. That fundamentally has to change. Teams have to understand it's a lot more contextual. We cannot pick certain practices from some other setting and adopt for our setting. That approach will just not work.

Shane Hastie: There is no one size fits all.

Ashay Saxena: Absolutely.

Shane Hastie: That's been our message for the last 20 years, but nobody's listening.

Ashay Saxena: The way I look at it, Shane, I will request the listeners to do spend some time looking at this research. Again, what I'm trying to do with this research is I'm trying to help people a bit more. I mean, without getting overtly prescriptive, this is not about telling individuals what they exactly need to do, but this is about allowing them to understand how to diagnose their context, how to go about setting up practices. So there are a lot of these guidance that are provided in this research, which will help individuals to assess their context and then set up distributed agile in a right manner.

And the approach that I have followed, this is completely from the first principles. So this is not about looking at any scaling agile framework or looking at any particular preexisting approach and then building on top of it. This is about agile from the first principles, distributor teams from the first principles. And then I've come up with certain recommendations, certain framework that allow teams to then assess their context and then set up the right practices.

Shane Hastie: Shane, some food for thought in there, if people want to continue the conversation, where do they find you? Where do they find the research?

Ashay Saxena: The research is publicly available. As I said at the beginning, this is published by Information Technology and Management, which is a Springer journal, which is very much widely read across the globe. The research is publicly available. I'm happy to provide a link to the audience so they can access the research.

In terms of where they can find me, they can find me any day on LinkedIn. I'm quite active on LinkedIn. All they have to do is type my name and I'm sure they'll be able to find me there. It was wonderful talking to you, Shane, and I've always enjoyed interacting or sharing my updates with the InfoQ audiences. I hope they find this research useful, and if they do go through this article, I'm happy to take any questions or engage in any conversation if anyone has anything to discuss.

Shane Hastie: Ashay, thank you so much.

Mentioned

• The published research paper
• Ashay Saxena on LinkedIn