All Things Agile - Episode 010 - Resolving Team Conflict

Welcome to another episode of All Things Agile. In this episode, we discuss the tough subject of team conflict. Whether your Agile or not, every organization is bound to encounter team conflict. We'll discuss how to resolve existing conflict as well as preventing it from even occurring.

I am also very excited to announce that the next episode will feature an interview with notable Agile author, Ken Rubin.  Ken is the great mind behind Essential Scrum. I hope you enjoy this episode and make sure you subscribe to catch the upcoming interview using this link: iTunes. Reviews on iTunes are also always appreciated. Do you have a question that you would like answered in an upcoming podcast? Please send your question to: [email protected].

All Things Agile - Episode 010 - Resolving Team Conflict

Transcript:

Welcome to the All Things Agile Podcast! Your destination for tips and interviews with the leaders in the world of Agile. Don’t forget to subscribe to this podcast on iTunes, and please check out our sponsor: TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.

Hello everyone and welcome to the All Things Agile Podcast! First off, I want to get started by issuing an apology for the delay in getting a new episode out. The reason why is because I have an upcoming guest and unfortunately, we are not able to get the scheduling worked out in time for this episode. But, I am pleased to announce that Ken Ruben, author of Essential Scrum, will be the honored guest in our next episode.

That said, I want to go ahead and issue another episode. I don’t want to keep you waiting too long – and with that, I hope you accept my apologies for the delay in getting this episode out to you. Now, before we begin, a quick reminder that this podcast is for informational purposes only and accepts no legal liability. So the topic for today will be ‘Resolving Team Conflict’. Virtually any team you will be working on is going to have some degree of conflict. It’s just part of human nature. You can’t all agree 100% of the time, even though Agile encourages more of a democratic approach to what the team is working on and the approaches that they use, there’s bound to be some degree of conflict on any team that you work on.

Now, before we dive into solutions to resolving team conflict, let’s first identify the different types of conflict. One type I think is just general healthy conflict and what really we’re referring to is debate. Using the word ‘conflict’ is probably inappropriate in this particular case. An example of debate, you may have people that share different ideas and solutions and what type of technologies should be used, or different coding practices, whatever. That’s fine. Having those healthy debates, discussing ideas, is actually a good thing. In this case, it allows you to have differing points of opinion which can be discussed, evaluated and reach an ultimate decision on. And that’s fine. That’s a healthy form of debate or conflict, if you will. And, if you have a little bit of that on your team, that’s fine and I wouldn’t worry about it.

What we’re really going to be focusing on in this particular episode, is unhealthy debate. And I would describe unhealthy conflict or debate as a case where it’s really impacting the team. Where it’s creating what I like to call a toxic environment. You can definitely tell it when you’re part of a team that’s having this because it just brings everybody down. It brings the morale down, and it just feels like the team has been poisoned, if you will. And you’re going to see evidence of that not only in the morale, but the conversation, the level of communication and collaboration are going to go down. You are going to see people that are going to be engaging in using a lot of inappropriate language. You’re going to have a lot of people getting into some sort of personal battles with each other or one-upmanship, and it just really destroys the overall team morale and ultimately, the productivity. And you’ll actually begin to see this long-term in the metrics where you’ll start to see a team that was doing really well, and then they start to perhaps have their velocity dip down and more and more of their stories are being accepted late, etc. So that definitely has an impact. I would definitely classify unhealthy conflict as conflict which is really bringing down the team. It may be disrespectful, and it’s simply just not in the long-term viability of the team. So that’s kind of how I would probably classify the two main types of conflict that I see, either healthy, just discussion of topics and technologies versus some things more personal and toxic. And so we’re going to talk about the latter and how do you resolve it?

Now, I have personally seen these cases come up numerous times in my career, and if you are particularly in a situation – your team or teams that you’re coaching or another team in your company that you’ve seen this kind of just not quite right environment, just a little bit toxic, that’s not uncommon. First off, it’s bound to occur on average. So that said, even though it’s a common experience within a company, you certainly don’t want to maintain that toxic environment. Because here is an interesting point that I have seen personally which is if one team is currently experiencing a level of poison, if you will – not only does that team’s morale drop and their productivity drop – it can spread to the other teams. It’s true.

You can have a team that is doing really well, but if their neighboring team is engaging in disrespectful behavior and yelling at each other, cursing at each other, it’s going to impact the neighboring team. They are not going to want to come in to work that day. Their morale starts to drop and then their performance starts to drop. So another reason why you want to deal with unhealthy teams head-on is because not only do you want to help that team, but you also want to ensure that the degree of poison really doesn’t spread to the other teams and disrupt them as well.

Alright, so let’s talk about some practical tips that I’ve personally implemented in the past and found beneficial. Again, every company’s unique, every team’s unique – you’re responsible for your own actions, but something that has worked well for me is to focus on the present and the future. Often times when you’re trying to resolve team conflict or coaching the teams through conflict situations, the team members may get too focused on the past and the things that happened. And, what I mean by this is that I’ve certainly seen cases where people get into paper trail battles. You know what I’m talking about? Where you have someone who has an email that they sent 6 months ago, and they bring it out. ‘Six months ago you said blah blah and now you’re saying this!’

So you have these people that hold on to every little piece of communication, every little email and their real honest reason why they do so is so that they can spit it back out later. And candidly, that’s not healthy. And when you really analyze it, those persons, those individuals are focusing their attention on things that occurred in the past, right? ‘Two weeks ago you said this; last year you did that’ and so they can get into a lot of negative debate, a lot of disrespectful behavior sometimes because they’re so focused on past hurt. And they’re not really learning to forgive and let it be water under the bridge. And they’re just holding on to that pain, and they’re then letting that disagreement, anger, and pain, poison the waters in the present and then going forward towards the future. And you don’t want that.

One of the first things I like to focus on when trying to coach a team is to – sort of phrase of the idea is: keep the water under the bridge and keep it there. Okay? Don’t say ‘Oh well, yeah, okay we can move forward’ and then the next week later ‘Again, I told you 4 months ago that this is the way we’re supposed to do it’, etc. And again, that leads to that negative behavior if you’re always bringing up the past. And so whenever I’m sort of involved in trying to coach a team, I try to think about staying present, right? Think about: never mind the past, whatever happened in the past has already happened – we can’t get back into the DeLorean and go back in time and try to fix it. So in that case, what can we do right here, right now? Stay focused and present. And if you’re speaking with them and they start going ‘Well, what about that 3 months…?’ just say Stop! Stop. That was in the past, we can’t change it – what we can change is the present, let’s focus on that. And it’s not easy to do, but try to hold a hard line on that. Just say ‘That’s in the past, let’s learn to forgive and put that behind us and carry on for the present and the future.’

Now, if you can work on that and allow the team to avoid getting into those negative conversations about the past, then I’d say the next step is to focus on what actions or changes they can make here in the present to avoid future pains. So, for example, if part of the past pain was say, for example, some of the defect procedures were not being followed, as an example, and people were complaining about it with each other about whose fault it was – this person didn’t follow procedure and they should have, and someone has a paper trail from 6 months ago. To avoid that situation, I would say: Identify what changes could prevent that problem from happening again. So, for example, you might do six sigma root cause analysis, if you will and say ‘Okay, what really happened? Why was the process really not being followed?’ Well, maybe one reason is because the tool being involved wasn’t adequate enough. Maybe you just need to upgrade your toolset, maybe there’s some other procedures that can be added. Maybe someone needs to go through some additional training or maybe involvement with another team can be changed or improved. Or another team member’s schedules can be altered to allow them greater flexibility in the work schedule. Whatever the case may be, but the point is this: don’t dwell in the past, it’s already happened, okay? And then, for being able to resolve the team conflict, identify actions or steps that can be processed right here, right now and able to prevent that future pain.

In terms of where it’s a little bit more personal – that does happen sometimes, where you have teams that for whatever reason, people harbor personal grudges towards each other, and even if all of your policies and tools and procedures are all well and good, some people may, simply put, just not like each other. It certainly can happen. Again, most of the time, teams will be okay with just changes in their practices. But, there will be cases where people just simply have personality clashes and where I’ve seen that in the past – if it’s really that strong, I would say it can be sometimes worthwhile to go ahead and switch some team members around. There can be cases where, for whatever reason, those overlapping personalities just bump up against each other just a little too strong, but you can take that individual and perhaps shift him to another team, and he’ll work perfectly well there! Because at the end of the day, all team members are not equal. We each bring our own level of skill and personality and really, you don’t want everybody on the team to have an exact mirror copy of each other, in terms of skillset and personality. You need that diversity because it helps produce a more well-rounded and ultimately balanced team.

If one person, for example, is a little bit more thorough and another person is a little bit more sort of quick to act, actually having them on a team together can sometimes help because the person who’s more thorough will help balance the other individual out and ultimately, you can end up with a sort of a middle ground which is actually pretty well and functional. However, if you have those personality clashes where perhaps you have two individuals that are for example overly thorough and they may be bumping heads with each other, maybe that person belongs on another team and maybe there’s another team out there who needs that type of personality and skillset and they may actually be a welcome addition.

Now, it is kind of like a last resort to implement team member changes to shift the morale, but it is certainly better to do that than to let the team continue in unresolved conflict. And I know it takes a little bit of guts to go ahead and to talk to people and say ‘You know, I think we need to move you to another team' but you got to think about the overall team and the overall organization with the other teams. And again, if you let this team remain unhealthy or toxic, it’s going to spread to the other teams and you certainly don’t want to do that and that’s not fair to the other teams, to have that happen. So, again – I always start first by avoiding getting into the past trauma state, focus on the present, evaluate what options can occur in the present, changes and practices, etc; they can be implemented to prevent future pain and if it is a situation where it’s kind of a deep personality clash more so than the practices, there need to be team member changes. And that’s okay, and that does happen – I have certainly seen it happen in other teams as well as my own teams before. And that’s okay – in a larger organization, it’s bound to happen sometime.

I would say, kind of like an ultra-last resort, I really hate to see situations where a team member is removed from the company. That has happened, I have seen it happen, but that is such a last resort action and I would certainly encourage any Agile professional that’s trying to help a team experiencing conflict, that they truly keep that as an absolute last effort action. And the reason why it’s because it’s my belief that it’s easier to coach and maintain than it is to replace. Whenever you replace a person in your organization, you’re incurring cost not only with recruitment, but also with the interview process – people have to take time out of their days just to interview the guy or girl – but you also have to consume time with training and getting them up to speed and having them learn the culture and the ins and outs of the team, team practices or they may be new to Agile and you have to train them with that. So all that process can easily take a couple of months. And in doing so, the team’s velocity is already impacted. So I personally recommend, whenever possible, try to coach through the situation and reach a solution, rather than simply just throwing in new bodies. That’s my experience and that’s my belief. So, again – this is sort of a fourth option there, kind of last resort.

But those are the strategies that I’ve employed to try and resolve team conflict and that’s a conflict once it’s already occurred. And I’d actually like to take a moment and cover a different topic which I honestly think many Agile professionals don't even consider, and I haven’t seen it mentioned too much in articles or books, and that is preventing team conflicts. The material I just covered a second ago is in relation to resolving team conflict once it’s already occurred. But, the old adage is that an ounce prevention is worth a pound of cure. So you might ask yourself: how can we prevent team conflict from ever even occurring?

I’ll offer, I’d say about 4 suggestions that I believe, if you can implement them, they may help you. I’ve certainly seen them help teams in the past. The first is co-location. When you’re able to bring the team together physically, like they’re actually physically sitting next to each other, it often times helps prevent team conflict. If you have teams that are composed of a lot of full-time remote members, it can be difficult to maintain a healthy team. And the reason why is because of the bandwidth of communication. And the highest bandwidth of communication is face to face, where the person can see the other person’s gestures, the tone of voice, etc. And if they’re remote too much, then you’re doing a lot of email, a lot of IM chats, etc. and it’s so easy for the words to get misinterpreted, to get lost in translation. And so, in that case, it’s just bound to result in team conflict eventually. So if you can co-locate the teams, and I mean physically co-locate, like in the same office area, that really helps with being able to reduce the chances of team conflict ever occurring.

Second way I’d highly suggest is in how you treat the team members. And what I mean by that is this: if you have a team of let’s say 7 members or whatever, and one or two of those members are always favored upon by management or leadership and always listens to those individuals and nobody else, or those individuals get included in all the important discussions and meetings and nobody else does; they’re the ones that always get promoted, that receive a healthy salary and everyone else doesn't– that’s bound to create team conflict, right? But if you can really look at the team as a team, and comprised of many different people, each bringing their own value and contribution to the team, that will significantly reduce the chances of team conflict from ever occurring. Because you’re reducing the likelihood of people feeling disenfranchised or left out. Or disrespected. So if you can prevent that – again, it’s a lot easier to prevent team conflict than it is to fix it once it’s occurred, right?

I would say that another way to help resolve team conflict is through training. I’ve seen so many times where Agile teams are just thrown together and the training aspects is never really fully delivered on. Even though it costs a couple of thousand dollars, it’s far worth it to ensure that your team gets off to the right start. You want to ensure that, for example, all the Scrum Masters become, in my opinion, Certified Scrum Masters, Product Owners become Certified Product Owners – again, these are my experiences; your actions are your actions. But that’s my personal opinion – when you’re able to have those individuals be formally trained, it really does help because they learn the right practices, not just the way that the companies or organizations are currently operating. And that’s important!

I also recommend having all of the team members receive some sort of Agile training. Again, it enables them to have buy-in, and enables them to better understand the changes being implemented and why, for them to really see the benefits. If you simply throw people on an Agile team without adequate training, I think you’re setting yourself and the team up for failure. Don’t do it. Even though there may be some costs involved in training, it is absolutely worth it to do so because the longer term cost of not giving them adequate training and education will be ten times worse or even more than the cost that could’ve just been handled up front through adequate training. So I definitely recommend doing that. Don’t skimp on training and coaching and that’s not some ad or something for my own benefit. I mean this sincerely that I have seen teams and organizations that did not train adequately and I’ve seen others that did. And it’s a night and day difference. And again, by doing that, you’ll help prevent the team conflict from ever even occurring, and that’s certainly something you want to do.

The fourth thing that I would like to throw out there, a suggestion again to prevent the team conflict in the beginning, is how you form the teams. Who’s on the teams and in what roles or capacity? So many times I have seen team conflict occur because the team members are just thrown together. Look at a spreadsheet, get some names, throw them on a team. That’s simply just not wise. You need to really examine the skillsets and the personalities. Who’s got a strong personality? Who’s going to be the person who’s going to challenge the status quo? Who’s the person who’s going to be a negotiator? Who’s the person who’s going to help bridge different people together and help people come to a consensus?

Finding out those personalities and the skillsets, including development and maybe testing skillsets, finding out those individuals and then seeing how to craft them into a functional and balanced team really pays dividends because they are far less likely to have conflict. They are going to be able to work with each other and compliment each other. If you just simply throw people together in a team, you’re just asking for conflict. And not only that – but if they’re not balanced properly, if you look at for example the work each member’s contributing during a particular sprint or iteration, you’re more likely to find that the workload isn’t very balanced and that’s usually because the team’s not balanced. They’re not properly structured. So prevent the conflict in the first place by investing time to ensure that from all the people you have across the organization, that you’re really analyzing their skillset and personalities and putting them together and positioning them to win, right? If you’re just throwing the bodies together into a team, you’re just asking for failure and conflict. If you invest the time – and really, how much time does it take, folks? A couple of days, maybe, to really take a deep look at the team members and really consider who would be great to partner up with who and if you can spend that time to partner the team members up correctly, it really will pay dividends. If you can do that, you’ll prevent a ton of team conflict down the road. So that’s four suggestions for you, in relation to preventing team conflict, on top of the other suggestions on resolving if it’s already occurred.

Alright, well I think that wraps it up, regarding for how I have personally tried to resolve and prevent team conflict. I certainly am open to hearing your suggestions. If you have any, feel free to send me an email at [email protected]. And don’t forget to check out the AgileInstructor.com website and TeamXcelerator.com website. And as mentioned earlier, I do have a special guest coming up in the next show, which is Ken Ruben, author of Essential Scrum and I’m really looking forward to asking him some really great questions I think you’ll enjoy and find insightful. Well, I think that wraps it up for this show – thank you so much for your patience in waiting for a new episode, I apologize for the delay and looking forward to releasing a new episode with that great interview with Ken Ruben. Thank you very much! Goodbye!

Thank you for listening to All Things Agile. We look forward to you subscribing to the podcast on iTunes and leaving a kind review. Thanks and God bless!

All Things Agile - Episode 009 - Scrum of Scrums

Welcome to another great episode of All Things Agile. This blog and podcast is dedicated not only to interviews with Agile leaders but also to actionable and practical advice. In this episode, we tackle Scrum of Scrums. Well cover what it is, mechanics, benefits, and things to watch out for. If you have multiple Agile teams, this is an episode you must checkout.

As always, please take a moment to subscribe using this link: iTunes. Reviews on iTunes are also always appreciated. Do you have a question that you would like answered in an upcoming podcast, please send your question to: [email protected].

All Things Agile - Episode 009 - Scrum of Scrums

Transcript:

Welcome to the All Things Agile Podcast! Your destination for tips and interviews with the leaders in the world of Agile. Don’t forget to subscribe to this podcast on iTunes, and please check out our sponsor: TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.

Ronnie: Hello everyone and welcome to the All Things Agile Podcast. Today’s topic will be: Scrum of Scrums. What are they and how do you implement them successfully? But before we begin – a quick reminder that this podcast is for informational purposes only and accepts no legal liability. So let’s get started. As part of the AgileInstructor.com blog and this podcast, All Things Agile, I like to alternate between interviews and informational content. I think it’s important to help listeners with direct, actionable advice based on hands-on experience. Interviews are great and I certainly look forward to conducting more interviews, including in the next episode – however, I definitely want to include direct content. Things that I’ve learned from my experience that I hope can help you.

One of those topics that is often overlooked is Scrum of Scrums. Now, many people have heard of this, but are not really quite sure how to pull it off or perhaps they’re kind of winging it right now and perhaps haven’t seen what has worked at other organizations and are maybe looking for some additional advice. So I’d like to focus today on, again, Scrum of Scrums. So in this case, let’s start with ‘What is it?’

For those who haven’t heard that term – Scrum of Scrums – basically, when you have the individual Scrum teams, maybe in a smaller company or at a team that’s focused on a product –that team might work well and be able to take care of all the needs and that’s great. However, you may have cases when one team is just not enough to fulfill the needs of a product. Or perhaps there are multiple products being worked on and perhaps each team is working on one particular product or component, but those teams then have dependencies on each other. So just to recap: you may have cases where you have to have multiple teams working in order to get the job done on a particular product because there’s just so much work to do; or perhaps you still have multiple teams, not because multiple teams are required for a particular product or component, but just because maybe there is a dependency between the teams. You may have a product A and a product B, and you may have a case where the products are supposed to act like a suite. For example, a lot of Apple and Microsoft products are designed to work together with each other. And so, in that case, even though the teams may be working on separate products, they still may have dependencies on each other in which case there are pieces of the puzzle that still need to align with each other.

With any of our project managers in the listening audience, they’ll immediately start to think ‘Well, you got to keep these teams in sync’ because if the teams are working on the same product or multiple products with dependencies, then there’s definitely the risk that the teams can end up stepping on each other. And, you run into other issues where you need to be able to release code at the same time together, right? Because if you have, say 3 teams working on the same product, that product is going to get released at one time or is going to get delivered to production. And you can’t have those teams so disconnected that they’re causing havoc for each other and making it difficult to release the product at one time.

And then you also have quality concerns. You have multiple teams working on products together in parallel – there’s always a risk that one team can make a change for something and then inadvertently break another team and introduce unaccounted for defects. And naturally speaking, that’s not a good thing. So, how to overcome it? Well, there are many different practices and I’m not going to say there’s any particular right and wrong answer for this, but one of the more commonly applied principles, or practices I should say, is the Scrum of Scrums.

So there’s a need for it when you have multiple teams and you have to keep them in sync, help them ensure they’re not stepping on each other – what does the Scrum of Scrums actually look like? It can certainly vary by organization, so I’m going to focus on what do I commonly see in the field? Again – I’m not talking about a theory or a book, but what I actually see taking place in many other companies and industries.

Scrum of Scrums is a ceremonial meeting involving representation from multiple Scrum teams in which those representatives get together and help synchronize each other. For example, as I’ve mentioned – usually, what I see in the field is that it tends to be representation from the contributing or participating teams. Every organization is different – technically speaking, they could involve all the team members, but what I often see used in the field is representation. Meaning, you have a team of 7 people or so – each team has many different team members and if you start to get everybody together, it can get unwieldy sometimes. So typically, I’ve seen 1-2 representatives per team.

Again, there’s no hard and fast rule regarding who those individuals are, but what I commonly see is that it tends to be a ScrumMaster and or Product Owner. Now, there can also be cases where another rotating team member is involved – maybe it’s just a senior technical person or a senior person regarding testing, so maybe they rotate on some kind of schedule – but generally speaking, I tend to see the ScrumMaster and the Product Owner as being the ones that are the most frequent participants.

And if you stop and think about it, that makes a lot of sense. One of the roles or responsibilities, if you will, that I commonly associate with the ScrumMaster is they need to know what the deal is. They need to know how the team is doing. What are the team’s obstacles? What’s the overall progress on where they’re at? As I like to call it: the ScrumMaster always knows the pulse of the team at all times. If someone were to stop the ScrumMaster in the hall and ask how his or her team is doing, they should be able to answer that question. Conversely, the Product Owner is also usually in the loop and should be. The Product Owner should also be a person who’s actively engaged with the team and knows not only generally how the team is doing, but also how they’re doing in relation to the scope for the items that are being worked on for that particular effort or release.

So in this case, having either one or both of those individuals attend on a regular basis is usually what I see in practice. And I also see value in having other rotating team members and I think if the Scrum Master / Product Owner are the only ones to ever attend, then that can sometimes stifle some of the other team members, or maybe sometimes the morale. It is good to have some occasional participation from other team members – it gives them insight into what the other teams are doing and also to ensure greater participation and injection of different viewpoints and ideas.

But again, common things being common, I usually see ScrumMasters and Product Owners as typical representation. So if you had 3 teams working on the same product and let’s say each one of those teams provided two representing members – say for example a ScrumMaster and Product Owner – with each of those teams and members, they’ll usually formed together in some sort of a meeting or, if you prefer the term – ceremony. Basically, a quick meeting. And again, every organization is different, everybody conducts Scrum of Scrums a little bit differently, but what I tend to see happen in many organizations is that Scrum of Scrums tends to form a modified daily Scrum or daily Standup. Meaning that in your daily Scrum, you might usually have the typical ‘What did you work on yesterday? What are you working on today? What’s in your way? What are your impediments?’ Usually, I’ve seen Scrum of Scrums take a little bit of variant to that.

So for example, the group members may get together for a Scrum of Scrums and ask questions like ‘What have you worked on since the last time we met?’ And the reason I mention that ‘since last time we met’ is because the frequency for the Scrum of Scrums varies a lot. Some organizations will have Scrum of Scrums weekly, maybe every two weeks – maybe once a sprint. And some organizations will even have the Scrum of Scrums daily. And I think there’s no hard and fast, right or wrong answer on the frequency. I think it really depends also on the nature of the project being worked on and the teams, and their maturity and the risk level involved. If there’s high risk and the product pieces being worked on are very complex and there’s lots of teams participating in this, then having a higher frequency is usually a good thing. But if it’s a very mature product and the teams are very mature and there’s not too much risk on what’s being worked on at that time, then a less frequent Scrum of Scrums meeting makes perfect sense.

Again – I think that’s totally dependent on your organization and your unique situation, but typically what I see is that members get together and they’ll ask ‘What have you worked on since the last time we met?’, whatever period that’s been; ‘What are you going to work on before the next time we meet again?’ So for example if your Scrum of Scrums is, say, weekly – What did you work on in last week and what are you going to work on this week? As an example. And that helps clue in the other members on ‘Did this team fulfill the items that they said they were going to work on? Did they accomplish them; yes or no? And what are they going to work on next, what’s coming up?’ That’s important information to know if you’re trying to synchronize the teams.

Thirdly, what’s in my way? Or what impediments does my team have? Again – just another way of saying ‘these are potential things that can block us’ or ‘are blocking us’. And part of that reason is to one: see if someone else can help. You may have a case where team A is very blocked at the moment and running into issues, but perhaps someone on team B has had prior exposure to this type of problem and they can answer that question like ‘Hey – I’ve seen that before! Here’s what you need to do!’ and they can give you the solution right there and avoid further pain. So it’s a way of not only helping synchronize the teams, but also helping the teams help each other. So it’s definitely an encouraging aspect of the Scrum of Scrums.

Another facet is by discussing the challenges faced by a team is that it allows other teams to know that information and account for it. For example, if they know that one of the other teams – say team A hypothetically – is running into issues, then maybe one or two of those stories that have originally been targeted may or may not complete on time and they can sort of mentally put that in their list; if there’s concerns or if there’s dependencies where if team A starts to slip behind the schedule, then team B, which may have a dependency on team A, can then account for it. Like ‘Okay, well, maybe we need to push off some of our items into a future sprint for example.

I would say the fourth question that can be asked in a Scrum of Scrums is: What will you put in another team’s way? In this case, I’ve told you what has our team worked on since the last time we met? What are we going to work on or are we working on currently and I have discussed with you are challenges and impediments, things that are concerning us or blocking us – and forth, here are some items to be aware of, here are some heads-up things. Let me give you some examples of how this can be applied to you. Let’s say you have 3 teams working on, as an example, the same product and for example team B is about to make some risky changes. And they’re going to do it this week and they may want to ensure that they give the other teams a heads up. Hey – as part of what we’re going to be doing, I just want to make sure you are fully aware that we are going to be making these changes, and when we do, it may break some of the existing APIs and the other teams present may need to make some adjustments on their side, so that they can account for the API changes, for example.

It’s a great way to ensure that you are letting the other teams know of your potential impact on them, so they’re not caught off by surprise and that really helps build trust and you’re not surprising other teams with problems; you’re letting them know in advance ‘Hey – we’re about to put something in your way, perhaps’. And maybe it doesn’t turn out that way, maybe it’s just a potential risk – but you just want to ensure that the other teams have that curtesy heads-up.

So again, just to recap: every organization is different, every unique industry has its risk tolerance and things like that, so the frequency may vary depending on your circumstances, the representation for the Scrum of Scrums can definitely vary – depending on what you organization needs, but as I’ve mentioned, typically I see in the field one to two representatives, typically a ScrumMaster and Product Owner, maybe a rotating team member; typically I see the modified form of daily Scrum or standup. Usually I see, especially the first 3 ‘What have I worked on since the last time we met? What have I worked on or going to work on between now and the next time we meet and what’s in the way, what’s blocking me, what’s concerning me?’ And forth ‘What do you need to be worried about? What potential risks can our team inject that you need to be aware of?’

In terms of how much time it takes, what I typically see – similar to a standup, the process should not take long. The point of Scrum of Scrums is not to have a giant, fancy PowerPoint presentation and really sleek graphics or anything like that. It’s a very, very informal meeting and, in this case, I would say 15 minutes. Similar to a normal, Daily Scrum. It’s, to me, what a well-oiled Scrum of Scrums should be like. Very quick, very informal, very direct, to the point. In terms of how to help do that, one of the ways is again going back to the audience. If you have everybody from all the teams, it can be very difficult to have those sessions in a quick timeframe. That’s why having representation tends to work out better in my opinion.

Also, the people participating – in this case, the representation is from the teams themselves. It’s not really trying to loop end on the project managers and resource managers and the directors and the VPs and everybody and their brother. Because the more, honestly, those people get involved in the situation, the longer the meetings are going to be and the more off-topic they will be. And that goes back to ‘What’s the benefit to even doing all the Scrum of Scrums stuff?’ Why should you care?

Well, one is, it helps reduce risk, but more importantly, it helps the teams help each other. Like I’ve mentioned before, teams can offer advice to each other. It’ll keep them synchronized as well and it’s really to benefit the teams themselves. It’s not meant to make project managers happy or to make VPs happy. And so, in that case, by keeping the audience to the actionable members of the team, you’re able to operate more informally, more efficient and sort of get in there, and talk together and be adjourned and move on with your day. No need to inject a lot of long-winded discussions or politics involved. Some of the other key aspects of the Scrum of Scrums is that when you do have the sessions, I think it’s important for someone to maybe take a few notes sometimes. I’m not saying big, detailed meeting minutes, but it can be helpful if someone is at least taking some notes regarding that. Typically, what I see, is that the ScrumsMasters, if they’re participating, they’ll sometimes take down a little bit of notes – again, nothing formal, on the conversation that was had. And the reason that I mention that is because when the representatives leave that Scrum of Scrums, I personally found that it’s very beneficial for them to relate important notes back to their teams.

So for example, let’s say during the Scrum of Scrums meeting and let’s say there are 3 teams participating in the product release. They may, for example, one team A may say ‘Hey, by the way, I just want to let you know we’re about to make some API changes and the other two participating teams will need to make some adjustments for that.’ Great point to let people know about it – that’s very awesome. And so when the other ScrumMasters go back to their teams, maybe for example in their next daily standup, daily Scrum, that ScrumMaster is going to mention ‘Hey, by the way, I just finished participating in our Scrum of Scrums and I want to let you know that team A mentioned in the Scrum of Scrums that they’re about to make some API changes and it may break us, and we may need to make a few changes to adapt to that’.

In this case, the ScrumMaster or the representative, or whoever it is – they have at least some rough idea, notes or ideas of what was discussed in the Scrum of Scrums. They can relay pertinent information back to their own teams, so that not only is the representation sort of in the loop with what’s going on, the whole teams are in the loop. In that case, the teams themselves, all the team members are aware of the relevant information for them. And that way, it’s not just a few people that know what’s going on there and everybody else is in the dark.

If you have representation in a meeting, as part of that representation’s responsibility is to ensure that the other team members that did not attend are aware of important information. And so, I think that’s sort of the general gist of the ‘how’, if you will, the mechanics of the Scrum of Scrums. Again, there’s no particular right or wrong answer to doing that. Every organization is different, you have to find out what works for you – that’s kind of the beauty of Agile, to adapt.

Now, in terms of what my experience has been – I think that one piece of advice I’d issue to you as caution. Do make sure that the Scrum of Scrums does not become a status meeting. Your goal is not to just read off some random set of status updates. One of your goals, again, is to help each other. And to keep each other informed. And so, when you engage in just a pure status roll call meeting, then the helping each other and the transparencies can break down. And so, I would definitely warn or encourage you that when you conduct your Scrum of Scrums, try to keep it focused on ‘Hey, the teams themselves are the audience. This meeting is for us, this meeting is to help us help each other, so that we can deliver the products together or within the same product.’

So if you keep that mentality or focus, then I think it helps the tone and the attitude of the meeting. Cause if it turns into just a giant project management status meeting, then I think the morale tends to go south and helping each other tends to go down as well. Because people are trying to ensure that they are publicly postured well, that their team is not looked upon in a negative light. So they may even play down information, they may even withhold information. They may not want to admit that ‘hey, we just dropped the ball!’ But if it’s very informal and kept to the participating teams and focused on helping each other, the teams will have that confidence and have more candor and transparency, where they can say: Hey, look – this is really in our way right now and this is causing us major problems. And by being able to communicate in an open manner, that helps the teams that are participating feel connected and willing to reach out to each other and help one another.

The purpose of the Scrum of Scrums is to help the teams themselves. I know I kind of beat a dead horse on this one a little bit, but it’s a complicated topic. Many books don’t go into it very much, many websites don’t go into it very much either. And there’s not a whole lot of guidance into the Scrum of Scrums and I just wanted to take a moment and sort of discuss what is it, who’s the audience, what are the mechanics, and what are the benefits – we talked about that, in terms of the improved synchronization, communication, helping each other, letting people know about risk, etc. And so, with that said, if you are involved with multiple Scrum teams or product or suite of products, I would certainly encourage you to take a look at the Scrum of Scrums practice if you’re already using it. And if you are using it, I may want to encourage you to take a look at how it’s currently functioning and what the drivers are, if you will, behind your current meetings. And maybe just take a look at it, kind of like a retrospective. Take a look at how well your Scrum of Scrums meetings are taking place and, you now, as you go, you can always make improvements to it.

Alright, I hope you enjoyed this episode! As always, I’m honored to get a chance to speak to you and stay tuned for our next episode where we’ll be having a special guest interview – I’m really excited! Alright, well thank you very much and if you have any questions or would like to offer suggestions for future topics, please email me. You can reach me at [email protected] and I’ll be happy to include your questions in the next episode. Thank you very much!

Thank you for listening to All Things Agile. We look forward to you subscribing to the podcast on iTunes and leaving a kind review. Thanks and God bless!

All Things Agile - Episode 008 - Nupura Kolwalkar Interview

I am thrilled to bring you a true business leader to the show. This episode features an interview with HealthPort CTO, Nupura Kolwalkar. Learn how she championed the transition to Agile in her organization. We will discuss challenges, tips, and most importantly, results.

I hope you are enjoying the great targeted content on this podcast. Please take a moment to subscribe in iTunes using this link: iTunes. Also, please send me your thoughts and questions using [email protected].


All Things Agile - Episode 008 - Nupura Kolwalkar Interview

Transcript:

Welcome to the All Things Agile Podcast - your destination for tips and interviews with the leaders in the world of Agile. Don’t forget to subscribe to this podcast on iTunes and please check out our sponsor: TeamXcelerator.com. And now, here’s your host – Ronnie Andrews Jr.

Ronnie: Hello everyone and thank you for joining me for another exciting episode of All Things Agile. Today I’m joined by a special guest: Nupura Kolwalkar. She’s a long-time friend and former colleague of mine. Nupura is a business leader who is utilizing Agile to accelerate her organization. So first off, thank you Nupura for joining us today – it is definitely an honor.

Nupura: Thank you for having me on the show.

Ronnie: Can you please take a moment to tell our audience more about your background, maybe both personally and professionally?

Nupura: Sure! So I have been in the healthcare IT space for about 9 years now. I have been exposed to all aspects or most aspects to approach IT from a revenue cycle, clinical, HR and analytics perspective. So a good, broad understanding of this day’s American healthcare industry. It’s been an interesting journey – as much as everybody focuses on the actual industry and the domain expertise, through 9 years, more of my learning has been on the talent management and process simplification side, although the domain expertise is always a great plus.

What I enjoy most about my role, where I’m at now, is that I get to see folks learn something from simple processes and direct conversation that helps them to be better professionals at their workplace and find joy in working with their teammates.

Currently, I am working at HealthPort Technologies as the Chief Technology Officer. I have worked in the past with companies like McKesson, Pfizer, NextGen – so I have a wide variety or background, but I’ve definitely found my groove where I am.

That’s professionally. Personally, I have two young kids, a husband, a house, a typical family with a dog as well. So, standard young family, mom role at home. So my goal always is, if I take on a new challenge, how do I rely on the talent that I hire and work with to achieve my personal work-life balance; which is usually measured by how many times in a week do I have to take my laptop back home. And currently I take my laptop home only in the weekends, which I think speaks to my theories and my co-workers and the folks that work in our organization.

So that’s probably more on the personal side. I love to travel, love to interact and learn these things; I love change, so change is probably the most constant thing in my life.

Ronnie: That’s a great introduction – thank you so much! First off, I really wanted to thank you for coming on the show because you’re really our first guest that’s coming on as a business leader. We’ve had some other guests before that were sort of with the Agile gurus and more like instructors and so forth; but I’m really excited to have an actual person who is putting this in place in the field as a business leader and implementing Agile in their organization and being able to testify to the impact. So with that, I’d probably like to dive into our first question which is: As a business leader, how has the use of Agile impacted your teams?

Nupura: When I think about the question, there are so many little impacts that make a big impact; but at the end of the day, to really pinpoint a couple, I would say my biggest satisfaction from bringing Agile to our organization is it’s allowed the organization to scale fast and work correctly really early on.

We do two weeks test, so in a couple of weeks we usually know if something’s going to work through the organization, because we’re able to demo to the business. And if it doesn’t, then we’re able to course correct early on in the process. My next key point is showing business value. This is probable where I feel that Agile has come true in the most significant way and close to the idea Agile principles. But showing business value: when I walked in we had internal tenth day quarters because we had a good evaluation aspect to work with, as well as products and we had to wait 6-7-9 months to see what came out, but as we moved to Scrum and we installed the demo process, the stakeholders got absolutely addicted to it. They wait for every Tuesday to get the demo for their operation goal and objective.

The business value, it helps us, it helps them, it helps the organization and save a lot of money. As a business leader, between the two of them, what is ultimately impacted is the cost and efficiency that we’re able to achieve and through our organization because of fail fast, course correct early principle in Agile. So those are the two biggest ones. There are quite a few little ones like the morale of the team. Once we settled down with Scrum – it was definitely difficult to get there – but once we settled down the morale, the motivation, the commitment and ownership are definitely very high on the radar. Sounds like little things, but ultimately the team puts the show together so they are highly motivated, and you get better results. So those are probably my key 3 points that I would point out.

Ronnie: Sure. I love that answer and I really like the phrase you used that the stakeholders were addicted to the demos – that’s awesome. And I would definitely agree with your experience that when you are able to provide those demos and be able to course correct early, it keeps you from making costly mistakes later. You don’t want to be 6 months later at the end of the release and realize that what you’ve developed wasn’t what the stakeholders really wanted.

Nupura: Right, absolutely. And one the things that I would like to point out is that it takes time for the teams and the stakeholders to get to where we are. In the process, many times the stakeholders won’t show up for a demo. And they’ll show up for the next and skip one and they would start complaining ‘Well, that’s not what I really asked for’ – but the demo is our way to hold our stakeholders and customers accountable for what they asked us to do. So our response would be: If you don’t show up to validate what you need, then you get what you signed up for because we’re not going to go back and invest in correcting the mistakes. So it’s a bi-directional accountability as well. The demo holds the team accountable to the stakeholders, but what I have found very interesting is that’s my only forum to hold the stakeholders accountable to the team.

Ronnie: Excellent point, excellent point. I totally agree. That’s a really key factor there; being able to hold each other accountable. Well, I think that probably really dove-tails well into our second question, which is: What are some steps that you are currently using or in the past have used to help adopt Agile practices?

Nupura: Good question, Ronnie. And I think we did really good at McKesson. I changed the direction of how I wanted to go about doing this at our business. The theme of this implementation has always been: let’s have a grass-roots level movement, not a top-down level movement, but have a  grass-roots level movement with top support to it. People ask me what I have learned; I’ve done this in a couple of top organizations – if I had too many external folks involved who did not understand the impact of a good or a bad process, or the lack of a process, it added a lot of noise to the organization. Why go through this change?

And one of the things I have definitely seen as we implement Scrum is that we do see attrition. I have seen close to 25-30% attrition in all the last three cases that I’ve implemented this process. So a couple of things we did. My functional management team and I sat down and planned for what happens if we have attrition? What is it that we need in our organization to ensure that we can take on the attrition? Which is mainly knowledge redundancy – do we have knowledge redundancy in the organization? If there are people who are going to leave because of change, will the organization, the stakeholders and ultimately the customers suffer?

So that was one question. The second was: what will it do to our morale organizationally, and what would it be as a reflection of the management team? That was relatively new to HealthPort. So those were the three answers that we wanted to answer so that we can deliver to the business; we wouldn’t have a revenue impact to the business, but we’d be able to take this organization through the change at our own pace instead of someone else’s pace.

Once we set goals for those, the rest of the time was getting the knowledge documented because when I walked in there was nothing documented. And when I say documented, it’s not pages and pages of requirements. It’s really about change. For example, this particular area is a little bit difficult to understand. Let’s put it into our knowledge pack that we give to our new hires. So the first thing we do in getting ready for Agile was a new hire packet because we knew we were going to go through attrition and we wanted a good, stable base to hand over to our new hires as they came in. So we implemented a new hire packet. We planned for attrition by getting the knowledge into visual workflows and these workflows were located on the walls, they were in the team environment. They weren't living in a tool; they were out there in everyone’s face so people could just walk over and look at them. So that was the trick to even think about Scrum.

But once we started to actually think about Scrum, one of the ideas that I’ve used back in my McKesson days was to put together a team of the teams to build it in a way that the teams hold themselves accountable to this change and they wanted to go through this chance. So we called our team Matrix, because it truly was a matrix of different roles. Now, one of the things we did do differently here than what I have seen done – there’s a big focus on no functional management or leadership should be in any of these meetings. Now, we haven’t released functional managers but there is no stress between the contributors and the management teams. We work well, so they asked us to help out so that we could use some of our time and save them some project time in order to take this through change.

So our Matrix team consisted of some functional leaders, but not all of them, and contributors from each function area and a couple of stakeholders outside of my direct organization to help them see how they’re going through this change, and how is it going to impact them. And the team pretty much put their agenda together; they worked through our town-hall meetings, and monthly staff meetings to get buy-in from directors in the organization, next steps, morale boosters, coaching – which is the biggest thing in my opinion. We trained a team so that a team can start to train at the peer level to other teams. We had, of course, formal coaching which can never be replaced in my opinion.

It was a 6 month effort to transition the whole organization to Scrum. We did it based on the revenue impacts that we could forecast. Cause, you know, when you plan for attrition, you have to make sure that key knowledge is not lost; and if it’s going to get lost, what’s the impact that it would make. So all in all, it was a gradual movement reported completely by the management teams and implemented by the individual contributors through the individual contributors. I believe it took us to stabilize, maybe about 6 to 9 months, just to stabilize. We saw a very high level of attrition, but we were able to plan to bring new people in and have them absorbed into the organization without an impact. It did, in fact, impact morale, and I want business leaders to recognize that when they sign up for these things, we have to do morale boosters for the organizations because it’s hard to see your colleagues leave because they don’t agree with the culture that’s coming into play.

So that was my biggest struggle – to keep the motivation and morale level high through this change. And we also discovered that there were a couple of things in Scrum that don't even apply to those teams because of the turnaround times that we required on those teams. So all in all, in 6 months the team did it – all I had to really do as a business leader was to have their back and be supportive. We did all of this internally with none of the businesses stakeholders really knowing what we were doing because they were still getting their projects delivered and introduced the concepts very slowly to them,  the demo being the first thing that we introduced. So there was the transition period, we allowed people to transition at their pace, not our pace. And I believe we came out really good out of the transition and I do believe having the individual contributors drive it really helped that process significantly.

Ronnie: I would agree, and I like your insight. Again, as a business leader regarding, for example attrition because that’s really something that most of us wouldn’t have even considered, right? And it is true that in any organization, doesn’t matter what it is, you’re going to have some individuals that are going to embrace change and you’re going to have some individuals that are just very resistant and they just don’t want to change and when you’re trying to implement any type of process change, there’s also going to be a degree of friction and it’s important to be cognizant of that. So I’m glad you…

Nupura: And plan for it. As a business leader responsible for $400 million – in my case, if I haven’t planned for it behind the scenes that would’ve been a huge impact that the organization couldn’t absorb because of their size. Another thing I would like to point out on that is that it’s not just that people don’t want to change. What I saw was – sometimes the pace is too fast for some people. We have lost some really extremely talented people who had great business knowledge because they couldn’t deal with the pace of this sprint. So trying to find that balance and letting the teams come there was definitely another big challenge that we had to face.

Ronnie: That’s a good point. Well, Nupura, why don’t we transition into our next question; it’s a little bit more of a tougher one, it’s definitely more of a challenge and definitely someone looking for an answer from a business leader, which is: how are you currently, or perhaps in the future, look into tie in the HR component to the use of Agile? For example, what do you recommend to other business leaders to provide performance reviews, rewards, to encourage successful Agile adoption and use?

Nupura: I have been asked this question a couple of times before. From my personal perspective, given our context and culture, it’s a little bit different to perform mixed measurement and management. And myself have gone through a lot of performance metrics, being a leader, I’m doing it a little outside the box. So what we do, and I can only speak about what I do and it is working pretty well in our organizations: two things. There’s a team level performance which is directly tied to the outcome of the Agile aspects of the process. I don’t really say it has to be tied to a date, although dates are important, don’t get me wrong – but I don’t really tie directly to their run-rate – it’s about what outcome did you achieve at the end of two weeks, at the end of four sprints is how we measure it. And we have data that we use to measure it internally. We do surveys with our stakeholders, we do after-demo surveys for the big projects. But it’s very outcome-based, not necessarily estimates vs. actuals based. Which is a little bit of a different way to look at Agile. And I’m sure not all business leaders would agree with me, but it worked well for the team, it helps with the morale and motivation.

Now, with personal performance management, we focus on in the individual and team, and on the individual side, where I say that Scrum helps the most, is in more than the management itself. It was the individual found it easy to break down some of the barriers that they need to find like communication. Like let me cover my basis constantly via email. Those things, I think, Scrum really challenges you to open up, break the barriers and get into an uncomfortable zone of direct communication.

So through this, while we were transitioning a few things we did was measure our folks. Not necessarily whether they’re performing well or not, but measuring our folks to see if they’re able to get over that barrier and help them with a lot of personal coaching, outside coaching, to get over the barrier of direct communication and conflict management. So those are the two things where I have found value in implementing Scrum and the fact that implemented Scrum has brought out our talented folks to be direct, respectful and ready to deal with conflict. I haven’t really thought of tying any direct Agile results to individual performance and I don’t know if I will get there, because from all different perspectives – I do feel like artificial data like dates and boundaries ultimately don’t measure a talented person. It’s the creativity and it’s the outcome that they provided to the organization, along with their commitment, that measures the individual. It’s maybe a little bit of a different answer, maybe not expected.

Ronnie: Sure – it’s great! I definitely appreciate you opening up and explaining what you have seen and I hope that that benefits other members of our audience, so thank you so much. With that, I’d like to transition into our final question which is: What advice would you like to give to other organizations that are considering adopting Agile?

Nupura: Agile and Scrum works for any organization. Several times when I’ve been on forums, where I’ve engaged some of my peer conversation, the first thing people say that even though you had all the right stars aligned to put Scrum in – that’s why you were successful. Scrum’s not for me, Agile’s not for me – anything that bases off from my organization. I really, truly, passionately believe that Agile is for anybody and it is up for the business leader to find ways to bring such a wonderful bi-directional accountable process to the organization for the better of your talent. At the end of the day, your talent is going to be at a better place once you have this process.

And I hate to call Agile a process as well, because it’s a principle, it’s a mindset, it’s a culture. It’s not so much just a demo or the retrospective; it’s how people think when they start to practice Agile. That’s what I love about what this methodology brought to our organization. So given that, I would say be open-minded and be ready for a change. If the business leader is not ready for change, then there’s no way you can transition into something that’s so intrusive to the organization, creates a lot of noise in the interim, but knowing where you want to get to, you should be prepared mentally, organizationally, knowledge-wise to cross that barrier as a leader.

Now, one of the lessons learned from my past is, in the first round, we all read books, we all were trying to implement Agile in a very waterfall organization. We all read books and we said we are going to follow Agile to the end nth principles. So we started with the expectation to have an ideal implementation. What I’ve learned through taking two or three organizations through this is the core would be to get to an ideal implementation, not to start at ideal implementation. And it allows for people to absorb change, leave, come back and embrace the growth of this methodology, instead of the brute force of the methodology. So we, having been in product management and strategy for a long time, I always tell the product managements: the thing about minimal value products instead of the perfect product – I have applied that principle to the implementation of Agile. Minimal viable that shows the value of the change itself. If you’re able to provide the value to the business and to our own organizations, then take the next step. So don’t use the Agile principles to implement Agile. That would probably be my biggest take-away.

Ronnie: That’s a great point. Love that answer! Well, thank you so much Nupura for that great advice and insight and thank you once again for joining us here on All Things Agile. It’s been a real pleasure.

Nupura: Thank you for having me on the show again and I’m glad to be here with you, Ronnie. Great job on what you’ve started here!

Ronnie: Well, thank you very much to our special guest Nupura Kolwalkar and thank you everyone for listening to another great podcast. Look forward to seeing you again! Thank you!

Thank you for listening to All Things Agile. We look forward to you subscribing to the podcast on iTunes and leaving a kind review. Thanks and God Bless!