 Thank you for joining us on this edition of the Agile India interview series. We're your hosts, Chris Edwards and Sean Dunn. Agile India 2017 is Asia's largest and premier conference on Agile and Lean methods. This year's conference will take place in Bangalore starting on Monday, March 6th, where experts and practitioners from around the world will share their experience. For more information, please visit 2017.agileindia.org. Our guest today is Esther Derby. She is an independent consultant and author of the book's Agile Retrospectives, Making Good Teams Great and Behind Closed Doors, Secrets of Great Management. Esther, it's an honor to have you join us here today. Thank you. Thank you. Thank you for inviting me. I'm happy to be here. So Esther, you served on the board of directors for the Agile Alliance for a number of years. You've seen a lot of transition and change in the Agile community over this time. And you've seen the use of language come up a lot. You know, we talk about Agile evangelism, Agile coaching. We have all these metaphors for what we do in the Agile community. And so I'd like to know what your thoughts are on our choice and use of language in describing Agile and what impact does it have on our perception of it? Sure. First, our minds work with metaphor. I mean, that's basically how they work. So we hear a metaphor and it kicks off a little story in our head. And then that story affects what we see as possible and what we see as not even in the field. So, which is a metaphor. The words we use, I think, have a big impact. And evangelist is one of the ones that I think really gets in the way sometimes because it presumes that the person who is labeled as the evangel is bringing the light to those who have been in darkness. And that devalues the knowledge that the people were trying to help have. And I think makes it more difficult for people to be willing to hear and really engage in moving towards Agile methods or applying Agile concepts. Because to do so, you have to admit that you've been wrong your whole life. And I think that just makes it hard. I think that's interesting because when a lot of times coaches get brought into teams, we're brought in as someone who's there to maybe fix them. So if we're thinking about things from a perspective of judgment on people, it's going to be hard for them to hear what we're saying. So what have you found helpful as an alternative to help make change happen? Well, I think it's useful to start first by centering yourself. So you're clear about where you are coming from and what judgments you might have and try to soften them to the extent you can because that stuff always leaks through. But I find that it's often very helpful to work first on a problem that people perceive and experience as a problem rather than trying to come in with something that you have to convince people about. So if you can actually help people with something that they care about, they're going to be much, much more likely to want to listen to in the future. And then you can start introducing other sorts of ideas and work by attraction rather than having to work by persuasion or brow-beating in the worst sorts of situations. The whole concept of coaching is one of these other metaphors, and we've seen a whole industry of coaches and coaching, which I think is a fairly interesting and new phenomenon. I don't think elsewhere in our history of industry that we have coaching as an industry. And is that a viable approach for our business? And I think that coaches are very well-meaning, very intentioned. I've been one myself. But like you say, if coaches are brought in, is it much better than the evangelist approach? Well, coaching is really a broad field and there are a lot of definitions of it. I think it can be very helpful to have someone working with a team or working with a group of managers to help them examine their processes, examine their thinking, facilitate, move towards a different way of doing things. I think all of those things can be super helpful. The model that we often have of coaching is pretty limited, that it is in some ways more akin to counseling than to looking at what the actual systemic situation is and trying to move it forward. When I teach my Coaching Beyond the Team workshop with Don Gray, we actually talk about nine different coaching roles that you can take. And they're arranged on a grid that looks like responsibility for improvement and responsibility for results. And that grid, we find, enables people to be much more choiceful about how they approach a given situation, how they enter a group, and how they enter different relationships. Because very often what I see is a manager will hire a coach to coach that team over there, which is kind of viewing them as, you know, you're a hands-on expert to go fix that team. But then that coach will try to coach the manager without having the relationship, without having the agreement from that manager that they need coaching, they want coaching, they want it from that person. So it's very often taken as sort of a blanket, I'm a coach, I'll coach everybody and anybody without recognizing the relationships involved and the fact that status plays into it. Any time you're offering help, status comes into play. And I see that, well, I don't see that attended to in a lot of the situations where coaches are working with teams or with the managers of those teams. Does the language get in the way of the expectations that a company or a person has when they bring you in? If there's nine different types of coaching and you're being brought in as a coach and they have a different expectation of what that's going to be, then you do, does that get in the way? Sure, sure it does. And that's one of the ways we see people use that grid is to say, okay, so you're hiring me to do this, but these are the other kind of roles I can take that can be helpful. Or from your vantage point, you're viewing me this way, but that's a different relationship than I have with you. I have one relationship with the team, I have a different relationship with you. So I think it's very helpful to be explicit about what you're doing, at least in your own mind, and then navigate it with people. So one of the roles I think that sometimes coaches take is teaching. They have some knowledge about principles and methods and ideas that they can impart that can be very helpful. So it's not just a matter of, you know, I'm going to ask questions and hope you get some place. Sometimes teaching is an important part of coaching, but it's also a tricky one because people as adults need to accept and invite someone to be their teacher. You can't just assume that you've been given that permission to teach and that one's really, really tricky because it's a very up-down status. We've learned that our entire lives that teachers are in positions of authority and have status and so that's a really tricky one. So do you need to spend a lot of time when you're first working with people just building that trust so that they can begin to open up to you and extend that invitation? Sure, I think it's important to have some sort of connection with people. I mean you can't just have a transactional relationship and do any kind of significant work with people. So it's important to have a relationship and there's kind of a span of it. You know, on one hand it's just transactional and that's not sufficient to build trust and really make changes. And on the other hand, on the other extreme, it's intimacy which also isn't a great situation in which to be a coach because then the status stuff gets all messed up. So having some connection I think is super important. Super important. You mentioned a few minutes ago about how we first need to understand and identify what problem we have to want to solve and then bring in a coach or someone to solve that problem. How often do you see, let's say managers believe their problem to be the development team itself and they hire the coach to come in and as you say, fix that team with those developers into shape. Is that the most common model that we see? Is coaches hired by managers to fix teams and how do you get around that? Well, I see that a lot. I actually see that a lot where it's assumed that the team is the problem and sometimes the team has problems, some of which are of their own making and many of which are related to how work flows into the team or the fact that they don't have a supportive environment for collaboration or any number of things and then you have to shift your relationship to one where the manager is willing to engage in problem-solving with you. So what I don't find works is going up to the managers and saying here's your impediments list. That's not such a great strategy. But if you can build enough rapport that a manager is willing to work with you on some of the problems and not feel like, well, you're saying I'm the problem then you can actually get some significant traction. Do you have any advice or strategies for building that rapport? So find mutual purpose. Find something that they care about and connect whatever it is you want to do to that. I also think it's really important not to personalize the problem and say you're the problem. This managers, for the most part, I would say the vast majority of managers want to do a good job and they're working out of a legacy of thinking and a legacy of management practice that isn't necessarily sufficient for the complex environments that we're in. So they're doing the best they can with what they've been taught and what's worked in the past. So not personalizing it but saying it's a system problem, it's not between us, it's outside us both. And I guess they're working with their own set of reward systems and constraints on their own that can be influencing the way they lead. Well, that and they're working with a whole system of management practices that are built out of a set of beliefs and assumptions about how organizations work and most of them date back to factory situations and ordered systems and the sort of thinking about people don't want to work hard so we have to figure out the sticks and carrots to make them work hard. And telling them they're wrong isn't likely to get there by in either. So you have to frame it as a problem not with them but a problem with the system. So you bring up a very interesting point about systemic problems in organization and how leaders whether deliberately or unconsciously have been taught through their careers to think about systems and rewards and motivating people in a certain way which isn't necessarily correct but maybe it's not exactly aware to them why they think this way. So how do we break out of that? How do we address the systemic issues in organizations where we're not necessarily teaching leaders from the beginning of their careers to think about these the right way? I would offer a refinement of not the right way but in a more effective way because there's a lot of ways to think about it. What I often do is when someone posits a causality I try to get behind that. So this is one that I hear a fair amount actually. Why are people accountable? People are just accountable. Why do you suppose that they aren't stepping up in the way that you would hope they would? And so I try to ask a lot of questions to get behind that. Sometimes I start sketching things to show that there's actually many entangled causes and I find that that often will get people to shift their thinking. But the accountability is one that comes up a lot. If everybody just did their job and was accountable, not so much. Sometimes I wonder if we're missing an abstraction or in the agile community we're still struggling with abstractions around management and leadership and coaching because there's this whole thing people talk about management versus leadership and then we bring coaches in who seem to take on certain leadership activities and roles and then managers are maybe struggling to figure out where they're left with this. Going back to your sort of comment about metaphor and language, are we still maybe struggling to figure out the right language around these abstractions? Yeah, I think so. I actually don't buy that there's a clear dividing line between management and leadership. I think it can't be a good manager without being also a leader and I think that leaders who don't have any skill at managing set up all these expectations but there's no follow-through. I think some of our traditional definitions of leadership are particularly helpful because they tend to rely on positional power or charisma or the ability to create a vision. All of those are nice but they tend to be focused around one person who is the leader and I think particularly in complex environments and in agile environments if we can move to a definition that says and this actually comes but I'm not going to get the quote entirely right but it comes from Jerry Weinberg that leadership is the act of adapting and adjusting the environment so that everybody can contribute creatively to solving problems. That shifts leadership in an entirely different way. So it's not about who gets to tell who what to do, who creates the vision. It's more about how can I make sure that this environment is such that everybody can bring all their smarts to bear and I think that's a very very powerful definition of leadership. I like that definition because it fits with a lot of the agile practices which shift the responsibility of delivery and getting work and projects done to the team but then what do I as a leader focus on and now I can sort of have a bit of elevated thinking and think about other things and how do I grow and develop the organization and the people. Exactly, exactly. I think that's one of the missteps that happened early on in agile is that there was this kind of crime. We don't need managers, we're self-organizing, we don't need managers and that of course just made people feel like I'm not valued, there's no place for me so of course people sometimes embrace things with open arms. I actually think there's a hugely strategic role for managers when teams have the clarity, the conditions and the constraints to self-organize in an effective way and work on the right things because of the clarity. Then managers as you say can work on the system and that's a hugely strategic role for them. I can look at how is work flowing into the teams, they can look at what are the conditions for the teams, they can look at developing people, they can look at are we actually building the right things, they can be looking at how well is our system functioning in terms of our cycle time all of which is far more valuable than telling people what to do in the long run for the organization. From a historical perspective, this is actually an interesting point my friend brought up which is that I worked in a waterfall organization or several back in the day, Chris did as well. There's some of us, industry veterans who have been around and seen waterfall and experienced the challenges of waterfall and being told what to do in Gantt charts and resource leveling and how these things don't really help. But more and more people are coming out of school and going straight into agile organizations or quote unquote agile organizations and without ever actually experiencing maybe the problems that a lot of these methodologies were trying to solve and is there a risk to that? Are we not teaching people the history and so they come in and not really understanding why these things exist in the first place? Well, just like managers aren't generally taught the history of management and how these practices came to be, people generally are taught the history of how waterfall came to be which is a desire to separate the smarts from the head from the hands. We had the smart designers designing all of the systems and writing all the specifications then you could hand them off and you could use lesser skilled people to do the work. Which means then you have to define everything up front. So those are some of the history behind that. And if you're unaware of that and you don't question it then those assumptions are just kind of baked into the practices and you do them in this sort of roadway. All practices come out of principles and beliefs about how the world are and the same is true for management practices as it is for the waterfall practices that many of us experienced. Although I must say when I started in this field and I started as a programmer the way we worked was much more akin to Agile than it was to waterfall because we would figure something out. We get a big overview of something. What's the system we're building? We're going to automate all of the calculations for doing those little strengths that go on the side of cars, which is actually a system I worked on at some point. And so we had the big picture. We knew what we were doing. We knew what the economics of it were. But in terms of actually writing the programs we'd write, we'd get a little piece going. We'd test it. We'd get another little piece going. We'd test it. And that's the way we worked. And we worked very closely with each other. We worked together a lot. We did our own testing. So in some ways Agile is going back to the roots. And it wasn't until I worked for a big company that I experienced the sort of we must plan everything up front. We must nail down every detail and know everything up front before we start. And I actually have seen that work once, twice, twice I've seen it work. You mentioned before accountability and you have lots of organizations really driving and wanting more accountability, believing that this is going to solve their problems. The other one that often comes up a lot is predictability. They want predictability and often that goes hand in hand with accountability. What do you say to those types of organizations who are really striving for this high degree of predictability out of their teams? And is that possible? Well, for most of those organizations, they already are predictable. It is already predictable that their projects will be two or three or five or a thousand percent over time budget. It is already predictable that the teams will only be able to deliver 60 or 70 percent of what they say they'll deliver at the beginning of a cycle. So for organizations who are people in organizations who say they want to be predictable, in general, they actually want something else, which is they want to be able to make commitments that they can then follow through on. So if they just would say, okay, we know that historically we have never had a project coming on time, why would we possibly commit to this? Let's look at the historical factors of how late things have been or let's look at the historical factors about what the team has delivered based on commitments. They would already be more predictable, which is a hard thing for many people to wrap their heads around. Commitment is an interesting thing because there's like a series of commitments and I as a manager are being asked for commitments from my manager, so I'm then wanting to ask it from my people and it sort of flows downhill from there. Well at some point somebody has made a promise, because most of the dates that we come up with are based on someone has made a promise, somewhere in the organization, usually very, very high up in the organization, and the pressure to actually deliver it flows downward without necessarily a high level of understanding about the capacity of the organization. So I don't blame people for saying I want this, I don't blame people for that at all, but those commitments are very often made without an understanding of the capacity and very often the data is there but it's not listened to, so the data that we can deliver, 70% of what we say we want to deliver, that could actually be used in planning, but it typically isn't. It's typically no, we want to choose this date and then we want to hit the date. Well, use your data, use your data. So how do you, it's a very complex issue and when you come in and deal with organizations, what is kind of your heuristics I guess, you come in and kind of do a mental assessment, I know I kind of have my own mental checklist and I'm working with new teams or groups of people, what are some of the things that you come in and look for to get a sense of the landscape and what the challenges might be? Sure, I look at three main categories. So I look at clarity, I look at conditions and I look at constraints and I look at those in three different domains. So on the steering level I'm looking at which is broadly setting the direction for the organization. Do people know who their customers are? Do they know where their product, what their product is? Do they know how it fits in the market? Do they understand the difference it makes for their customers? What problems it solves? I look at sort of the overall conditions of the organizations and I look at the constraints. Usually at that level it's in terms of culture and policy. And then on the enabling level it's like how do people order work? How do we know what to work on next? Do teams have the conditions to work with and is there bounded autonomy for decision making? And then on the doing level, again I'm looking at clarity conditions and constraints, do we know how we're going to accomplish this? Do we know who's working on what? Do we have the conditions and skills and are we taking all the advantage we can to produce great products? Do we have the agreements about how we work together that will help us be effective? So broadly speaking I'm always looking at clarity conditions and constraints on the steering, in the steering domain and the enabling domain and in the doing domain. You mentioned cultures as part of that list. What does that mean to you? How do you gauge culture? So I look at what people always do and what they never do and what they say about that matches that. I look at beliefs about how people are motivated. Some cultures still think that people won't work hard unless they're pushed. So I look at things like that, I look at the stories people tell. It's kind of a big fuzzy thing and I wouldn't say that I actually try to change culture as much as I try to shift patterns, the recurring events that happen over and over and over again in organization by looking at clarity conditions and constraints, because those are essentially the levers you have to shift patterns in an organization. Earlier we were talking about sort of the change in leadership style that's required, which my own experience is involved a bit of a rewiring of my brain in the way I think about leadership. Now, is that something that will happen organically as you adjust these conditions and clarity and constraints in an organization or do you need to back that up with leadership skills training or is just kind of that leadership part of that core culture of the company and the way people act and behave? Sure. So I try to shift the definition of a little bit by having conversations with people and there's the element of how people are thinking about things and it's the element of how people are doing things. And what I find is that very often even if managers mentally make the shift, philosophically they make the shift, they may not have a repertoire that supports that new way of doing things. So sometimes it's a matter of expanding some repertoires. You know, people have been doing something in a particular way for 10 years. It can't fault them for a lack of imagination if they don't automatically don't want to do it differently right away. So for example, I talked to a guy who he was trying to focus on having workflow into teams more effectively. So he was real focused on are the stories in a condition, do they have enough definition, not perfectly defined, but they have enough definition and architecture thinking behind them that the teams can actually work on them. So he came up with a way of color coded rating. Is this a red, yellow, green in terms of is it ready to work on? And then he started talking about I want to see all these things green. And what he really wanted, and when I challenged him a little on this, he said, oh yeah, that's what he wanted. He really wants the work to be in good condition to flow into the team. So the teams aren't churning. So they're not having to go back and forth and they're working on things that haven't been, you know, that they have to have an excessive amount of definite redefinition at them when they're going in. Because there's always some learning. But he was very used to focusing on targets. I want them all green rather than what the outcome or the impact he wanted to have. And I find that that's very often the case that people focus either on activities or they focus on targets when what they really want is an impact or outcome. That resonates to me. As I was first sort of taking my own steps into, you know, servant leadership and changing the way I thought about things, you fall back onto your habits because if you don't have another way, you just sort of, I know this isn't the right thing to do, but I don't know what the other thing is. And I think maybe this is why a lot of agile community went into the, you know, management's bad. We just have no management because we need to replace it with something. Management is an enabling function, right? It's not to tell people what to do. It's to create the conditions where teams can effectively self-organize and effectively self-manage. That's powerful active leadership. It's a huge active leadership. But we haven't traditionally been taught those tools. We've got the MBA school. They don't teach you how to do that. If you come up through the ranks, you don't learn how to do that. You learn, you know, different stuff that is not all of its, should be thrown out. I mean, a lot of it's really quite valuable. But it's a matter of saying, well, given these principles and given that this is what the impact I'm trying to have, what is the best way to do this? What advice would you have to the new manager, the new leader who wants to build that set of repertoire, who has a blank slate and wants to learn these things? If you've got no patterns and no heuristics to follow, what would be the best place to start out? Well, I'd start by understanding something about group dynamics and systems. And so I think probably the best short book on systems is Donella Meadows' book. And it's, yeah, I mean, it deals more with natural systems than human systems. But there's certainly a lot of parallel. I'd look into complexity. I'd look at the Kinephant stuff. Yeah, and I'd look at, you know, something about human and group dynamics. Most of which aren't really talked about in management. So I'm going to find interesting talking to people who are quite experienced and speak in the Agile community. Is the word Agile actually doesn't get used that much? And, you know, when you're talking about metaphors earlier, the word Agile I think has changed meaning to a lot of people over the years. And, you know, there's a lot of blog posts that were out around, you know, is Agile dead? And where is the Agile community going? Yeah, do you think that the word Agile has just become, I mean, as we learn more about all these other domains that are applicable to us, like as you said, group, you know, group dynamics, complexity theory, and we realize this does have very significant impacts on how we work and falls under kind of what we're trying to achieve with Agile. Does Agile become so diluted that it no longer has meaning? Maybe we should be focusing more specifically on these domains? Well, you know, I think the word has certainly lost its punch. You know, it's used to describe just about everything now, you know, some things which I would not recognize. And it's used in a much broader sense than it was. You know, now it's no longer Agile methods for software development, it's sort of become much broader. And, you know, I think that the core of XP practices is still completely relevant. Those technical practices are still completely relevant, although I think there's new practices that have come along. But yeah, I think that just focusing on Agile is not sufficient. You know, Agile software development is certainly powerful, but it's not sufficient in terms of getting an organization to work effectively. The other thing that I find, well, let's just say sort of surprising but not surprising is that it seems like Agile methods have become frozen in time. There's so much emphasis on you have to do this by the book, you have to do this correctly. There's nothing Agile about just mindlessly following a book. It's lost sort of the expect and adapt and grow and discovered new practices that are even better. Our development environments have moved along enormously since we started. We have new technologies we're working with, new architectural constructs that we're working with. And so to kind of freeze Agile in time is not serving anyone. So do you teach methods and practices when you coach? I haven't actually written any code in a long time, so I don't focus on the technical practices. Well, I guess other practices like scrum. I mean scrum is probably the most common Agile like process I guess. Well, and I seldom see scrum succeed without entropy practices. Right, so sure, I mean I think sometimes working iteratively and incrementally is a great way to help people begin to make progress. I think sometimes depending on the sort of work, Kanban can be effective. If you're in a sort of role where you're just getting requests and acting on them in the order they come in, sometimes Kanban can be more effective. But yeah, I think effective thinking is really where I put my emphasis rather than on any particular silver bullet sort of solution. Yeah, that's a very interesting idea, effective thinking because it's not something we necessarily teach or we talk about in organizations and in companies. You say like as effective thinking is something that I as a leader necessarily are developing my people around me and is thinking about things. Do you see that's a shift companies can make? Is this is something that effective thinking and critical thinking is something we can value and develop ourselves in? Oh, so, I think we're sunk if we don't. The latest thing we come from is and this goes back to the Industrial Revolution and even earlier was separation of head and hands. You know, the managers were the thinkers and the workers were the doers. If that ever worked, it certainly isn't appropriate and knowledge work. It just makes no sense. So I think developing people's ability to think is fundamental. To come full circle then, we started off talking about how the language we use is so important and influences, you know, what we reflects what we value and influences how we perceive these changes. If this concept of critical thinking and developing thinking is what we should be valuing, how do we change the language? How do we change how we talk about these things to reflect that? I'm thinking. Critically, I hope. Well, you know, I think that, you know, we can use language that's more accurate, you know. So when we talk about change, we're not talking about driving or evangelizing. We're talking about we're going to learn some new ways of doing things. We are going to examine our current assumptions. We're going to examine our current practices because really that's a lot of what's involved in making any sort of change. So changing that language to be more accurate, I think would cascade into, you know, we have to think about what we're doing. We have to examine our practices deeply. We have to look, we have to understand the problem we're trying to solve. And then and only then can we choose an action that is likely to be helpful. So what's next for you, Esther? What's the big interest you have at the moment in upcoming initiatives? Well, I actually have two books going on right now that I'm working on. So one is called Six Rules for Change, which touches on some of the things we've been talking about. And there's also a little video on my website of a talk I did. I first started working with that idea. And the other is also related to what we talked about, which is I'm co-writing it with my colleague, Don Gray, and it's based on the material in our Coaching Beyond the Team workshop, which is how do you actually help an organization change? So how do you center yourself? How do you enter the organization? How do you turn the organization by engaging in joint problem solving, not just with the teams, but with the managers who are in a position to influence broadly influences the system? Those were two big projects. And for our listeners, we will have links to your books, Agile Retrospectives, and your workshop, Coaching Beyond the Teams, available when we post the podcast. Fantastic. Yeah, and yeah, we'll link to the other book you mentioned earlier too. Thank you for your time, Esther. It was really great having you, Andesh. And these are very interesting topics, and I'm very excited to read your new books when they come out. Thank you for joining us today on the Agile India Podcast. This video is produced by Chris and Sean Agile. You can find us on Twitter at ChrisSeanAgile and at our website, www.christenSeanAgile.com. Thanks for joining us today. We hope to see you next time. Thank you.