Middle Management and Lean-Agile. A Conversation with with Dr. Tom Grant

 
Share
 
Manage episode 150894990 series 26821
By Discovered by Player FM and our community — copyright is owned by the publisher, not Player FM, and audio streamed directly from their servers.

Middle Management and Lean-Agile: A Conversation with Dr. Tom Grant

Dr. Tom Grant and Jim Trott discuss the implications of Lean and Agile software development for middle management. The role is changed, with different skills and behaviors required. Managers transition from being directive to enabling teams to be self-organizing. There are changes in performance evaluations, metrics, and power dynamics. They get into the team's life "just enough" in order to be helpful.

Coaching middle managers in the transition to Lean-Agile is also different: helping them acquire new skills at just the right time, learning how to do retrospections. Tom suggests using "Serious Games" as a way to help this transition. He also discusses the influence of the various Agile frameworks on management and the transition to Lean-Agile

​Dr. Tom Grant is an analyst covering software development and delivery. His specific focus areas include Agile, Lean, application lifecycle management (ALM), requirements, serious games, and the innovation process. He has also taught political science at UC Irvine and Chapman College.

This show is part of a regular series of conversations with Net Objectives consultants and thought-leaders on a variety of topics. We call this series, "The Doctor Is In!"

Recommendations - Reading and Sites

Music used in this podcast:

  • “And So It Begins” and “Easy Lemon” by Kevin MacLeod © Incompetech Inc.
Blog Type:
Podcast

Transcript
Introduction

In this show, Dr. Tom Grant and Jim Trott talk about the implications for Agile and Lean for middle management.

View Full Transcript

Jim Trott: It's July 19, 2016. This show, "The Doctor Is In." with Tom Grant.

[background music]

Jim: Hello, and welcome to another edition of Lean‑Agile Straight Talk, a regular podcast series from Net Objectives. I'm your host, Jim Trott. In this show, Dr. Tom Grant and I talk about the implications for Agile and Lean for middle management.

Dr. Grant is an analyst covering software development and delivery. His specific focus areas include Agile, Lean, application lifecycle management requirements, serious games, and the innovation process. He's also taught political science at UC Irvine and Chapman College.

In this show we're going to discuss many issues that impact middle management, in a Lean‑Agile organization, including things such as what changes are required for middle managers and what new skills are they going have to acquire?

When should middle‑management be trained in the Lean‑Agile process, so they can be better enablers of Lean‑Agile for their own teams, implications for managing performance on self‑organizing Agile teams, implications for retrospections and power dynamics and metrics, the dynamics involved in coaching middle‑management for the transition to Lean Agile, and the use of serious games that coaches can use for developing Lean‑Agile culture.

It's a really interesting podcast. You're going enjoy it. Before we get started, I want to remind you that you can explore more about this topic and other topics by jumping over to the resources section at www.netobjectives.com.

At Net Objectives we are committed to discovering effective software development methods, so that we can assist organizations in becoming more successful. We combine our experience to continuously extend the capability of what is possible in creating effective software development organizations.

We provide these approaches to our clients and the community in general, so that we can assist people in achieving their goals, in making their organizations more successful. Our scope includes a Lean, Agile, Leanban, Kanban, Emergent Design and Acceptance Test Driven Development. We welcome the chance to work with you. We're always learning and we invite you to join in. Visit us at www.netobjectives.com.

Let's keep the conversation going.

We're really happy that you have joined us today. Tom, I wonder if you'd like to introduce yourself and set the stage for us.

Dr. Tom Grant: [inaudible 2:57] a flattering introduction from you. [laughs] I don't know what I can say other than for the first, The Doctor Is In Session I actually do have a doctorate but I also know some people who're not terribly smart to have a doctorate, so I'm not sure what that exactly portends.

Anyway, I would to add to what you said that I certainly have had a lot of experience with the topic du jour, I'd be happy to talk about a lot of things but we're going keep things off talking about Agile and middle‑management as that seems to be a fracture point or a stress point in a lot of people's Agile transformation project.

If you hear me occasionally speak passionately about this, it's probably because it's based on a true story or two stories.

Jim: Two stories are good.

Dr. Grant: You should introduce yourself, Jim.

Jim: Thanks. Jim Trott. I've been with Net Objectives 15 years now. I started working with Al Shalloway. We wrote, Design Patterns Explained together. He's lead author on that. It's been just a great experience with Net Objectives. Prior to that, I came out of model building, knowledge management and artificial intelligence; working for a variety of oil and aerospace and banking before I opted to come here.

It's been a pleasure to get the chance to work with everybody here. I wonder, Tom, as we get things going and people will start to want to ask questions, what is it that makes middle managers anxious about Agile transformation?

Dr. Grant: I will say a lot of justifiable reasons. It certainly strikes at the root and branch of a lot of, not only, what people in middle‑management roles see is their position with the organization, but how they see themselves as managers. There is a deeply personal element as well as a somewhat highly practical side to it as well.

First of all, of course, they're like everybody in an organization that's undergoing Agile transformation. There is the shock of the new, the number of different practices and principles that people have to absorb.

This is one of the reasons why it's important for managers to be part of Agile training. I always welcome having managers even if they're not members of the team in Agile training, so that this can help their education process along. There's also not a lot clear role defined in Agile for middle managers.

There's certainly a lot of very good instructions in the Agile manual about what a team should be doing, it's a team‑centric methodology, but where managers fit into that is completely unclear in the picture from basic core Agile.

I'm not talking about what's happening out is with frameworks, or what we at Net Objectives like to talk about concerning Leanban, and other Lean extensions to Agile. The team‑centric model itself is non clear.

Aside from the shock of suddenly doing estimation differently, doing planning differently, defining requirements differently, teams self‑directing themselves, and so forth, there's a whole ethos about how the organization needs to support the team that something that is going to be new to a lot of people.

It's going to change day‑to‑day behavior for everyone to some degree, but I think especially for managers. They worry whether they'll have a job in this new world order then if the same teams are self‑directing, and self‑organizing, then what do I do as a manager?

This is where I think that highly personal element lies. That is people will often in middle management positions have been struggling just to keep the highly complicated projects, or products that they've been working on moving forward, and therefore they've had a very directive role. If they've felt like they were setting on the battlements against chaos for however long they've been managers.

That the only real sure weapon that they had against things falling apart is been understanding what my people are working on, understanding what their strengths are, re‑assigning people, telling them how they should be prioritizing the work items that they're facing.

Telling them how to address a lot of the problems that they're facing, suddenly pulled a prune on that, and it's not just, "Do I have a job," but, "My God, what is my worth?" [laughs] Almost as a human being at that point. There is a lot of good reasons to be anxious as a result of Agile transformation.

Jim: Yeah. In this conversation, a time where middle management...You said that they have some cause for concern, I wonder if you could...how does Lean address that? What conflict can you give?

Dr. Grant: Lean certainly helps a lot, by focusing everybody to the extent that they're really absorbing what Lean is all about on things like, first of all, flow. What is the flow of an activity within the team? What's the flow within the larger value stream?

Then it's easier for managers to see, "All right, if that's really where I have a value at, and in helping teams maintain their flow, then sometimes I might best be able to help that by stepping back."

Now, what else I do in the support of flow, or let's say, a focus on value, or other really good things about Lean, is probably the area where managers have to either dust off skills that they have left on the shelf for a bit, or are not done as much as the more directive function often, or pick up for the first time, sad to say.

Those are things like, for example, I'm a manager and I am thinking about my teams long‑term technical challenges. I don't want to jump in and tell everybody how they should coat things, how they should test things, what platforms they should be using, but I can be looking ahead of that.

If we see things coming down the pipe. For example, one very disruptive event, when I was coaching a team, was a big SAP upgrade. That's something that the manager can help a team deal with in different ways.

Often not even involving the team, smoothing a way for them, or acting in an advisory role to make sure it isn't as disruptive as they thought it would be, the panic initially of, "Oh my God, this is going to completely mess up our spring plans or our release plans." That's something that the manager can help with.

It's, again, focusing on what it is that Lean tells you is important, such as flow, or waste, or value, or those sorts of things. That's going to mean having an indirect role with the team rather than a direct role, but that can be a good thing.

Jim: Here's a question from a reading. "Do you think that middle management should be trained before they're trained, so that they can help teams be successful rather than becoming impediments to their success?

When should middle management or management be trained in Lean‑Agile, as you're introducing Lean‑Agile techniques into the organization? How do they become enablers rather impediments to that process?"

Dr. Grant: That's an excellent question. Boy. I've certainly seen it work really well to have some number of managers involved. Sometimes it's a core team who is responsible for the Lean‑Agile initiative. Sometimes it's the managers who are most involved with the teams that are going to be going through that training.

They can smooth a way a bit. As I was saying before, one of the functions of management is to smooth a way. Smooth a way often means having teams themselves don't become impediments to their own work.

A manager who, for example, takes a Lean‑Agile course, and has little time to think about, "What does this mean for our project? What are the challenges that the team is going to face in collaborating with the customer? What are the challenges that they'll face in breaking down stories, or overestimating stories effectively. There are other things that they might be facing.

Also, too, pondering to what extent that the Lean‑Agile practices and principles are going to create frictions in the organization, and how the manager might anticipate some of those, and, again, play a productive role and a very diplomatic intervention here and there on behalf of the team. Those of the sorts of things, that having an advanced team of managers can help with.

At the same time the one disadvantage of that is that there's nothing quite like going from the training right into doing Lean and Agile. That you don't have the benefit then of not just the experience that you get out of the workshop, which is often a surrogate experience of what it is like to do these disciples, but really having the hands‑on discipline.

You're not on the team, you're not necessarily going to be then getting the benefit of the initial challenges in building the backlog and estimating it, and going to plan, and so forth. You're not going to have a coach around to help you with that.

There are many things that may not be altogether still clearer to the manager that might actually be clearer to the team once it gets through the training and gets immediately started. That's the one minus I would say to the idea of doing managers ahead, but it's not a big minus of that particular strategy.

Jim: This is another question that just came in, as you're training managers, they've got to build up their own skill set in this new approach. It's not entirely new, right? Some of these things are things they've always done, but other things they've got to learn.

Dr. Grant: Yeah.

Jim: What makes an effective of good middle manager in a Lean‑Agile environment? The second part of that question is, why are they so many patterns? [laughs] .

Dr. Grant: Yeah. I don't completely blame them. It is a bit of a shock. Again, it has been often the case that the organization was incenting highly directive behaviors on the part of the manager, that are now much, much less useful, and, in fact, highly disruptive as an anti‑pattern to Agile.

I would say that there are things that if your manager go beyond just the directive part. For example, just mentoring people who work for you. I don't know how many times I have seen managers who just don't have the time for that. That they're running off to meetings. They are often, in many organizations, individual contributors themselves or they're trying to balance their managerial duties with checking in code or doing other kinds of activities.

They're just not able to effectively be managers in that mentoring sense or, again, being the look ahead radar of the team. That even though you're not part of the team, that there maybe things tool‑wise that you could be looking at that might help the team further down the road, or technology changes that are going to be important, or other things that will be affecting the team, but you got to have the head space and the open time in your calendar to be able to look at those things.

Once the pressure to be a highly directive manager goes away. Once the team becomes more self‑organizing, self‑directing, I'll be honest, not every manager enjoys doing some of those other functions. There are other ones that I haven't even named, but there's a list of things to do as a manager that don't involve telling people what to do, that are highly useful, that really are the core part of being a manager. But not everyone really not necessarily enjoys them.

There would be, I would imagine, in any organization, and certainly I've seen this, some number of managers who, their definition of manager is so restricted to that directive role that they just don't like what it means to be a manager then.

There's no easy way to deal with that. Often those people may transition to other roles, or they may go back to being individual contributors, because they get a lot of satisfaction out of that, being a senior developer again, or an architect, might be, a great job for some people. In some cases, as I'm being completely frank, it's the case that people don't enjoy doing that.

It's the same with a lot of other functions that get affected by Agile. I've seen, for example, business analysts and product managers who have been not really more than, unfortunately, order takers. A very strategic customer needs X or this very important part of the business wants Y.

If they've been used to that being their role and, suddenly if they want to be a good product owner, if that's a logical shift for them, it's not that role. It's much more figuring out an interesting puzzle about technology, value, and the patterns of technology adoption that someone in that job might not necessarily enjoy.

It's not that managers are unique and just necessarily uncovering some small percentage of people who don't enjoy the new role all that much or may not be well suited for it, but that's always going to be the case regardless.

Jim: I wanted to ask this question, which follows onto that. I'm assuming that the manager is still responsible for performance management and that's not something that goes away, or at least there is somebody that is responsible for performance management.

How does that look in this new Lean‑Agile space? What things are they doing? If you're trying to build a software‑organized Agile team, how do you check performance in something that's more of a team‑centric approach? What have you seen?

Dr. Grant: Often, people will do away with anything but the team level evaluation. Not every organization is necessarily comfortable with that, but it is a highly legitimate option that really...it's also in some respects fair to the employees to say this, that team performance is not the collection of individual performances. It's how these people mesh together.

You take somebody out of one team, you drop them in another team, and their performance may be utterly different. I remember when I was in grad school, since I brought up my doctorate before, I used to do teaching assistant work, doing the discussion sections that supplemented the lecture class. I would often have like two or three in a row.

I would say exactly the same things ] laughs] at the start of every one of those. Like, "OK, so today we're going to cover what we discussed in the last lecture." One group of people, they were immediately ready to respond, ready to talk, and so forth. The other people, they didn't really click with what I was saying and I had to adjust immediately what my approach was as a TA.

Boy, that's true of individuals in teams. That, on team A, someone might behave very differently than they do on team B. That being said, if it's an organization that is insistent on having some individual evaluations, there are ways to do that that aren't necessarily against the grain of Agile.

For example, the team itself providing some feedback on members, though that could be potentially a little dangerous if that turns into a mutual admiration society where no one's willing to say anything about anybody on the team because of team cohesion reasons. Certainly, looking at what artifacts there are of what the team has been doing.

Is this young developer, for example, over the course of, let's say, the three month evaluation period, has that person been taking on tasks in unfamiliar areas? Has this person really been pigeonholed in one area of the code? Or, has this person broken out and started to get to know some other aspects of what the system does or learned some other technical skills on their own?

Those are things that you can be looking for with, again, not disrespecting the sanctity of the team‑centric approach that is Lean and Agile. When you start getting beyond that, it starts getting a little dangerous. You don't want to necessarily either come up with evaluation measures that require you to get into the business of the team too deeply.

If you're at the point then of getting into what happens within the retrospectives, that's not good. Or, you also don't want to create an evaluation system that then is dysfunctional. For example, one of the things that is a shock for a lot of people, particularly very senior people sometimes about Agile is it's a methodology that really punishes excessive heroism.

If you are one of those people who has been glorying in being the hero of your organization, you work really hard, you were the only person who knows this one critical aspect of the work that needs to be done, and the weight of the world was on your shoulders, but you always triumph. That's not going to work in an Agile team anymore.

You've got to share that load. You've got to spread the knowledge around a bit. If your evaluation system is looking for people to be heroes, then you're really going to damage the Agile team in the process.

Jim: You mentioned retrospections. Does the middle manager get invited into retrospections? Is that a sacred space for the team?

Dr. Grant: It has to be a sacred space to be honest. With any methodology, there are exceptions, but I, personally, err on the side of, "Don't ever let the middle manager in." It's not because they're bad people, but the conversation changes. It's not as honest as it needs to be.

It also becomes less likely that people will take on responsibility in some occasions to solve their own problems, which is the whole point of the retrospective is to say, "Here is the set of challenges that we have that we feel we need to address. We could be a lot better off as a team. Our morale could be higher. Our productivity could be higher. We could be better planners. We could deliver more value. Whatever it is that we think is vexing us and we're responsible then for continuous improvement. People aren't going to tell us what to do."

Sure, go outside the retrospective and ask for advice or help. If you need a better automated testing tool, go to your manager and ask for help in securing that or whatever, but in the retrospective, that's the one moment when you need both very honest dialogue as well as the ethos of self‑reliance on the team's part for continuous improvement.

Jim: What's the role of metrics in all this? There's daily operating metrics for team and performance maturity metrics.

Dr. Grant: Yeah, great question. Wow. I'm a very quantitative‑oriented person. When I'm a coach, I'll be eager to get into whatever their ALM tool is and see what's going on. I'll put reports out of it and slice and dice them in different ways, but that's as a coach, not as a manager because what I'm doing is exposing the day‑to‑day functioning of the team. In many respects, that can be harmless.

If it turns into a system of rewards and punishments, that's not necessarily harmless. Here's why.

Obviously, there has to be some management dashboard level information that comes out of the team. Often, that's as good as, "Here's the burn down or here's our velocity or here's something that is a good indicator of the health of the team or the health of the work that we're doing outside of the team."

I always think it's best if the teams start really taking on their own strategy for what metrics they want to use. Metrics not measures, what are the targets that we're trying to hit that we use measures as diagnostics and we don't necessarily know? For example, if we have problems, we keep hitting the end of the sprint and we're way too busy.

Maybe that's the pattern that we're struggling with. It seems like things are going along pretty well. It gets to the end of the sprint and, boom, all of a sudden, we're all here, up late at night. It seems like it's very hard to do that last couple of days of work to finish out the sprint and meet our commitments.

There could be a lot of causes for that. People are going to have hypotheses about it. We're going to go find measures that can tell us, is it something about our planning at the beginning of the spring that we're being too enthusiastic about our own capabilities? Is it something happening at the end that is messing things up, that our definition of done is too vague, and we keep tripping over own feet?

Our initial hypothesis may be completely wrong, but we need to be able to explore that, gather the data, figure out what the problem is, then set some targets for improvement. That's where the team is going to be able to be very nimble in being able to define the hypotheses, test the hypotheses against the metrics that they collect, do work to actually collect the metrics or measures that may not exist right now.

They may have to put some work into collecting measures, for example, of maybe the problem is our stories are too big. What's a pattern in our breaking down of stories that we need to change somehow?

Middle managers will have theories. Certainly, an outsider's perspective can be helpful, but, again, you don't want those to turn immediately into metrics. That can happen in a very subtle way sometimes. That can be where the manager may be "Suggesting something" and that's not the understanding that the team takes away that is was a mere suggestion.

Like, "You really should be getting your bug trending curves to look this particular way. That's what you really maybe need to think about." Well, of course, that's not necessarily a neutral suggestion. The manager could be completely wrong. The manager could be right.

This is an art, not a science. The manager has a lot of experience potentially to bring to bear on this. The manager may have seen these patterns develop before, but it could be that person is completely wrong about what they're seeing. 90 percent of the time, they're right, but that 10 percent, when they start leaning on the team to do something, could be actually very counterproductive.

Jim: When you've got Agile teams like that, does that dynamic of power between management and the team change?

Dr. Grant: Oh, absolutely. Yeah. It's like the difference in political science between hard power and soft power. For those people who are not familiar with those concepts, hard power is when we talk about international [inaudible 31:03] . We say, "Who are the big players in the international system?"

It's the people who have all the nuclear weapons and air craft carriers, soldiers in uniform. They have a huge industrial base. There are these ways that they can exercise their will through the direct application, often in a very compulsory way to compel people to behave in particular ways.

Soft power is various lever the people have to pull with other countries. Their sources of influence they may have that are way out of proportion to how many tanks the country has. You can get situations where a smaller country, but nonetheless vital in some way, might actually have more influence over its big power ally than the big power ally has over the little country.

What managers have to be looking for is not a loss of power per se, but a different kind of power. It really influenced that. Does the team come to you for advice? Does the team trust you that when there's a problem, that they're going to be open with you about it?

One organization I work with a lot, one of their chief concerns, for example, was, "What happens if there are low performers on the team?" Our answer was initially, "Well, let the team be the front line of defense. Let them try to deal with it first before anybody outside the team jumps in and does anything."

It became clear in the discussion that it was a lot of trust sometimes between team members and managers, sadly. Part of the conversation, the painful part was saying, "Well, maybe the team doesn't, if they get out of their depth and try to deal with this lower performer, maybe they don't come to the manager for help. Maybe they do something else."

Building up a reservoir of trust and authority is crucially important. That can be done for some of the mechanisms I was talking about, such as looking ahead for the team on what could be affecting them or what could be hurting them, or what could be helping them technology‑wise or whatever, being a sage advisor.

Those are things that managers can do, so that when they need to influence the team a bit. There are those moments. Teams are not perfect self‑managers. I don't want to give the impression that that's the case. A number of occasions, I've seen very dysfunctional teams that benefited from a gentle, authoritative managerial intervention.

That required, again, a certain amount of trust, authority, and influence that doesn't come automatically just because you have a manager as title.

Jim: That makes a lot of sense. We've had several questions that have to do with coaching middle management. Obviously, that's something that we do at Net Objectives. It might be interesting to explore this a little bit. For instance, Patrick asked a question, management can motivate their teams by using both carrots and sticks.

As a coach, somebody has come alongside management. It seems like he's only got carrots, that's a moral situation, which is what kind of what you've been talking about with middle management's use of soft power anyways. There's not a whole lot of stick in Lean‑Agile.

I'm just curious, especially for those of us that are coaching, people need middle managers to become more effective in a Lean‑Agile space. What advice would you offer to a coach [inaudible 35:35] ? What works in helping middle management become more effective in the space?

Dr. Grant: First of all, asking them, "Do I want this role? Is this for me? Is this something I want to pursue?" If not, let's be honest. There's been any number of other options to pursue. In a lot of it is also difficult because of the lack of hands‑on day‑to‑day experience to the intensity that an Agile team has.

The Agile team is everyday doing a standup, everyday going back to the backlog and adjusting things, everyday doing things in order to pass tasks back and forth among team members. They are not the same kind of, for a manager on the outside, those works of day‑to‑day lessens.

You kindly mentioned my deep fondness for serious games at the beginning. This is where these kinds of exercises can do a lot of good. Let me talk about some of the different kinds of games and where they fit with middle managers.

First of all, there are the games that are about a certain principle that the teams may be living but the manager hasn't had the same experience seeing an action before. Principles are invisible things. It does take a little bit of effort to try to read into experience, what's actually driving behavior in a good or bad direction.

For example, I'm going to be next week at the Agile 2016 Conference. I'm going to be giving a talk on Agile games. One of the exercises we're going to do is the self‑organization game where you just put people up. You have one group of people say, "OK, everybody here, you need to line up in alphabetical order by last name, but you can't move until the manager tells you to."

There's one person as the manager. The other team, "OK, everybody, you have the same outcome that you're trying to do, but everybody, go ahead and do whatever you want. There's no manager telling you what to do."

Of course, Team two, the one that doesn't have a manager directing everybody, does it way faster. It's a task that the manager doesn't need to be involved in. You may see sometimes with that or other kinds of exercises, that let go on with a lot of managers. Just a little surrogate experience you get from an exercise like that can be helpful.

There are other games that are about simulating possible outcomes. A manager might not understand the importance of something just from the vantage point of that person's desk. For example, what is the effect of technical debt on a team? Is that a practice that the Agile team takes on a certain flinty, unforgiving attitude towards technical debt?

You can play a short game in which you simulate what a team might do to address technical debt and what are payoffs of that.

These are long‑term payoffs. You have to then accept that you're going to be investing some of your time that you might be doing implementing stories on improving your ability to prevent toward reduced technical debt, but there's a payoff in getting the manager to see, "Oh, OK. If I'm not flying top cover for that team and helping them make these investments, I'm not doing my job as a manager."

Certainly, there are also role‑playing exercises that you can put managers through as well. These are really good ways to fill in the experience through the medium of that game, whatever it is, simulation or a quickie little innovation game like an exercise or something like that that might drive home the point.

Thank you all for listening to us talk here, but sometimes words are not enough. Often, that's what tells people over into better understanding the rules of being a manager are these surrogate experiences.

Jim: That seems like a really valuable skill, by this coaching, to know more about serious games. Are the resources you had point them to to learn more, how would a coach begin to add that to their tool kit?

Dr. Grant: Certainly the big companion of the Agile games is the TastyCupcakes website, which is just about Agile games. If you just want to look at the huge Amazon‑style catalog [laughs] of game options that you have, that's where I would start. The site doesn't explain necessarily the reasons why you do one kind of game versus another kind of game.

I started a site about that called seriousgamesatwork.org that explains the different kinds of games, like when do you use one these lightweight innovation games versus something that's a little more like a board game? There are more rules involved and actually points that you score possibly.

It's a different kind of game. If you want that sort of guidance, I would go there. Also, I'm going to mention the [inaudible 41:47] Innovation Games as an online platform if you ever want to use games online. That's an option as well. They do there a couple of different kinds of games that they've developed and created an online platform for.

If you just want to be simple and figure out what kind of games options that you have, if somebody needs to understand Lean a bit better, a game of Kanban Pizza, the Dot Game, or something like that is going to be helpful. Think about the other two resources I mentioned. I also mentioned we use games as rebuilding our own practice in teaching Lean‑Agile principles.

Jim: I'm curious about the role of Agile frameworks, if we could spend just a few minutes talking about that.

Dr. Grant: Sure.

Jim: There are these frameworks like SAFe, OSS, or DD, Leanban. There's a number of Agile frameworks out there. The benefit of them is they help you know what to do. The danger of them is they tell you what to do in general. The general frameworks, they don't always apply this specific context.

I'm wondering what your thoughts are about how they help with the role for middle managers, what are the joys and concerns about using them, and what you're thinking about Agile framework as it pertains to the role of middle management.

Dr. Grant: The inevitable frameworks question. [laughs]

Jim: Got to give that. You know it's coming.

Dr. Grant: I'll start first by saying that managers have the vantage point from which to look at the value stream. That's one of the distinct benefits of being a manager, not being in the hurly‑burley of the team is you could look at the bigger picture.

You can do value stream mapping. You can do see the [inaudible 44:05] . You can do lots of things in order to get a picture of how well the flow of value is working in that value stream. When the time comes to consider which of these frameworks to implement, whether they are implementing at all, that's going to be a valuable perspective.

When the decision‑making process begins about, say, do we do SAFe? Do we do something else? Then, you can say, "Well, all right. What's the net benefit of this? Are we helping people improve the operation of the value stream, either the speed, the reliability, or the amount of value that delivers, very biased words towards Lean thinking on this area? Is one of those frameworks going to help us?"

That's where I think Lean is critical as a yardstick for making these kinds of larger framework choices. That's something that a manager can certainly help with. The manager is also in a position once the decision gets made in order to adopt that to their organization.

One of the great truce about Agile is everybody does it their own way. As long as you're living up to whatever core Agile is about at the team level, that's good. If Team A does it a little bit differently than Team B, that's fine.

If Team A has a, for example, a particular style of doing retrospectives that another team doesn't, who cares as long as their doing retrospectives and the team is continuously improving. There are variances among teams that already exist that shape the adoption of Agile as a team‑level methodology.

If you look above the level of the team, look at the diversity in organizations at that scale. You take a manufacturing company's IT Department and you compare it to another manufacturing company's IT Department. Those differences are going to be fairly significant.

If you're doing Leanban, SAFe, LeSS, you name it, in those organizations, there is somebody in the organization who's going to have to be able to figure out how to fit that approach into organization. A, in a way that wouldn't work in organization. B, that's a good rule for managers as well. You're going to be adopting it overtime.

There will be ongoing changes that will occur, learning processes that have to happen. It's not a one‑time, "Hey, we deployed this framework, and we're done." There has to be some executive function that operates in the collective organization's brand that then learns and adopts. That's also where managers can be very helpful.

The dangers, as you said, was if somebody is nervous about not just Lean and Agile, but now this bigger picture of, say, for whatever then they're going to sometimes seize on the very doctrinaire way you could read some of these frameworks. This is exactly the way you have to do this, "This is my job in this organization, and don't budge me from that particular role."

That's obviously fairly destructive. It does happen. This is a process of putting a fair amount of stress on managers to figure out what sort of manager they want to be, what the roles in the organization, how adaptive they're willing to be, and just something to be on the lookout for.

Jim: We have one question. It's maybe a little bit related to this. Maybe this is going to be our last question for today. I wonder if you want to spend a few minutes talking about how middle management must interact once you got both Waterfall and Agile going on in the same organization, that sort of complication that comes in that. What's your experience of that?

Dr. Grant: The mundane answer is there's obviously some amount of syncopation, coordination that has to occur that the managers can help with. That might be beyond the team's devices to do that.

If you have, let's say, a team building in mobile application that's talking to some back end legacy system, it's very difficult for the team on its own to be able to get from the back end team the AVIs that it needs on a regular basis or other thing that it needs, the slower pace that that team is used to working on or long‑pole definitions of work items that they've even use for building, that's obviously where a manager can step in.

A far more important job, though, for a manger in this situation is to be a vector for the Agile mindset, even if the other teams are not doing Agile necessarily themselves, but to say things like, "It's OK to experiment," or, "There's a lot of uncertainty in software development, and experiments are there for necessary. We don't expect every experiment to work. The plan that we have today is something that is only a guide to action at this moment. We're not going to completely throw at everything about the plan like what the plan is trying to achieve. If we find out there's a better direction to go in to reach our destination, let's not get freaked out over that."

The really important thing is the human element of software development. As a former colleague of mine, Jeffrey Hammond, said, it's not an algorithmic process. It's not where you have an instant right answer that you can apply to every situation. There's a lot of creativity. It's a very heuristic process.

That's going to mean that people are going to have to not fall back immediately on some procedure or some particular sanctioned approach that may not apply on this particular area. It's just problem‑solving exercise.

Those are the messages that have to get across and I think that's true even if Agile had never existed, that somebody needed to talk reality to power [laughs] , truth to power but it's a hard reality about software development and how it actually works and Agile illustrates, I think that it's necessary both for Agile to work and for a software to develop and in general to succeed by cleaving to these particular principles.

Everyone benefits but it also reduces a lot of the friction between teams. They could say, "Well, If the Agile team doesn't have exactly the same kind of test plan that you're used to on the Waterfall organization, there are good reasons for that and don't treat them like they're cowboys or idiots or whatever other unflattering stereotype you want to apply to them, but that's just part of doing software development.

"If that works better than embrace that particular different approach but as long as the outcomes are good, then the team should be able to collaborate with one another."

That's an educational function a manager will have to be doing but they can be very good at doing and that's critical in getting waterfall management teams to work together better.

[background music]

Jim: I want to thank you, Tom. It's been an interesting conversation and I hope you all have found it interesting as well. That wraps up the show for this time. Thanks for listening and thanks for being involved.

We welcome your feedback on what you've heard and your suggestions for future topics. You can send a note to Al Shalloway at now alshall@netobjectives.com, or to me Jim Trott at Jim.Trott@netobjectives.com and we'll talk again.

Transcription by CastingWords

73 episodes available. A new episode about every 71 days .