Welcome to the Agile Coaching Network
An online community for Agile Coaches to improve their skills
The Agile Coaching Network is a twice a month panel style conference call with Agile coaches from around the world. The hour-long session is hosted by nuCognitve, and it covers a wide variety of topics that are based on actual questions asked by the coaching community. The question backlog is prioritized based on votes from the community. Here are a few of the questions from prior sessions:
- My team has a trust issue. How can I fix this?
- How do we get more executives to care about Agile?
- How do you define value?
- Tension in deploying Agile — start with values or practices?
- How do the semantics of sprint and sustainable pace go together?
Everyone is welcome to participate in the Agile Coaching Network call every other Wednesday at 8:00AM Pacific / 11:00AM Eastern. We posted a transcript from a prior session below as an example. If you’d like to join the Agile Coaching Network, here is how to get started:
- Complete a simple form here to add your email to our list
- Accept the meeting notice and block your calendar
- Ask questions and vote on topics (link provided in meeting notice)
- Participate in the session or listen to a replay if you are not able to make it
If you have any questions or would like to participate on the panel, contact us at email@example.com
Agile Coaching Network Transcript
(automated transcription is still imperfect - edits were made to improve clarity and readability)
Ray: Ok, everyone let’s go and get started. My name is Ray Arell. This is the Agile Coaching Network. It’s a bi-weekly webcast. As always, I’m the host. I’m from a company called nuCognitive. My role here is to get the conversation rolling and also participate on the panel or ‘park bench.’
This virtual ‘park bench’ that we’ve set up is a place where you can ask your questions about your Agile adoption. As always we have the questions up on sli.do where you can actually go up and vote up and vote down. Basically making sure that we get the questions that all of you guys want to hear about today. I will occasionally ask to pivot off the question if we see the conversation goes low. But beyond all of that, this is a safe environment for us to be able to ask questions and to learn. So the first question. And Jorg I see that you’re on the call, it looks like the top one is up there. Why don’t you go ahead and kick us off. It says “Please share are some of the best practices on how to show teams that they’re not perfect.”
Jorg: I can kick you off on that. I’ve been working with a couple of new teams. So to me, all of the people are new. I just met them a month ago. And they are quite diverse in the adoption of Agile, adoption of Scrum, adoption of the mindset. Some of them still go that engineering way “saying I’m absolutely in control of my work,” “I know what I need to do,” “ Don’t bother me with the new approach,” “Don’t make me think about what I might do better because I’m already so perfect,” “See, my stakeholders are not complaining.” Things like that. Their pretty obviously wrong, but hitting them over the head with it is just not going to work. So I’m looking for some interesting ideas to make them aware of that challenge that we are all never going to be perfect. That’s definitely for sure. Maybe you can help me there.
Ray: Ok. Anyone want to take a first stab at that?
Dan: One thing that comes to mind for me is to get them to demonstrate their expertise by making predictions. And of course, you know the nature of a complex system, it’s very difficult to predict. They will absolutely learn things from their predictions. A Lean guru that taught me, Steven Spear, one of his favorite phrases that he used in all his courses was “How do you create an opportunity for surprise.” By being surprised, by creating those opportunities for surprises, is how you accelerate learning. So by getting these engineers to write down some predictions like “what is your customer going to think about this feature” or “how long do think or how many hours do you think this task will take to get it done,” you generate that opportunity for surprise and learning.
Ray: Yeah. To add to that, I think that a number of people, especially when when things are good, when things are working, it’s always hard to shift them toward the mindset that we need to go improve. As Dan was just pointing out, when they see that there’s something that isn’t perfect, then that gives an opportunity to open up and say “Hey, is there something we can do about this?” There’s always going to be something that’s going to be wrong or something that didn’t work out so well. Those opportunities might come out of the retrospective. Explore that space a little bit.
Jorg: Maybe I can comment a bit, I thought that ‘surprises’ are a really good point. As well as the idea of making predictions which go beyond just timeline or effort. Because currently they either say ‘it’s clear how long it takes’ or ‘it takes as long as it takes’ - shifting between those two views. For the retrospectives, currently the attitude is somebody else is to blame. They’re not looking for what they should do better. These two avenues are still pretty closed, but making them do a few predictions on things that are not strictly technical or in the normal line of thinking — that’s really interesting and I like that VERY much.
Dan: The teams that I’ve worked with that kind of get this way of thinking eventually come to the conclusion that they should be very humble, very open to the fact that ‘there is no best… there is only better.’ Everyone can improve. Everything can be improved. Does this team have this attitude towards improvement or do you think that they think they are perfect essentially?
Jorg: I’m not exactly sure what is driving them, but they not capable of reflecting what improvement lies in their future, or what they want to do. I think that they are not shown that space. All questions that come from predictions to them are still bound by this managerial view of being right on time. They don’t see the benefit of Agile for themselves. One of my first things will be to get them to reflect and surprise is a good idea.
Ray: One other thing that you might want to do is to offer suggestions for the business urgency of why the Agile adoption is taking place. Bring in someone in the senior ranks of management to talk about critical market changes that are occurring or some reasons why Agile became important to the company. Paint the financial picture for why this is important. The other idea, if you have the opportunity, is to bring a customer in. Or the person who is receiving a bill.
Jorg: That might be a bit challenging but definitely something to think about.
Ray: So I noticed Rhea is on the call. I welcome. Do you have anything you want to add to this?
Rhea: Sure. First of all, hi everybody. I don’t know if you’ve tried to share stories of your improvements that you’ve done, like when you were surprised by things that you could improve?
Ray: Sort of like a competition a little bit?
Rhea: No…the opposite. I think that engineering tends to be an expert culture, and it’s not necessarily safe to show failure or show that you don’t know what you’re doing. That may be an underlying thing here. I’m not sure, but make it safe for people to say they are not doing something perfect. It’s often helpful to share your own stories where you were surprised and show that it’s okay to talk about that.
Jorg: Yeah, I been thinking about that as what they’re doing. It’s a bit sideways to where my direct experience lies. It’s hard to find the right inspiring story for them that works. So yeah, I definitely think it’s good share war stories to inspire people.
Ray: So do we want to pivot to another question?
Dan: One more quick comment. Help them realize that their job isn’t just to code a feature, but it’s also to code so that the next time they have a similar task it is better. Their job is to learn, as well as to complete tasks. Every time they do a particular thing, they should also be trying to learn how to do it more effectively and efficiently in the future. Essentially learning is part of your job, and if you don’t think that learning is part of your job, then something is wrong.
Erik: Rhea has a very good point that engineering tends to be an expert culture, and any kind of admission that you’re imperfect is seen as a very bad thing. I wonder whether you’ve got the opportunity to highlight the people who are doing this and are saying ‘we improved in this way, we were imperfect.’ Not only is it okay to do that, but it becomes expected within the culture that you do this, and it’s NOT okay to hide the problems. In the expert culture it’s okay to hide the problems. If it is just a person or two, it’s pretty easy to use social proof. Surround this person or two with people who are alike and maybe admired. Find the person who’s of influence here, and get that person to step out and be more visible of saying “yeah, I made this mistake and here is how I fixed it, and now I’m doing better.” Reward that behavior. If it’s just one team among many, do the same thing. Surround that team with teams that are doing the right behavior and get them to think that — oh not only is it okay to say I was wrong and I’m getting better, it’s really expected of me.
If the whole culture is one of an expert expert culture, then you’ve got to look for another lever. You need some form of what Edgar Schein calls ‘survival anxiety’ in the system. If the customers aren’t complaining, then management is not complaining, and if nobody else sees the problem you’re trying to solve then you get ‘why the heck should I do anything different?’ Especially if I am an expert and don’t like the feeling of saying ‘I’m wrong’ and ‘I need to get better.’
Jorg: That’s a very good idea because teams are more or less split in the middle. I’d say roughly half the teams are openly adopting. They are pretty flexible and look for the best way to do it. It’s natural. Then there is the other part which is pretty entrenched. “We’ve always done it like that,” and “We know what we’re doing.” They’re divided by knowledge areas or domains. One close knit group isn’t adopting, while another is. One thing that is on my mind, but definitely not easily, is to kick start them to compete. Not to compete against each other, but compete WITH each other. Which is much more easily said in English than in German. So I’m still struggling with how to get the concept to them in their native language. But I like it a lot.
Erik: One of the things we did years and years ago at large company was create a software quality award. This award was something that we use to show people a mirror. Say that you apply for this award. It’s very obvious to me that you care about software quality, and as someone who cares about software quality I’d like to come and talk to you about X, Y, or Z. You might have the opportunity here to put together some sort of an award. It’s that sort of co-operative competition where we’re trying to raise all boats. And it’s not just the winner but everybody who applies that starts to define themselves as someone who cares about getting better. So if you have an improvement award, then you start to get people think — okay, I’m going to apply to this improvement awards, I must care about improving. If there’s a lot of good recognition that comes with improving then maybe the culture will start to rotate to say it’s no longer acceptable to say you’re perfect.
Ray: Another thing to add to this discuss. There were a couple teams that I coached where the senior architect was that sort of holdout. They were the smartest person out there who knew a lot of product knowledge. They just didn’t see why Agile was a fit. As a coach, I needed to take that person aside and just have some conversations about why this was important. It was interesting. On the first visit, this person was almost angry. They were mad about the fact that their work environment was being disturbed. After I had that conversation and described what we were trying to achieve with Agile, the person had read a couple of books on the side and started asking me more questions. They were still a little angry about the fact that their work environment was being disturbed. By about the third time, this individual actually wanted to step-up and start to teach what they knew about the product to others because of knowledge silo issues and other things that they were dealing with. They could only go so fast because there was only one person who knew how to do one portion of the build. This person became an advocate for the change in the system which was really cool. So you might want to identify and target these expert laggards.
Jorg: Two thoughts that I picked up that are really, really beneficial here. One is applying for the award. Just creating the award and passing it out would definitely not work so much. But if they can raise their hand, then this really gets them active. I like this a lot. That’s really good.
Ray had another idea here that was about teaching. I think giving them opportunity to teach others might be an opening that I can create. Combining this idea with concept of predictions. Might be a REAL opening that’s worth trying.
Ray: That way you’re also acknowledging that what they do is important. It’s not that we’re discounting the way that we’ve done things before. We’re actually shifting to a new way. The stuff that you have in your head, we want you to share that. I think that opens the door more. Agile is a sharing culture. We want to encouraged people to come out and share.
Erik: Two quick book references for anybody listening who wants more depth in some of this than we can talk about in a short hour. The first would be the work of Edgar Schein on corporate culture, especially the Corporate Culture Survival Guide. It is a nice short overview of everything. Secondly, for things like social proof, self-consistency, and some of these other psychological aspects, I would look to Robert Cialdini’s book called Influence, The Psychology of Persuasion. He goes through reciprocity, social proof, self-consistency, and a bunch of other little things about influence that we’re all sort of vulnerable to and that you can use to change the culture and individual behavior.
Ray: Cool. I’m going to pivot to the next question “Tension in deploying Agile — start with values or practices? Practices without values will lead to cargo cult, but too much time upfront might scare team away”
This relates to an event from an Agile management forum up in Seattle. Someone said, “ The first time I saw an Agile coach coming at me, I think he wanted to give me a big hug. I felt like we were in a hippie commune.” Too much time on culture first really turned this person off. So, what do we start with? Do we start with values or do we start with practices?
Erik: Yes. I think they are rubber-banded. You start where you have the opportunity to start. But these two ideas are rubber-banded. You can’t go very far in one dimensional without pulling the other one along or you’re going to get completely out of whack, as I think that questioner is implying.
Ray: Right. I just posted something on YouTube a couple days ago where I was talking about the fact that people say “Hey - Agile failed in our organization.” But if you really dig down, I don’t think they really understood what Agile was in the first place. Agile describes the culture, where scrums describe the practice. I think that a lot of teams go forward with adopting scrum, and they never use the manifesto or using any of the heuristics that we would expect them to be using.
Erik: If people actually saw these two things as co-equal and put effort and resources against them individually, in support of each other, much of this problem would go away. As you just said, the problem is frequently that somebody doesn’t see one side of the other of this coin, and they get too far out of whack.
Rhea: Espousing values does not make those values a reality. I think a lot of people think that if we talk about them, then suddenly everybody has those values. It’s so important to have this kind of mix. What do we value today that is along those lines, and already a pattern. Some aspect we can get behind right now and start moving in that direction. As we learn more, we may add more of these values.
Erik: Yeah, here you’re actually reinforcing my quote from Edgar Schein earlier. Maybe I’m just thinking in those terms today, but the three-tiered model he has with espoused values and observed artifacts - signs on the wall, badge around your neck, Agile values stuck on cubicles. Then you have the gold mine down beneath those — the tacit assumptions. That what’s really driving the organization, because as you rightly say people can go off and quote these values, but if they don’t behave correctly then something else’s preventing it.
Rhea: One of the techniques used with a large team in a large company was simple rules. There were very different views of how everything works and across teams that are trying to work together but are separated by geographies. It is very complex and we were trying to get to state where we move forward with Agile. The technique that they used was simple rules. What are the simple rules, or heuristics, that we want to follow? They wrote those together and of course those that wanted to go to Agile could influence it. It was written in the language of those teams and of those people. Then they could then get behind it and move forward. It was enough for people who wanted to run and show that this was a possibility and show how this would work to move forward and not be in conflict with the people who aren’t quite there yet.
Ray: So you’re saying that you sit down with people and said “Let’s read the manifesto and write it how it’s relevant to us.” Is that what you’re trying to do?
Rhea: Theoretically, people had known the manifesto, but I think it was probably to theoretical. It was so far from where people were at. How do we write it in terms of simple rules, from Glenda Eoyang and Human Systems Dynamics. We wrote it in that format. They wrote down what they agreed to do as a group. There was definitely underlying elements of Agile, but it was written in their terms or their language. So that it wasn’t this kind of theoretical, commune thing. This sky that they couldn’t achieve. It was something tangible that they could then start to take steps towards.
Ray: Sure, that makes sense. So from the distance between whatever future state that they created with this document, did they walk away with a game plan on how they were going to shift some of that? Because cultural change, behavioral change takes years. You know?
Rhea: Yeah, I don’t want to say it was a future state. It was kind of like — this is what we do. Things like quick feedback loops or we are always trying to get faster feedback loops in our system. So, the people that really wanted to change, we would talk about this at the larger group level. How that would translate, and how they could support people to get feedback at a faster cadence. Some people already knew how to do that better, so they started in their space. I was working with that team that was wanting to kind of run out ahead, and change how they worked. When they met with conflict with these other teams, they could go back to those rules and say, “Hey we can all agreed to look at fast feedback and that’s what we’re trying to do. Could you help us now?” Before it was a conflict between teams and a conflicting way of doing things. They couldn’t even have a discussion because I thought their values were so out of line. This was a way for them to start to have that conversation. They wanted to move forward not be blocked.
Ray: That’s cool. Back to Eric. You had said something earlier about the posters on the wall and everything. What I found with a number of teams is that they don’t have those posters on the wall. The values are SO disconnected — meaning that they might have spent ten minutes in a scrum class talking about what the manifesto was and blew passed all of the principals that are involved with it. Then just jumped into the mechanics. When coaches teach scrum, I think many do Agile a disservice because they spend more time on the mechanical portion. Versus, a retrospective where people really reflect against the values they want to follow?
Erik: Exactly. That’s the point I was trying to make at the beginning. We have to treat these things as semi-independent. They are mutually dependent, but we have to treat them so that we can invest in each one uniquely. Otherwise, one will get lost. Generally, I think you’re quoting the more common case where the values get lost, and everybody focuses on the day-to-day mechanics. I suppose the opposite happens too. But in my experience, it’s usually the values that get diminished.
Ray: Jorg or Dan, do you want to jump in?
Jorg: Yeah, one thought I have is to strengthen the connection between values and practices. Let me give you a simple example. I had been discussing feedback culture with the team. I pointed out to the team that they just got feedback from your team member and asked if they noticed it? The blank looks told me they didn’t notice. The team had said they wanted more feedback and it was done, but people didn’t notice it. They needed to strengthening this connection by acting on feedback immediately when it occurs. Mechanisms and values need to become one over time.
Dan: I wanted to go back to the original question and talk a little about the way it’s phrased and the way it’s set up. The question reads, “Tension in DEPLOYING Agile, start with values or practices.” First, the wording sets this up as a false choice. You have to start with X or Y. It’s not like there is a twelve-step program to follow: Step #1 is value, Step #2 is practices. That’s not how Agile transformations work. Secondly, they use the words ‘DEPLOYING’ Agile. Like deploying a set of training programs or deploying something in a mechanistic, roll-out fashion, making sure everyone complies to a new standard. I think it’s more like you’re cultivating a mindset. I know that Ray, you’ve been working on a piece about the Agile mindset. But that’s not something that “gets deployed.” Right?
Ray: Yeah. If you look at most failures that we see in businesses, they always step back and say that they were not following their values any longer. If you look at Toyota when they had some issues with the brake system. They took a step back and looked at themselves and said we’re not following our values. I think V.W. did the same thing as well. I think the reinforcement of values, and how they spread through the organization, and constant reflection on them becomes critical and important.
You also bring up that point of deployment. I mean do we actually or are we deploying Agile?
Dan: I would hope not. I don’t think you can deploy Agile at all. That’s my argument.
Rhea: Yeah it’s funny you bring that up because we had a conversation on the Agile PDX Slack channel about this. I realized some people were approaching it that way by how they talked about Agile. One person’s approach was like we’ll do Agile to people and kind of deploy it on them. Now I see that kind of language and framing. Versus how are we going to be, and how do we want to be? Start with where people are at and what we want to change and create together in a much more positive way. We can pretend to enforce things on people but we’ve seen that’s where Agile deployment goes terribly or deployment goes pretty bad and sideways. I think we’re seeing so many failures because they’re just trying to apply it to the people versus try to really understand what it means to be Agile. What is that mindset? How do we start with where we are and start to grow and build up these capabilities to be better in the future.
Ray: So deployment is deplorable? Yes. So what would be a better word to insert here? Do we evolve to Agile? Do some have an adaption to Agile? What would be a better word the we should start using?
Dan: There is probably a better word out there, but I like the idea of cultivating an Agile mindset. It has got an organic feel. Amplify things that are working. Don’t pretend to know too much about how to cultivate with precision. There are things that are going to work, and then they’re things are not going to work. Or foster perhaps?
Erik: Yeah. Foster or cultivate. I like the notion of adoption here rather than deployment. I just looked up online where the word comes from, thinking it was a military word, and in fact it is. It comes from French: to unfold, or to scatter, or to unroll. It generally said as pushing something into an environment. I think from a culture change perspective that doesn’t work. So, I like Dan’s terms, cultivating or fostering, and I think what the culture has to do is adopt. It has to pull.
Ray: I think it’s almost organic in nature. You need to have an environment that’s fertile enough that Agile can actually grow. I think there’s an environmental component associated. As a coach do we actually DEPLOY Agile? Or are we creating the environment where Agile can succeed?
Erik: Clearly the latter. This has to be something that the culture does for itself. Not something that is done to the culture.
Ray: Good point. Rhea?
Rhea: I really like that. I like the more, I suppose, complex or ecological terms. So that’s nice. It’s a nice way to start to get that kind of metaphor in people’s heads. If you’re going to like change the ecology of a forest, are you going to just put a bunch of pesticide on it and kill everything that doesn’t conform? Or are you going to look for an invasive species and start to dampen that and promote the growth of the more healthy native species in the system? Lots of ecological terms, but like in our business context — Where are people doing good work today that we can highlight, support, and amplify within the system. Maybe there’s some things we’ll start to dampen. Maybe by virtue of just showcasing that certain things are working so well. Also saying we’re not acting our values and we need to kind of course correct.
Ray: I fully agree with that. If I go to the Agile conferences, I think the problem that we have in the Agile community in general is there are a lot of people that are using the word ‘DEPLOY’. If I look at things like, and I don’t mean to pick on a couple of the frameworks that are out there, but frameworks where they’re disciplined. You know, we’re going to use a disciplined Agile approach to DEPLOY this within our organization and establish firm rules around the way that we should be behaving. The scaled framework just announced that they’re using more of a disciplined approach as well. Something that’s more compliance based and we seem to be going in the wrong direction.
Erik: In some cases I think that the discipline thing is just a red herring for engineering, but it’s the wrong word to use on a good day and it probably has a lot of bad side effects. So I agree with you. It’s not the right term to use.
Jorg: Actually, I think there is something to be said for discipline, if it evolves. If you stick with this growing perspective of cultivation, some trees grow pretty straight up. It’s beneficial to them. I’ve seen it at least one team really introduce a lot of discipline from the Scrum framework. They said we need this discipline to be sure we’re doing the perfect thing. They didn’t start with discipline, but they ended up learning that it was a benefit for them.
Ray: Take an example from the Eastern culture. I learned how to become a black belt in Taekwondo. In order to achieve a black belt, you go through all of these different levels where you’re learning to use motor skills. They teach that by having people practice rigidly about how to stand, how to throw punches, all of those things. They have a rule that you can’t break the rules until you become a master. And a master isn’t actually a first degree black belt, it’s a third degree black belt. When you get there, only then you can now be more improvisational. So, maybe there is a mix of some amount of discipline in there, but we would also let people grow towards mastery. I don’t know. What do you guys think?
Dan: I’m a huge fan of the principle of discipline. I want to completely separate the idea of discipline from deployment. I think they are two completely different concepts.
Ray: Ok, I agree with that as well.
Erik: Yeah. It depends on what discipline means. If discipline means the right things, then it’s a very positive force. But one definition I get on the web for discipline is to obey rules or a code to behavior using punishment to correct disobedience.
Dan: [Ooooh] I don’t care for that definition.
Erik: But that’s what it is, right? Because you discipline your pet. If the dog craps on the rug, you’re going to discipline the dog. And that’s a form of discipline. So it’s that aspect of it that troubles me, but I can see some aspect of the rules, behaviors, we need norms for sure. Just it just can’t go into this punishment stuff.
Ray: We see some of these aspects in coaching. Anything from shaming — “you’re not doing this correctly,” — to an extreme case — “we will be Agile and if you don’t get in alignment, yes, there will be punishment.” Punishment can come in the form of reviews or how merits are distributed at the end of the year.
Erik: So the question is under what circumstances is it appropriate to apply discipline? I think that when people fail in doing things that are established competencies, then some form of punishment is probably appropriate. One of the worst things you could do when people are trying to be competent and gain skill in some area is to punish them for failure, even though they tried. To me the only thing we need to punish in this move toward Agile is a failure to act. The failure to try is discipline-able, but if you’re trying to get better and make a mistake — my gosh, if we punish that, if we discipline that — it’s going to shut everything down.
Rhea: I would say even that gets tricky, failure to try. I know from how people change, a lot of it is environmental support and the surrounding context in which they’re changing.
Erik: Sure, that’s Deming right?
Rhea: Yeah and like Andrea Shapiro’s model. So people have to be very cognizant of that. I would even be afraid, because I think a lot of people are. If you’ve made sure that there is a supportive environment for them to change and they simply refuse to do so, then that’s a different thing.
Ray: Right, that makes a lot of sense. Jorg, you had another question on here “ “How can we make as much current information available to the team to make decisions and innovate easy, if stakeholders consider sharing hard and unnecessary.” Could you go little bit deeper on that question?
Jorg: Yeah. This comes from a case where product management is not really part of the development teams. They’re not open to saying this is the road map we are seeing - this is the direction we are going in. I’m unsure of what the motivation is for this lack information. Whether it’s really an instance of a little more work or not wanting to be accountable for the development team. Maybe it’s just still that waterfall feeling of ‘they’ only do code. I don’t have a clue. What I’m looking for is how to approach this and get this conversation rolling. Because it’s not happening naturally.
Ray: So, you have a situation where product management is making decisions off in the background and that information somehow is not getting back to the development team. And the reciprocal is not occurring as well?
Jorg: Yeah, the short term decisions actually do work. For everything that is in the scope of ~one to two months, the information sharing isn’t that bad. But there’s no outlook for the teams. What’s going to happen next? After that not even a really hazy one- at least not communicated. The official statement is “They don’t have a need to know.” Which is definitely wrong.
Ray: Ok. Yes, in the big-company culture where I came from, the Fortune 100 world, there tended to be this segmentation that occurred. Even with sales and marketing. If I wanted to go out and have a conversation with a customer, [sales] would have somebody in there to make sure that I, the evil engineer, was not selling something or somehow promising things. I noticed there was that compartmentalization. Another kind of compartmentalization was at the strategic level. We never had an input into the strategic plan. We just saw it when it came down from on high. Instead, we could have told them things that were possible or make a better plan by involving more minds. I think that cultural set has to do a little bit with distance. Meaning, how big the organization is. How many levels are there from where you are to the C.E.O. There haven’t been too many good fixes that I’ve seen that can create a more of a dialogue than just informing. Does anyone have any suggestions in this space?
Erik: On the one hand there could be some legitimate “need to know” information out there. Teams do things that bump against very sensitive strategic objectives. I suspect more often the case is that the people who are the withholding information, to tie back to our previous conversation, have been punished or disincented from sharing it. Because they’ve been beaten upside the head for changing their minds. Because people thought this is where we’re going and then they said no we were just being vague. Well that doesn’t matter. People forget this. So maybe you need to go back to the team that is withholding the information and try to create a better environment where that sharing is not going to be punished. We could put some estimate of certainty against the information, so that people know I can’t really take this too seriously yet. Versus- yeah, they seem very firm that this is where we’re headed.
Ray: It’s interesting. I think performing teams happen to be informed teams. There is a financial benefit to an organization to sharing more information and allowing people to see what’s course coming up.
Erik: Of Course. In instances like architecture, teams really do need to know peoples’ best guesses of what’s coming. So you don’t get into some sort of untenable situation just because you didn’t have your head looking far enough toward the horizon. But I would go back to that team that’s withholding the information and look at them from a cultural perspective. Look at their past performance and ask why is it that this team feels the need to behave this way? They are protecting themselves from something. What is it?
Rhea: I’ve definitely that seen that. There was a mix of not understanding what the impact was downstream on the other teams that they were working with. But also it definitely was protectionism. You have to keep your knowledge close because of how they’ve had to kind of suffer through in the past. That’s a really difficult thing to get through. I’ve been on a team where we had the very different perspectives on how to approach work. One thing that was happening was that teams were not talking to each other. They hadn’t even built up a relationship to be able to talk and understand that other team wasn’t there to like steal their information. Information the team legitimately needed since there was an impact downstream.
Try changing that interaction if you can. I looked for anybody that wanted to have a conversation with somebody on the other teams that needed to know the information. Talk and find those people that are willing to start to build those bridges. Because I think you always have to start changing the interaction. And to your point Ray, you’re right about not making it a one-way interaction. It’s a dialogue.
Ray: A couple the words that were used here about decisions and innovation and how to make these easy. I believe that a lot of people make too many decisions with too much certainty. They expect that this is exactly what we’re going to go off and build. When they do that they are actually closing innovation down. I think most senior leadership needs to actually step into the space of applying a vision and a set of goals that we want to go off and achieve. But don’t get too prescriptive so that it doesn’t feel like the teams have any innovation. They become so narrowly focused that if you step out of that boundary condition, then suddenly you’re off into the weeds. I think that more senior leaders need to stay away from making too many tight decisions. Dan what do you think about all this?
Dan: I think that the further a road map goes out in time, there is more uncertainty. If teams can present it as Erik was saying with confidence levels, or a landing zone format, or set-based, or a set of options or optionality. Maybe that’s a way of relieving some that pressure for being exact and precise. Back to Rhea’s point, look at the interactions between these two groups. How do you convince the planning organization or the product management organization that it is actually beneficial from a business perspective by being more transparent. Perhaps one could try setting up something like a code review session for the road map. Where you would have peer-level coaching and provide inputs and insights into what people think is going to work and not work. What needs to changes to make a benefit for the product manager to share as opposed to a penalty.
Ray: Ok. Jorg, did that help?
Jorg: Yes, a lot. One idea I am taking with me is to try and push back with a set of options based on the information furthest out. That might really start the discussion by proposing something instead of only asking for a change.
Erik: One more little pragmatic tidbit that comes from Tom Gilb. He’s created what he calls a credibility index. It goes from 0.1 to 1.0 in ten steps… 0.5, 0.6, 0.7…0.1 means we’re making it up. We really don’t know what’s happening here, but this is our best guess so far. 0.9 is where we’re all but certain of this. This has happened before. It’s never gone wrong, and we’re strongly believing in this as the right result. You might be able to attach some sort of credibility index to a lot of the information that’s passed out to inform people explicitly - we think we’re right on or we really don’t know what we’re doing.
Jorg: That’s good. Thank you.
Ray: Ok. It looks like we are at the top of the hour. This is the conclusion of the Agile Coaching Network. I want to thank everyone here. Great participation. Let people know that if they want a particular question answered to post a question to Sli.do and listen to the podcast later if they cannot attend. Have a great week everyone and take care.
If you enjoyed reading this and want more ACN sessions transcribed — please let us know at firstname.lastname@example.org