Skip to content

BigVisible Solutions :: An Agile Company
Syndicate content
Guiding the Agile Enterprise
Updated: 55 min 33 sec ago

4 Patterns for Handling Interruptions

Thu, 05/25/2017 - 17:00


Interruptions are a part of life, even on good Agile teams. You’ve made plans, now they have to change. Again. So, until the sources of interruptions can be plugged indefinitely (which will take some time and work), the team needs a way to handle interruptions while also delivering predictability against the backlog of new features. The goal is maintain predictability in a rapidly changing work environment where interruptions are planned for and can therefore be addressed in a timely manner.

Here are four simple ways to handle interruptions that can actually make a team more resilient to change (with hand-drawn visuals by yours truly).

Pattern 1: Roll With It


We know support and fix requests come in sporadically. Such work comes in every month or two so a special policy for handling it is not needed.


Plan as if there will not be support and fix work. When some comes in, adjust the plan to accommodate it. Drop one or two planned pieces of work to handle the speed bump of fix work, so you can limit your work in progress (WIP) and focus on getting work done. Tell stakeholders immediately what is happening and why. Remind them that, to accommodate this unplanned-for work, you had to remove lesser-priority stories from the Sprint.


Since the interruptions are not that often, we don’t have to change our work process. We simply have to be transparent about the effects of interruptions when they do happen.

Pattern 2: Budget Capacity


The team regularly has support, fix or other interruptive work. It’s expected but the team doesn’t know enough to make a specific plan.


Make an assessment, maybe just a feel or guess based on shared history of how much time is spent each week on such work. Calculate the percent of time spent on such work. Budget that percent of Story Point Velocity (or just hours) for such work. New work is planned for the remaining capacity.


We have a time set aside for the unknown work we know is coming. That way the new work plans can be executed. And, if no interruptions happen, we can do even more than planned!

Pattern 3: Firefighters


The team consistently has “non-new” work to do. Every Sprint or week, without fail, there are enhancements, fixes or service requests that are going to come in.


One or two people on the team each Sprint (or couple of weeks) are designated as “firefighters.” They do not do new work unless there are no interruption requests. The current plan for the next couple of weeks takes into account that these two people are NOT working on new stuff. The firefighter positions rotate every two weeks so the same two people are not stuck doing the fix and support work all the time.


The plan can be met by the people working on the new stories. The firefighters are dedicated to handling interruptions and get to learn new areas of the product. And if there are no interruptions, the firefighters can help get more new work done than planned!

Pattern 4: Special Teams Conditions

Some gnarly problems come in from time to time. These are often so big, so unknown that they are a project all on its own that can threaten to steal everyone away from new work.


Find a spot in your plan where you can stop to re-plan. Finish out the week or two weeks and then re-plan. Peel off a few people who are experts in the problem area and know the technology well. These few people form a Special Team who are 100% dedicated to the big problem. The rest of the team can make plans without them, proceeding with new work.


The current plan for a week or two is not overly disrupted. Then the problem will have the full focus of dedicated people. New work proceeds at a slower pace until the Special Team members come back, but at least it proceeds.

While you’re here, check out my 3 patterns for scheduling Scrum team planning meetings! Also, how do you and your team deal with interruptions? Let me know in the comments!


Subscribe to Agile Eats

Agile Eats is our semi-monthly e-blast chock full of tips and tricks too good not to share. Subscribe now!

The post 4 Patterns for Handling Interruptions appeared first on SolutionsIQ.

Categories: Companies

Adult Cognitive Development and the Agile Mindset

Thu, 05/18/2017 - 17:00

The science of Adult Cognitive Development has been around for quite some time, but William Rowden maps that science to the Agile Mindset and an Agile Transformation. His insights are fascinating and help him identify behaviors that are not aligned with an Agile mindset, and how to help his clients move in the correct development direction. William is speaking not from theory, but from practical application within clients in the US, China and Mexico.


Howard Sublett:  William is a senior Agile consultant at SolutionsIQ with expertise leading enterprise Agile adoptions for clients in the US, China, and Mexico. He is a skilled communicator and collaborator who not only can program in over 20 computer languages, but is fluent in English, Spanish, and is rapidly learning Mandarin.

In this episode, William and I discuss Agile cognitive development and the Agile mindset. In his work with clients, he’s mapping adult cognitive development within an Agile transformation. He shares his understanding of how a client’s professional development model needs to aligned and focused on the transformation. This work’s helped him to recognize behaviors that don’t match the expectation of an Agile mindset, and how to help them move in the developmental direction.

Again, thank you for joining us, and now, on to the conversion.

William, thank you so much for spending some time with me today. This is actually the very first time of carrying my gear, that I actually get to sit down in SIQ headquarters and actually record here, instead of in some pub somewhere or in wherever it is. Thanks for coming back from the client and sitting down with me a little bit.

William Rowden: Sure.

HS: Yup, so, you’ve got a monster topic that you and I have kind of been wrestling around — how to actually frame this into some way that makes sense for maybe a listener, and we kind of came up with this idea that what you’re trying to bring to the table is of the Agile mindset and what we could learn from adult cognitive development.

WR: Right.

HS: So, that is something I know very, very little about. I don’t know about the listeners in here, but that’s a huge topic.

WR: Right.

HS: So, we talk a lot about Agile mindset, but you’re bringing kind of the science of this cognitive development to it. Can you break it down for us just a little bit?

WR: Sure. Exactly. I did Agile development for about 10 years before I got into sort of helping people do Agile development. When we started helping people do Agile development, we developed a sort of intuitive sense about how is it that you help people change. It’s an important quality for a coach to support people through change.

But about three years ago, I started looking for a more formal explanation for the things that we know intuitively about an Agile transformation. We know when we go into a client and we present Agile to them, that we’re not just asking them to learn a new set of facts or a new way of doing things. We’re asking them to learn a new mindset, and we even put up slides saying, “A new mindset is needed.” But what really does that mean if we’re talking about helping people transform their mindset? I went looking for science that would help us understand what that really looks like and how we can help that happen.

HS: That’s huge because I know that most of us kind of look and go, “Yeah, he’s got it, and he doesn’t.” Or we can kind of see it and they get it and it’s something by the behavior that we see, but sometimes it’s not. It’s how they approach different problems and stuff.

WR: Right. Right.

HS: So you are bringing to the table several steps here, and we’ve got this wonderful thing that you’ve got on the wall we’re trying to look at, and we’ll try to put a picture of it in the cliff notes of what we’re doing of all these development stages. Can you kind of walk us through where people start at in cognitive development and where they go to?

WR: Sure. First, I want to comment a little bit about what you said about people get it or they don’t, and this is actually the differentiator between different stages of cognitive development. It’s how you make meaning. It’s how you make sense of your world. It’s how you interpret what’s happening to you. The people we see that “get it” are ones that are in a stage where they’re making meaning in a way that’s compatible with what we’re teaching with Agile, and if they’re not, then maybe there’s a little bit of growth that’s needed. This is based on adult developmental psychology that’s just an extension of childhood developmental psychology.

The famous childhood developmental psychologist is Piaget. If you go out on YouTube and you Google “Piaget experiments,” there’s an entertaining set of videos of children at various ages being asked to solve simple problems. You can see in childhood a breakpoint where they start to be able to see the world in a different way and answer questions and solve different kinds of problems. Until recently, it was thought that that just sort of ended, like when you became physiologically an adult, that that sort of development was done.

One of the famous adult developmental psychologists used to go to conferences, and his brain science colleagues at Harvard would make fun of him, so like, “Whatever it is you think you discovered in adult development, we know that the brain doesn’t change. It’s wired by the time you become an adult.” But in the last couple of decades, we’ve discovered that’s not true. Your brain continues to change in its structure over the course of your life. The childhood development stages actually continue into adulthood and so they have a lot to tell us about helping people transform the way they think.


HS: So, there’s probably two personas here that you’re probably talking to about this. From a coach’s perspective, they’re trying to identify those stages in the clients that they’re working with, and then from the individuals, the leaders, managers within organizations— they probably want to self-identify with the stages in which you’re talking about, right?

WR: Absolutely. If you’re a coach, you want to support people who change. If you’re a manager, you want to continue your own professional development because Agile leadership requires a little more than some of more traditional leadership of you personally and professionally.

Also, if you’re an Agile manager, you want to support your people as they go through the development that’s necessary to adopt an Agile way of working in an Agile mindset.

HS: You’ve got some stages for us here, and I will let you walk us through a little bit of it.

WR: Sure. So from a developmental perspective, there’s about three stages of childhood which is not really that important — just to understand that adulthood is a continuation, and then adulthood at this time, three stages identified as well, and so they would be stage … You’d start the childhood at zero and so we’re talking about stage three, four, and five for an adult.

Most adults spend most of their life climbing from three to four. You’re developing different ways of thinking and more complex ways of looking at the world. The development psychologist that I rely on most for adult psychology is Robert Kegan, and he calls these three stages, the three, four, and five, he calls them the socialized mind, the self-authoring mind, and the self-transforming mind. The self-transforming mind is typically a very small percentage of the population, so we’re really talking about the socialized mind and the self-authoring mind.

Now the interesting thing that caught my attention as an Agile coach is if you look at the expectations that we have of people going through an Agile transformation, a significant number of the expectations are self-authoring mind expectations. In order to do them well, you need to actually progress developmentally in some cases in order to achieve what you want to achieve.

So I have some examples of each of those on the chart if you want to talk about it.

HS: I was going to say, is there a way to describe the stage of a socialized mind, the stage three? What does that kind of look like?

WR: Sure. So, your socialized mind person, this is the team player. This is the person who maybe doesn’t seek out leadership, but is good in terms of a follower, does that well, seeks direction for their work because that’s really where they are.

If you read Stephen R. Covey’s “7 Habits of Highly Effective People” when that came out decades ago, he talked about “dependent, independent, interdependent.” This is the dependent stage. This is where you’re saying, “Tell me what to do.” Not always that extreme, but we actually run into developers that are basically “I would prefer that you give me a detailed specification of what I’m supposed to develop, and then I’ll just do that because that’s the kind of work that I want.” That’s the socialized mind.

At that stage, a socialized mind, you’re well-aware of shared agreements, shared expectations, so you’re actually able to work really well on a team, so when an Agile coach comes in and says, “We need to work on team. We need have a work agreement. We need to agree on how we’re going to do all this” — you’re right there and you’re able to do that just fine.

HS: Right. Okay. It sounds a lot — and I’m maybe taking this down the wrong rabbit hole here — but when you say that it sounds like kind of the beginning stage when I think about team dynamics into working on a Scrum team, for instance, it sounds a little bit like understanding the roles artifacts and ceremonies of working in a team and doing them well would fit within that stage, but that’s about a group, not an individual, but —

WR: Yeah, well, actually, each of these stages have a corresponding structure in an organization. There’s actually a strong tie between the mindsets of the participants in the organization and the level that the organization is at. If you were to read Laloux’s “Reinventing Organizations” where he talks about different kinds of organizations and classifies them with colors, this is the same set of stages, because one kind of mind is comfortable in a certain kind of organization, and so they’re actually very closely related.

HS: Cool. So now moving from a socialized mind, they would move to stage four, which they call a self-authoring mind?

WR: Self-authoring mind, right.

HS: Okay.

WR: This is the point where you’re more comfortable. This is what Covey would call “independent.” This is the point where you’re more comfortable driving the agenda. You’re beginning to learn to be a leader. You have your own compass and frame of reference that you use to evaluate what comes to you from the world, and you’re seeking out how to solve problems like, I’ve got a bunch of — I noticed this problem, I’m going to own that problem. I’m going to solve it. This is the kind of mind that a lot of Agile training expects or intends to encourage.

As an example, one of the things that we talk about is seeing the whole. This idea that it’s no longer acceptable that I do my work, and I hand it off to you, and I don’t care where it goes from there because I did my piece, and if your piece is late, “What’s your problem?” Right? That’s no longer acceptable. We need to look at how are we, together, delivering value to our Product Owner or our client. So we need to have an outside in sort of look. We need to be able to see the whole and think about a flow. That —

HS: So a little bit of a systems view of things.

WR: Yes. Exactly. Exactly. Systems view is a self-authoring mind kind of stage in order to do that. So when you’re asking people to do that, that’s the level of expectation that you’re asking [of] them.

Another expectation that’s at the self-authoring mind level is this idea of being self-initiating or self-correcting. So, I worked with an Agile team at a telecom, and they had stopped doing retrospectives, and I asked them, “Why aren’t you doing retrospectives anymore?” And they said, “Well, nothing ever happened.” I said, “Really? Tell me more about this because —”

HS: It’s not a great retrospective but …

WR: Right. Well, so they didn’t feel that great of an ownership over the solving of their own problems. They felt like they would identify the problems and someone else somewhere in the organization would solve the problems for them. That’s an external sort of an evaluation, that’s not an internal evaluation, and that’s actually closely related to the next thing that I would call, the next expectation, which is “self-ownership.”

If you just since I keep mentioning Covey, I’ll go back to his comment of stimulus and response, if you think about his idea that something happens to me, but I’m in control of my response, I can respond or not. The gap between stimulus and response is mine — that’s sort of a self-ownership. And that’s what we would want an Agile team to get to. We would want to say whatever organizational environment you’re in, whatever impediments you’re experiencing, we expect you to identify things in your own process that you can improve and so own that. If you can’t control it, maybe you can still influence it, so what can you do to influence the change around you, that kind of ownership. And that was different with this particular team that basically said, “Well, I found the problem. Somebody else should solve it,” and so that’s a different stage of development.

HS: And then, I see mastery up here.

WR: Yeah, so mastery is a similar thing. So the socialized mind says tell me what the standards are, tell me how to do my practice. I’ll follow them. I’ll do them well, and I’m going to essentially take an apprentice viewpoint toward my profession, right?

When we talk about technical mastery, what we’re thinking of is “I’ve learned this well enough to distinguish when to apply what standard to figure out what the best thing is in each case.” And so this is actually somewhat related to something else we use in training, the idea of Shu Ha Ri, right? So at the Shu level, you’re saying just give me the rules. I’ll learn to follow the rules. But by the time you’re at the Ri level, you’re making the rules, right? And in between is the Ha where you start playing around with the —

HS: The edges of the —

WR: …options.

HS: …roles, yeah.

WR: Exactly. Exactly. So when we’re talking about mastery, this idea that you should research a Ri stage and have some idea when you apply what rules — again that’s a self-authoring mind expectation that is difficult to do at the socialized mind stage.

HS: The next level that you’ve got is, so self-transforming mind?

WR: Right.

HS: Is anybody there? I mean, is this something that we see a lot of?

WR: Not a lot. So, Robert Kegan has done research into adult development and who’s at what stage, and so he did one study of about 500 people longitudinally and another study of over 300 longitudinally and found like less than 1% at this stage.

HS: Wow.

WR: So, it’s not frequent in the population or in … It often shows up in leaders, right? Because they’ve been able to see that.

The one expectation that I put up there is around collectively creating a vision. I put in the self-authoring mind, this idea of instituting a vision. So if you think of a leader saying, “Here’s our vision. Here’s the direction we want to go. Let’s go.” That’s a self-authoring approach, right? There is a different kind of a leader that says, “Hey, here’s the general direction I want to go, but let’s create it together. Let’s figure out what that looks like when we all put our desires and hopes into this and create something together.” That’s a more difficult thing to do.

It’s interesting here because there is something here that can be confusing. Covey talks about dependent, independent, interdependent as these sorts of stages. So first, I’m reliant on others, then I learn to be self-reliant, but then later I learn that okay, I’m self-reliant, but actually there’s a lot of value and synergy when I interact with other people. That interdependence can look like dependence. So there’s what I would call a “pre/trans fallacy”: you have to be careful to distinguish between the levels what’s really going on.

At one level, where I’d say, “Give me the vision.” Well, that’s a socialized mind approach. To graduate from that, maybe I would say, “This is the vision. Let me enlist you in it.” But at some level beyond that, you say, “Here’s the general shape of the vision, but I really want all of us together to work on this. How can we make this vision truly shared?” That’s a more difficult level of leadership.

HS: This seems really hard for people to self-assess in themselves, especially in the leadership space because I’ve witness people let clients that feel like that they’re that kind of leader, that they’re actually the kind that you would describe as a self-transforming mind: they do the action without actually doing the heart part of it. Do you see that? And how do people actually know themselves where they are?

WR: This is actually what kept me away from this field for years. Nearly a decade ago, we started talking about maturity models, and we had a big debate, and the group I was with at the time just threw out the idea of maturity models, and for years, I kept with that sort of bias because every time I saw a maturity model, I asked two questions about it. I said, 1) how does this guy who wrote this maturity actually know, like where’s his data? What’s his theory? And then 2) did he just write a model that places him at the peak? Right?

HS: Yeah. Yeah.

WR: Right?

HS: Yeah. I get it.

WR: And so most of those models out there look to me like somebody said, “Well this is how I became Agile, and obviously, I’m much more Agile than everyone else, so this is the end of the road and how I got here is how everybody got here.” So for the longest time, I looked at all maturity models with a skepticism based on “Is that really the way it happened?” It took me actually a while to be convinced that there was some reality behind Robert Kegan’s work, but he has a set of data and a clear theory that explains the transitions between it, so I’ve become convinced that there is really something there.

But, as you note, it’s really difficult to self-assess. This sort of thing is ripe for a lack of self-awareness, and for someone at one level just not knowing what they don’t know and, as a consequence, rating themselves higher. So really, the way to get this kind of information is through external feedback.

There’s actually an instrument called the “subject-object interview” that allows you to do this, but simply going to the people around you and asking them questions like “What do I really need to get better at? How can I improve in a way that would help our overall direction go better?” Those kinds of questions can give you the kind of information you need to assess this sort of thing, but it wouldn’t be something that I would sit down and try to figure out for myself.

HS: I know from my own experience, and I’ve seen it in others, is that the more I know about what I’m supposed to do or the more I know what about what I’m supposed to know, the worse that I will rate myself because now I’m aware of the gap that I have. Before, when I didn’t know that, I thought I was really good at something, and once you really get deep into it, you go, “Wow. I’m a failure,” so I rate myself — the self-assessment changes, but I’m actually growing, and I’m getting better, but my rating gets lower. There’s a saying for that, and I forgot the word now.

WR: That’s actually known is called the “Dunning-Kruger effect.”

HS: Dunning-Kruger effect, yeah.

WR: Because at a certain point, you don’t know what you don’t know, and so you rate yourself, you think, “Well, I know about 90% of what needs to be known in this area.” Actually, you just know 90% of what you’re not ignorant of. But then on the other hand, if you’re actually quite competent, you tend to assume that people around you are equally competent, so you’re probably about average. People tend to underrate or overrate themselves depending on which side of the average they are. It is an area that’s ripe for misunderstanding.

HS: So, you’ve been consulting a long time, and you said it’s taken you awhile to come to this and realize the value in this. How do you apply it? I mean, you’re working at clients. How does this resonate with them? Do you lay out to potential leaders and say, “Here are the five stages. You’re at number two. You suck.” As a consultant, how do you work with this and this knowledge now?

WR: Right. I don’t try to put people in any sort of stage.

HS: Thank you.

WR: Yes. And in fact, if you go back to Piaget and the childhood development, there’s a phenomenon he calls “horizontal décalage,” which means you reach a certain stage, but in one area of your life, and then you spend some period of time expanding your understanding of that across more areas of your life. So I don’t look at a whole person in terms of a stage. I might look at a particular situation in terms of what stage it’s reflecting.

We actually see this in Agile. You’ll get somebody that didn’t know anything about Agile. They’ll learn Agile, and then they think, “Oh, this is great,” and they start doing Agile in their software development. Then they say, “I bet I could apply this at home.” Then they teach their kids to use a Kanban so that they remember to brush their teeth and do their homework. Then they plan their wedding using a Scrum approach or whatever, and so they start applying it all across their lives.

So I really look situation to situation and try to assess what’s happening. Here’s an example of that: so I’m working with a client where there’s a significant amount of challenge in the organization around understanding what other parts of the organization want or are contributing or really mean, and so they’re really struggling to look at things from other points of view. That’s a very sort of stage three, “my tribe, I understand my people, I don’t understand those people” — and you can hear it in their language, the “us and them” — all that sort of thing happens, right?

In that particular case where I recognize that, I say to myself, well I could attempt to accommodate the stage three, but really, to do Agile well, you have to be able to put your mind in the mind of the customer, and put your mind in the mind of other groups, and so we need to stretch. A clear example of that is user stories. User stories — if you come to a group and user stories are written, “As a database system, I want blah, blah, blah,” right. Then you know, don’t really understand user stories —

HS: You haven’t gotten there.

WR: It should be in the voice of the user. So you need to see things from the voice of the customer. In that situation then, I challenge the people I’m talking to to look at things from the other point of view, because I know that doing Agile well is going to require them to do that. They’ll tell me, “Well, so-and-so thinks this thing,” and they’ll say something that no one would ever say because it portrays them in a bad light. And I will say, “Interesting. What would they say they mean by that?” and attempt to challenge to them to think about things from an outside point of view, as an example.

It’s not sort of classifying people by stage, but sort of recognizing behaviors that don’t match the expectation of an Agile mindset and attempting to help that person move in the developmental direction by exposing them to feedback or outside information, just like I was saying that you need outside information in order to make that transformation.

HS: So it seems like the human development is complex. There’s a lot of complexities in that —

WR: Absolutely.

HS: And there’s complexities in the human mind, and there seems like there’s complexity in Agile itself. Is there an alignment and a reason why that these things are that way?

WR: Yeah, so actually one way of looking at what we’ve been talking about is complexity of meaning making, like how complex your view of the world is.

In childhood, you view the world as fairly straight forward, it’s fairly simple. If you’ve got an “us and them” and sort of tribal viewpoint, you’ve got the world neatly divided. The modern world expects us to have a more complex view where we tolerate a wide variety of different ways of looking at things, and so we’re constantly increasing in complexity of mind.

This is actually part of what Agile was designed to address. We used to think that, well, we’re just going to develop software like we developed engineering. We just do our plan, then we do our design, and then we don’t have very many defects, and we’re done. It never worked out that way because it’s not that straight forward.

I used to be in civil engineering, and I can tell you that the human dimension of software and the interaction between humans and systems is far more complex, and so Agile is a way of addressing the complexity in software development and also the complexity in our modern economy, the fact that we need to figure out how to get to market fast and figure out what the customer really wants. This developmental set of stages is increasing the complexity of your thinking in the same way that Agile is increasing your capability of dealing with the complexity of development or the software development or the complexity of the market.


HS: Wow.

WR: Yeah. No, it’s been exciting for me to see these connections, although I am challenged to explain them in ways that seems pragmatic, like “What do I do next?” sort of thing.

HS: I was going to say, you seem to make, you draw really clear lines between, and they’re ambiguous lines sometimes, I realize — but you seem to see those connections. I’m thinking about the listeners that actually can’t seem to visual those connections between them and how to help explain those in a way that resonates with them. It’s deep stuff, man.

WR: Sure. Sure.

HS: It really is.

WR: From the complexity point of view, I think the simple example is if you can make a plan, consult an expert, and then… you know, consult an expert, make a plan, and then execute it, and things work? Then you’re not really dealing with a very complex situation, and we try to treat software that way. What always happened was you would show the software to somebody, and they would say, “You know, I know that’s what I said, and your requirements are probably right, but now that I see it, it’s totally not what I want.” And that’s just because that sort of approach of “we’re going to do some analysis and then we’re going to execute based on that” just doesn’t work on this space. It’s a complex space, and so Agile tools are a way to figure out how to deal with that complexity by simplifying it and reducing it, time-boxing it, setting in front of team. What we’re talking about here with developmental stage is how to expand your ability to think about the complexities that an organization or life or development bring your way.

HS: It sounds like that a client or a customer that’s really wanting to get the full benefit of this Agile adoption, this transformation — which isn’t my favorite word, but that’s the word that we use — has to think about these different stages of mindset shifts and those kinds of things. Because this isn’t like a standups, artifacts, retros — those are actions that you take. How do they grow, how do they learn in that area? And how do they know whether they’re actually on the right track or not?

WR: Right. Well, let me talk about transformation just for a second —

HS: Oh, God.

WR: …because, whatever word we use for it, one of the distinctions that I think is important is that there’s sort of this horizontal learning where I learned a new programming language, I learned a new language, I learned a new process, right? We can call that technical change or technical learning. But then there’s this sort of adaptive change, like I learned a new way of viewing the world. I learned a new way of relating with people. I’ve learned to think about things in a different way and see different things. And really, in a lot of organizations, Agile does require that and so you might use the word transformation for that, or you might call it an adaptive change or something like that.

Pragmatically, what that means [is], let’s take the example of a manager, if somebody’s reporting to you and they’ve come to you and they say, “The Product Owner is telling me what to do and why does the Product Owner get to tell me to do?” As a manager, you would say, “Well, that’s because they’re playing the role of the voice of the customer.”

But you need to recognize that the challenge this person is facing is seeing their team from the outside, seeing their team from the point of view of the organization for which the Product Owner is the representative, and so that’s a developmental challenge. How do we help this person see a little differently? What kind of feedback can we give that will help them see the importance of that role in the team.

HS: That sounds like a professional development opportunity.

WR: Yes, absolutely.

HS: How do they tie that together, for transformation even?

WR: Right. Well an experiment that I’m running with one of my clients is to do exactly that: to tie it together. So to work with a set of people and say, “What is it that you need to get better at in order for the transformation to succeed?” Because this is the thing about it. It isn’t just I learned something, and this will be successful. Each person has to change the way they think about their work and other people in order for it to be successful. You can make all the changes you want on paper, you can put people in rooms, and you can draw different org charts, and you can articulate strategic visions, but unless the people learn to relate differently and think differently and talk differently, it’s not going to be successful.

The tie-in there is to say, “Okay, for each person that we’re working with, what is it that they need to develop? What is it they need to work on for this transformation to be successful?” Maybe for one manager, they’re a micromanager, and that doesn’t work well with Agile teams, and so they need help getting themselves out of the micromanagement trap, where I do everything because my reports don’t know to do it, but of course they never learn because I tell them repeatedly how to do it, right? That’s a trap I’ve got myself in.

So maybe that’s the thing each person needs, that particular person. For each person there’s going to be something that’s going to be part of their growing edge that will help the transformation of the organization as a whole.

HS: It’s a professional development of being Agile, professional development plan towards not just learning the mechanics but of actually what is it like to being Agile, and it’s probably changed management over things that they need to start doing and stop doing as well through that. It’s interesting, I never thought about tying those learning objectives to an Agile transformation.

WR: Right.

HS: That’s deep stuff.

WR: It is, right. Yes. Because the organizations reflect the way we think about the world and relate to each other, particularly the leaders, and so when we’re changing an organization, there has to be also for that to actually happen and not just be a plan on paper. There has to be a corresponding change to mindset on the parts of the leaders and the participants.

HS: Wow.

WR: So that’s deep stuff.


For more deep stuff from William, you can email him at And to keep the learning going, don’t forget to subscribe to Agile Amped!

The post Adult Cognitive Development and the Agile Mindset appeared first on SolutionsIQ.

Categories: Companies

At the Intersection of Agile and Change Management

Tue, 05/09/2017 - 17:00

Email Monday, training Tuesday, change Wednesday–that’s how quickly some people think change happens. But organizational change is ultimately a human process, regardless of whether the enterprise is experiencing the change or the individuals that comprise it. The change management industry has been focused on making change more “sticky” and that’s why SolutionsIQ is excited to be participating at Change Management 2017 this year — to further our sharing of knowledge in both directions.

In our Agile Amped podcast, “CIO Tim Creasey at the Intersection of Agile and Change Management,” Tim points out that change management aims to “prepare, equip and support people to be successful in the changes” requested of them, and that process needs to time to take effect. Tim shares his thoughts of how companies who undergo an enterprise-wide change like an Agile transformation fail to invest adequately in the change management aspects. And then, if the company is successful in transforming to Agile, they don’t know how to deal with the pace of change. A clear example of this is the stark difference between the rate of change in customer-facing technologies and internal technologies implemented by a company’s IT department. Tim also shows how a change model like ADKAR can work in a Scrum environment.

Dan Fuller: Hello everyone and thanks again for joining us for another Agile Amped podcast. This is your all-access pass to the latest and greatest Agile content from industry thought leaders at events across the country. We’re here this week at the Gaylord Texan resort in Dallas talking to people at the Change Management conference. So, I’m here today with Tim Creasey. He’s the chief innovation officer from an organization named Prosci. So, thanks for joining us again, Tim.

Tim Creasey: Thanks for having me.

DF: Today we’re going to talk about two topics that we believe are kind of the intersection between Agile and change management. The first topic, which you and I have talked about a little bit already, in our experience a lot of organizations are going through what we call an Agile transformation. So, this is a radical way of transforming the way that they partner with the business to create software. What we have found is that a lot of organizations under-invest in traditional change management practices that have been tried and true in helping organizations deal with large-scale change. What’s been your experience in that so far, Tim?

TC: Yeah, I think there’s an exciting transformation happening in terms of organizations really getting smarter around how they’re bringing about change, and I think Agile along with a number of the other improvement approaches we’re seeing out there are a part of that. Now change management, and we kind of define it — I’ll give you a definition so we have kind of that context. It’s “How do I prepare equip and support people to be successful in the changes that I’m asking them to make?” What I’m finding is that when an organization tries to bring Agile to life, there is the change to Agile — so, “how do we actually move from a waterfall mindset and toolset to a more Agile iterative approach?” And then there’s “how do we manage the people side of change inside of an Agile rollout?” A lot of times we missed that first one. I use the notion of we send an email on Monday for training on Tuesday that we’re going to be an Agile shop on Wednesday. And that’s just not the way to prepare and equip and support people to be effective in this new interactive, iterative sort of approach to bringing change to life. So, I’d absolutely agree that if we don’t make that first move, then all of the rest of the waves become much more challenging because we haven’t primed the organization to be ready to be successful in an Agile environment.

DF: We’ve had similar experiences. We’ve noticed that a lot of organizations think it’s as simple as “Let’s just train everybody in Scrum.” And although that’s an important part of a change management approach for an Agile transformation, we found that we also need to make sure that we’re working with leadership to change leadership behavior, we need to make sure that we’re addressing fundamental reward structures that will encourage behavior, we need to make sure there’s a communication plan that communicates what we’re changing, why we’re changing, and making sure that the organization has a clear vision that the organization is aligned to. And what we’ve also found is that we need to use some tried-and-true change management frameworks and techniques. You know, ADKAR’s one that we often use with our clients. But under-investing in those types of aspects of organization change for an Agile transformation, what we found is it runs the risk of it not being sticky. You know, we get some short-term success but then people revert back to the way they used to do things.

TC: There’s been so many cases of “this too shall pass.” You know, Agile potentially being viewed as the next fad. “If I just wait it out, this will go back to the way we used to do things.” And that happens when we don’t get leaders engaged, when we don’t communicate why, when we don’t connect it to real business outcomes and results. I think you’re right: there’s some good solid change management that will help us set the tone, so that being Agile is more likely to be successful.

DF: Okay, great. So, if we use a little bit better change management practices and actually invest in that, we’re more likely to actually get to the point where we’ve now become an Agile organization. Now we’re at that point that we wanted to get to, where we’re now delivering shorter cycles, creating value quicker and getting that value up to the market or to our end-users faster. Now what?

TC: Yeah, and I think the interesting thing here is, we’d call this Reinforcement at the end of the ADKAR model, it’s phase 3 in our organizational change management process — and it’s because, you know, it is our natural and psychological and physiological tendency to go back to what we used to know how to do. Fascinating research that it takes the brain more glucose to process things in a new way than an old way, which means it literally hurts your brain to do something different. And so, if we are not intentional and thoughtful around those sustainment mechanisms, I think we run the risk of being left with the toolset of Agile without the mindset shift that we need.


DF: Yes.

TC: And that’s, you know, celebrating successes, a job well done, senior leaders saying, “This is the impact we were able to derive because where we ended up.” Metrics and measurement is huge to be able to show feedback into the organization that loop that comes back and says, “This made a difference…”

DF: Yes.

TC: “…when we made this change.” And I don’t think it has to be grandiose. It can very much be a walking down the hall and just saying, “That was awesome when you guys stepped up and went the extra mile so that we could shorten that down to two weeks, because I know it was hard on you.”

DF: Yes.

TC: That goes a long way to help human being stay in that new way of doing things.

DF: Yep. Now, the second area where we’ve observed organizations don’t really think through, in terms of change management when we’re trying to adopt Agile: we’ve now successfully done an Agile transformation and our teams are now delivering a rapid amount of change to the organization or to our end-user customers. What types of change management practices do we need to do differently in order to actually deal with that constant rate of change that we’re now creating?

TC: Yeah, I think this is — and I’ve been doing some work here. Because that first shift was that move to Agile, while the other has moved inside of Agile to the change management approach. So, what we’re working with clients to do right now is to say, let’s take ADKAR as an example: Awareness, Desire, Knowledge, Ability, Reinforcement. That’s our individual change model. There’s project-level and Scrum-level exercises. And so we would say building Awareness and Desire for the need for change, awareness of the need, desire to participate and support — tends to happen at the project level. And that’s really around priming the system. Knowledge and Ability become very focused on each Scrum, and then with a little bit of Reinforcement and then we get Reinforcement back at the end release. So, we’ve taken ADKAR and started to split it out across, you know, up to the project itself and down to the Scrum. We’ve done the same thing with the five change management plans that Prosci uses. So, the communication plan: we’ll have a project level and we’ll have Scrum level. Training plan tends to primarily be a Scrum-level activity. Resistance management tends to go both ways. Sponsorship tends to be a project-level with a little bit of Reinforcement at each Scrum. And then coaching tends to happen across the board. And so, I just think it’s being a little bit more thoughtful about the toolset we have, and saying, “How does it look a little bit different?” And I’ll tend to draw this on a flip chart and say, “What goes to the project level, what goes to the Scrum level? And let’s start to split out the work we’re going to do around change management.”

DF: Ok, well, that’s interesting. I think you and I both have an agreement there that there’s a lot of synergy between what the Agile community needs in terms of change management, and what the change management community can provide in terms of thoughtful solutions for how we can get there.

TC: Well, yeah, absolutely. I think that’s, I mean, this is where success lies — is when we can help Andy and Becky and Charlie and Debbie be successful in their job and in the changes we’re asking them to make. A lot of times it’s around establishing that expectation with the end-user base or the customer base that things are going to be coming in at a much more rapid pace. Now, I do think things like this (referring to smart phone) have changed the expectation, right? Because if an app breaks, now I expect to get a feed in two days of the updated app that’s not going to crash on me. That’s created an interesting expectation with inside business, because now inside business, I expect things to be served up like they are to my phone when they’re not working.

DF: Yeah.

TC: That can be hard for an IT shop. Because if they’ve not started to embrace Agile, this could be three to six months for us to finally get our acts together to make that one fix that everyone’s now expecting to happen like that. Because customer technology is updating in a much more rapid pace than a lot of times IT.

DF: Yeah, I couldn’t agree more.

TC: And I think it comes down to that smart phone in my pocket.

DF: Yeah. All right well thanks again for your time Tim. We’ve really enjoyed talking to you at the change management conference. So, thanks for joining us for another Agile Amped podcast. Subscribe now to receive real-time updates of future episodes. We’ll be at other events across the country, so look for us there. You can find our podcast available on YouTube, ITunes, or the website.


The post At the Intersection of Agile and Change Management appeared first on SolutionsIQ.

Categories: Companies

To Mock or Not to Mock: Is That Even a Question?

Thu, 05/04/2017 - 17:00


Mocking is a very popular approach for handling dependencies while unit testing, but it comes at a cost. It is important to recognize these costs, so we can choose (carefully) when the benefits outweigh that cost and when they don’t.

A Quick Overview of Mocking

Mocking is a way to replace a dependency in a unit under test with a stand-in for that dependency. The stand-in allows the unit under test to be tested without invoking the real dependency.


A note on terminology:

It would be more accurate to use the term “test double” instead of “mock”, but somehow “mock” has become the generic term among programmers. Bob Martin has suggested the following relationship among the different kinds of test doubles:


That is, a mock is a spy is a stub is a dummy. A fake is a different kind of thing (it has business behavior). For a more detailed explanation of these different types of test doubles, see

The Costs of Mocking

In my experience, there are 3 reasons to mock sparingly:

  1. Using mocks leads to violations of the DRY principle.
  2. Using mocks makes refactoring harder.
  3. Using mocks can reduce the simplicity of the design.

All of these reasons are interrelated (and, you could argue, are just different ways of saying the same thing), but let’s take them one at a time.

Mocks Can Lead to Violations of the DRY Principle

I first read about the DRY principle in “The Pragmatic Programmer” by Andrew Hunt and Dave Thomas. They state it as: “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” (p. 27).

So, this isn’t just about code duplication – it is about knowledge duplication. When you use a mock you are in violation of this principle because the knowledge of how the components in the system interact is defined in two places: once in the production code and once in the tests. Any change to those interactions has to be made in two places.

Mocks Make Refactoring Harder

In the preface of Martin Fowler’s “Refactoring” book, he defines refactoring as “the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure”. One of the XP practices is “refactor mercilessly”. A fair assumption when practicing merciless refactoring is that unit tests should pass before and after any given refactoring that we do. This is the essence of the red-green-refactor cycle: we only attempt a refactoring when we are in a “green” state, and we expect to still be in a “green” state after the refactoring.

But mocks break this assumption, because with mocks our tests do NOT merely test the “external behavior of the code” but also test the internal workings of the code under test — specifically what other modules are being used and how.

Here’s an example that just happened to me recently. I started out with class A invoking methods on two other classes, B and C.


Then I realized the design could be improved if I structured things this way:


The functionality of A had not changed, as far as its external behavior goes. But in the tests for A, I had mocked out B, so with this refactoring many of the A tests were now broken. Mocking couples the production code to the test code in a way that hinders refactoring, because with mocks your test code knows about the internal workings of the code under test.

Mocking also inhibits refactoring because some refactoring tools do not cleanly refactor code that uses mocks (renaming a method, for example, may not catch method names that are represented as strings, as in some mocking frameworks).

Mocks Reduce Design Simplicity

In Cory Haines’ book “Understanding the Four Rules of Simple Design”, he defines a simple design as “one that is easy to change”. As illustrated in the above example, the use of mocks makes the system harder to change.  When the system is harder to change, we become reluctant to refactor, and the design slowly deteriorates over time.

Arlo Belshee asserts that the need for mocking is a sign of a design with too many dependencies. At a Seattle Software Craftsmanship meetup in May of 2014 he put it this way: Mocking “basically allows me to treat highly dependent code as if it were not dependent, without having to change the design. Perfect for legacy, perfect for learning, a real problem when you are trying to get design feedback. As soon as I remove the [mocking] tool then I am required to change the design and reduce the dependency and reduce the coupling. That’s what all the design literature is about.” (Watch the full talk here.) This is a good description of how mocking reduces the simplicity of the design, namely, by increasing coupling and increasing the cost of change.

When to Mock

So, given these drawbacks to mocks, how do we decide when to use them? I use the following guidelines in my own code:

  • Only use a mock (or test double) “when testing things that cross the dependency inversion boundaries of the system” (per Bob Martin).
  • If I truly need a test double, I go to the highest level in the class hierarchy diagram above that will get the job done. In other words, don’t use a mock if a spy will do. Don’t use a spy if a stub will do, etc. This is because the lower you go in the class hierarchy of test doubles, the more knowledge duplication you are creating. (A test that uses a dummy only knows that a collaborator is used in the code under test. A test that uses a mock knows which method on the collaborator is used, how many times it is invoked, and the types of the parameters that are passed).
  • If I truly need a test double, I prefer to write my own, rather than using a mocking framework. This keeps the code simpler and works fine in most cases. I will resort to using a mocking framework when mocking fairly large interfaces or third party libraries.

Also, as Arlo mentioned above, mocking may be needed initially when getting legacy code under test, until some of the dependencies can be removed.

By using mocks sparingly, we can keep our code DRY, enable easier refactoring, and improve the simplicity of our designs.

The post To Mock or Not to Mock: Is That Even a Question? appeared first on SolutionsIQ.

Categories: Companies

Bringing Agility and Change Management Together at ACMP 2017

Tue, 05/02/2017 - 17:00


Change management is a crucial part of any Agile transformation, because it focuses on helping individuals transform and change in concert with the organization’s own transformational changes. The Association of Change Management Professionals (ACMP) arose in direct response for the need of guidance and support for change professionals from a formal organization. It’s been six years since ACMP launched the annual Change Management conference and SolutionsIQ is again excited to participate in Change Management 2017, bringing our expertise and experience in Agility to share with this industry. This year, the three-day conference will focus on providing the tools to help change professionals, including Agilists, help their client organizations succeed. SolutionsIQ’s all-access podcast series Agile Amped will be onsite so you won’t miss any of the action! You can expect more “Inspiring Conversations” with thought leaders in the change management industry.

Last year, ACMP celebrated its fifth anniversary running Change Management, and the President Donna Brighton and Vice President Rhiannon Cooke shared their pride with Agile Amped. Watch the podcast now:

Agile and Change Management

We have written and discussed the growing need for change management and Agile to come together, because the increasing complexity of the modern world requires an individual and organizational approach to life and work that necessitates an fully developed ability to change quickly and responsively. Here is a collection of some of our thoughts on the matter of leading Agile change.

Leading Agile Change Webinar

Many change leaders approach Agile adoption with naïve expectations. They don’t understand that training and coaching teams alone won’t be enough to ensure that their Agile initiative succeeds. Agile transformation entails change that will be broadly felt throughout the organization in policies, processes, mindset and culture. The key to successfully leading change that runs this deep is organizational change management. Organizational change management helps change leaders usher in extensive operational and structural changes. Even more important, it helps leaders facilitate the human aspects of change that occur during Agile transformations. In this webinar, we discuss what an Agile transformation is, how to successfully engage stakeholders, the critical role of change management and how to lead Agile change successfully.

Watch Now

In addition to this webinar (our most popular webinar in 2016), SolutionsIQ Solutions Consultant Dan Fuller has written more on the intersection between Agile and change management, in particular how Agile methods and mindsets can complement and help evolve traditional change models like ADKAR and Kotter Accelerate.

ACMP 2016 Podcast Highlights

If you’re on the fence about attending Change Management 2017, here are a couple of podcast highlights that may sway you to go.

CIO Tim Creasey at the Intersection of Agile and Change Management

Email Monday, training Tuesday, change Wednesday – that’s how quickly some people think change happens. Prosci CIO Tim Creasey points out that change management aims to “prepare, equip and support people to be successful in the changes” requested of them, and that process needs time to take effect.

Dean Anderson: “Leaders Either Enable or Block Change”

Being First has focused on designing and leading transformational change for 40 years. CEO Dean Anderson has been watching Agile grow in the past decade or so and has come to recognize its value. Dean says that change management and Agile share similar values and philosophies in “how to drive high performance in individuals, teams and organizations”.


Join Us in New Orleans or Online!

There’s still lots of time for you to sign to attend Change Management 2017 in beautiful New Orleans, Louisiana. Great gumbo! If you can’t make it in person but still want to see what the change management industry has to offer Agilists, subscribe to Agile Amped right here, right now!


The post Bringing Agility and Change Management Together at ACMP 2017 appeared first on SolutionsIQ.

Categories: Companies

Keeping Up with the Agilists – Spring Events Roundup

Tue, 04/25/2017 - 17:00

Conference season is in full swing! We love this time of year because it gives us an opportunity to reconnect with the thousands of SolutionsIQ clients, and our own distributed team of coaches and consultants from coast to coast. This spring we will be in so many more places. If you plan on attending any of the following conferences, stop by and say hi! Agile Amped will be onsite at Change Management 2017 capturing video podcasts with thought leaders from the organizational management industry. Meanwhile our Agile Amped In-Depth audio-only podcasts will be onsite at Keep Austin Agile and Mile High Agile, recording deeper dives with Agile experts and luminaries.


Learn more about each event here!

Event Highlight: Change Management 2017

Change management is a crucial part of any Agile transformation, because it focuses on helping individuals transform and change in concert with the organization’s own transformational changes. The Association of Change Management Professionals (ACMP) arose in direct response for the need of guidance and support for change professionals from a formal organization. It’s been six years since ACMP launched the annual Change Management conference and SolutionsIQ is again excited to participate in Change Management 2017, bringing our expertise and experience in Agility to share with this industry. This year, the three-day conference will focus on providing the tools to help change professionals, including Agilists, help their client organizations succeed. SolutionsIQ’s all-access podcast series Agile Amped will be onsite so you won’t miss any of the action! You can expect more “Inspiring Conversations” with thought leaders in the change management industry.

Podcast Highlight: High-Performing Agile Teams with Yasser Farra

“High-performing Agile teams” seems to be what everyone wants — but do you know what that means and what it takes to get there? Yasser Farra, CEO of Agile Accompli and a speaker at Keep Austin Agile, gives his perspective of high-performing teams and how to help create them. He gives us some helpful tips on team makeup and dynamics, team environment, and more. We also spend some time at the end of the episode talking about the upcoming Keep Austin Agile conference.


And don’t forget to subscribe to Agile Amped to get event updates from Change Management 2017, Keep Austin Agile and Mile High Agile!


The post Keeping Up with the Agilists – Spring Events Roundup appeared first on SolutionsIQ.

Categories: Companies

5 Agile Leadership Patterns

Thu, 04/13/2017 - 17:00

A epiphany came to Dan Greening in one of many conversations he had with Jeff Sutherland on the topic of why so many organizations claim to be Agile without actually being Agile. The epiphany was this: an Agile organization needs Agile leadership. It is common today for organizations to claim to have implemented Scrum and failed, then to move on to another framework like Kanban only to have that fail as well. These same organizations may then move on to Lean Startup. The trend lines in Dan’s research indicated peaks and valleys were huge as corporations hired on, and then fired off, mass quantities of coaches. Dan wanted to know why that was the case. After more research, he found corroborating evidence for his suspicions: businesses who retain their agility do so under the auspices of truly Agile leadership.


Brent Barton: Hi I’m Brent Barton and today I have Dan Greening. Hi Dan.

Dan Greening: Hey, man.

BB: You just finished an interesting talk on Agile leadership patterns.

DG: Yeah with Jeff Sutherland.

BB: That went well?

DG: Yeah, it went really well.

BB: I’m passionate about agile leadership, because as we get into bigger and more complex environments, it’s becoming more and more evident that they’re critical to our success.

DG: Right.

BB: Tell us more about your perspective on that.

DG: One of the things that I’ve discovered, and you’ve probably discovered this too, is that we think of Agile, at least initially, as an engineering problem. Okay, it takes a long time for us to do this, the projects sometimes fail, they’re overbudget and over-time. So we started out trying to fix engineering. And we did, largely. We have Scrum, Kanban, XP, all these other great things. But then, first of all, it’s hard to do, so we hire a bunch of coaches to do that and then it costs a lot of money. Then I started seeing large companies hiring massive numbers of coaches, an army of coaches, at millions of dollars per year in cost. They would hire them, they would convert the engineering department. Someone in the finance department would go, “Wow, this is really expensive. Do we have to keep these people around?” Someone says, “We’re Agile already — we don’t need them anymore, we’re converted.” The coaches go away and guess what? Agile would revert. We would get in the situation where the teams wouldn’t have this high level of Agile thinking anymore in the way that Agile would go. And then they would go, “Oh my god, our release times have gone from one month to six months, nine months, twelve months.” So, two years later, after they fired all the coaches, they go, “We better do something.” Someone says, “Well, that was Scum, now we ought to use Kanban.” So, they hire a bunch of Kanban people. Then I saw one recently where they go, “Yeah, that was Scrum and then we did Kanban, and now we should use something different called Lean Startup. That’s the thing!” And I’m going like, “That’s hilarious because Lean Startup is an Agile method but it’s not a replacement for Scrum or Kanban; it’s actually dealing with market-side stuff, product management. And so they can be used really effectively together. And then you see, you look at these peaks and valleys of hired coaches. What’s the issue here? So Jeff Sutherland and I have been hanging out and I’ve been complaining to Jeff for the last five years about this, and he said, “You know, I think one of the things is: who are the leaders?” And he and I started comparing notes, and we’re going, “Oh my god, is the leader Agile themselves? Do they run their company in an Agile way? Do they think about their work in an Agile way?” When we saw that, we saw that agility was retained. And often times they can create agility themselves and maintain it themselves. And then what we would also see is this pattern where a leader might get fired, or leave, or whatever, and then agility would disappear.


BB: What does it mean to be an Agile leader in the context you just described?

DG: That was my first cut. I said, “Ok, I want to tackle that.” Because I’ve been dealing with big companies: I’ve been working with Skype, Citrix and other companies like that. So I said, “What is it about this?” And then I realized, I didn’t really have a good definition for agility. I can go to the Agile manifesto and it’s got some guidance for software developers. If you read it, it’s all about software. I think finance people, marketing people, everybody can be Agile if it suits their economics needs, and it usually does. So, I said, “Before I even tackle leaders and enterprises, I’ve got to figure out what agility is and what it’s defined by.”

So, I looked at all of our Agile practices and what purposes they serve. And what I think of as “chaotic economies.” Production is a chaotic economy, and Scrum works really well for that. Market product management is a chaotic economy, and Lean Startup works really well for that. So, what’s going on there? It’s all about sensing, adapting, and creating new things for an economy and doing it fast enough that you can adapt to the changes that might be occurring. So I came up with five patterns and they’re actually really simple. The first thing is you have to measure some leading indicator about your economy. In scrum, it’s about production. We have to produce something and the big indicators are cost. A leading indicator of cost is velocity. That’s a primary metric. If you just use velocity, though, it gets a little perverse. You start doing high velocity and then you produce crap. So we have to have something else to balance that off to make it not so perverse, so we use defect rate. Then you have both of those and and then we go, “We want our people to be happy, because when they’re happy, they produce more creative output.” We add happiness. So, they’re three metrics that lots of people like to use, Jeff and I especially; velocity, happiness, and defect rate. That pattern, measuring [a] leading indicator, is step number one. If you don’t know what your economy is, why you are doing it and what are some leading indicators that you’re making the right choices — you’re doomed for Agile. You can’t do it.

The second thing is you have to experiment, you have to adaptively experiment to improve. When you do that, you’re looking at your metrics and you’re trying new things. Like our retrospectives. We try new Definitions of Done, Definitions of Ready. We see: does it improve things or not improve things? Today most retrospectives are pretty lame, I have to admit. A lot of people phone it in. Yet that’s the center piece of Scrum really. If you’re really doing a good retrospective, you’ll see this acceleration of velocity. If you’re phoning in your retrospective, you might be better than waterfall, but not by much. So that’s the experimentation side.

The third thing — and these three things give you agility — the third thing is limiting work in process. You can measure stuff and experiment, but if the length time or amount of work to run those experiments is too big, you’re going to be a lot slower than the chaotic economy that you live in. So, if you limit the work in process, you’re going to be fast enough, then you’re doing all the right things. My assertion is, if you’re doing those three things, you are Agile. The problem is, doing those three things is really hard.

BB: That’s true.

DG: Like, you’re measuring stuff and guess what? You’re starting to tell the truth, and people are getting embarrassed, and guess what? They really wish you weren’t doing that. So then you’re experimenting and guess what? Sometimes you fail and sometimes people are uncomfortable about that. And that uncomfortableness is another pressure to stop doing Agile. You’re limiting work in process. And the people are saying around you, “Oh my god, my project is so important. Can’t you do a little on my project?”

BB: Just fit that in. It’s not that big!

DG: Yeah. So there’s pressure everywhere to be not Agile. So those three things are hard, and I’ve realized we do things in Agile to reinforce it a little bit. And one of those things is we embrace collective responsibility. Here’s what I mean by that. When you join a team, you can say, “I’m a developer.” And another person can join the team and say, “I’m a tester.” Then you start doing your thing and the developer gets done. The testing doesn’t get done. You get to the end of the sprint, it doesn’t ship. Someone says, “Here’s a failure. We couldn’t ship it.” You go to the developer and ask, “What went wrong?” The developer blames somebody else. The developer says, “Not my problem, I’m a developer. It’s the tester that did it. The problem, though, is as your project matures, testing becomes more and more of a dominant factor.

BB: Right.

DG: So, we didn’t shift, this developer didn’t shift their responsibility over to deal with that. They just said, “My job is this.” So collective responsibility says I join this team and I agree — I write a contract by joining this team — that I will be personally responsible for the collective output of the team. That puts enormous pressure on individuals to really make up for deficiencies in the team. But the result is higher agility. Now people are adapting with the flow of work that’s coming into the team to deliver value. So, that fourth thing provides enormous stability for Agile teams and we see that in training. XP, it’s all about together as a team, collective code ownership —  as another subpattern of that.

BB: For sure.

DG: And then the last pattern is, you’re often working in a system that is limiting your agility. So here I am on a team and I depend on stuff from other teams, let’s say. And they are slow. And I’m going, “Okay, I’m Agile, I can just ship, ship, ship. But I keep depending on this stuff from this other group that is doing two-month sprints.” It takes them two months to actually give me something releasable. So, that pattern solves systemic problems. So now what’s happening instead of looking at my little team, I start looking around my team and say, “What’s going on in the system around me that is limiting my agility?” And it turns out there’s all these teams I depend on. And so what happens is that encourages people to go out and reach out to those teams and help them. So, famously, Toyota did this, when it was doing just-in-time manufacturing. It’s trying to build these cars, someone makes an order, and then you start doing all the stuff to build the car. Well, they would get all the way down to the tires, and then they would go, “We don’t build tires; we buy those.” So, they went out to the tire manufacturer and said, “Hey, could you make some tires for me? I just got an order.” The tire manufacturer goes, “We do this on a quarterly cycle. We sent you the memo; you didn’t read it. You’re supposed to pre-order however many tires you need for the cars you’re going to build. Well, how many cars are you going to build?” And Toyota goes, “We’re just-in-time — we don’t know!” So they finally got frustrated and said, “Well, I guess we could be a tire manufacturer, but we’re not great at that. Here’s the next best thing: we’ll go out and teach the tire manufacturer how to do just-in-time.” And that’s exactly what they did. And by doing that they actually created kind of an infrastructure of just-in-time in Japan. And we started seeing Honda and other car manufacturers start to adopt this strategy because they could. Their tire manufacturers were Agile and they were sitting there like, sitting on their butts really, but they were like, “Oh, we can do that. We have all these great service providers…”

So, those five things: measuring economic progress, so, leading indicators. Adaptively experimenting for improvement. Limit work in process. And now you are Agile. You won’t be able to keep it unless you do a couple more things: Embracing collective responsibility, creating a culture where individual people feel responsible. And finally, solving systemic problems. And that gets us back to leadership. Right? So, now I’m going, “This is great! I’ve got a definition of agility, I’ve got these patterns, and guess what? They’re totally scalable.” I can go to an individual and I can say, “Hey, Brent I can tell whether you’re Agile by just interviewing you and asking some questions about how you run your life.”

BB: Right.


DG: Or I could go to you as a team or as an executive and say, “Hey, let’s find out if your organization is Agile or not. What are you measuring? What are you experimenting on? What’s your work in process limit?” And this is important. It’s important on so many scales. One is, as an executive, do you have a team of people dealing with strategic work? I call them strategic Scrum teams, where you got a bunch of VPs or directors in a room and you’ve got strategic work and a backlog and you’re plowing through it and solving major problems for companies. Another thing you can do is, you’re hiring someone for a position in a company that is Agile. And I’m going, “You know what? You shouldn’t be hiring someone who answers those five questions in a funny way.” That’s how you tell they’re Agile, not ‘that they wrote on their resume, “I know Agile” or “I know Scrum” or whatever it is. CSM! Or I was a CEO at such a thing… It means nothing. Let’s find out the reality behind the system.

BB: Sounds like these are a consumable set of patterns for leaders to really evaluate and participate in the agility in an organization.

DG: Absolutely.

BB: That’s great. I’d love to probe further about the finance groups and all of these these other things and see how those teams are. We must do this again.

DG: Great to talk to you, Brent.

BB: Thanks, Dan.

Want more Agile Amped? Subscribe below!


The post 5 Agile Leadership Patterns appeared first on SolutionsIQ.

Categories: Companies

What’s the Difference Between Mentoring vs Coaching?

Tue, 04/04/2017 - 17:00

As more and more organizations are bought into an Agile mindset and Agile values, the need to transform at the individual level becomes more important than ever before, because only through individual transformations can an enterprise reap the full benefits of organization-wide business agility. Agile coaches, ScrumMasters and even managers are key to making the transformation to every member of an organization. That’s why mentoring and coaching are crucial today. The only problem is that few understand the subtle yet powerful distinction between mentorship and coaching.

Lyssa Adkins sits down with Agile Amped to dispel confusion around these two roles — or perhaps it’s better to think of these as hats that an Agilist wears at different times to achieve different ends. In this our most popular podcast (with nearly 3,500 views), we answer the question “What’s the difference between mentoring and coaching?”


Michael Tardiff: Hi, I’m Michael Tariff with SolutionsIQ, and we’re here at Agile2015 outside of lovely downtown Washington, D.C. I’m sitting here next to the lovely Lyssa Adkins from Agile Coaching Institute. Hi, thanks for coming.

Lyssa Adkins: Hey, so glad to be with you.

MT: You already did one session earlier this week and you’re doing one this afternoon at what time?

LA: At 3:45, in the Potomac C room.

MT: If you’re watching this before then, go. If not, at the end Lyssa will tell you how to get in touch to continue, or start your own conversation with her. At the first session you did something I’ve seen you do before in front of thousands of people — you’ve done something that’s hard to do one on one, which is coach, and then show the difference between coaching and mentoring. How does that work? How do you do it?

LA: Well, it was really great, because two of our alumni of our courses agreed to be — one was a coaching client and one was a mentoring client — so they knew what they were getting into in terms of how that goes. I did 15 minutes of coaching with one, 15 minutes of mentoring with the other, and it created such clarity for the audience, like, “Oh, that’s what professional coaching looks like. I thought it was just trying to manipulate people with open questions.” Actually, that’s not what people think, but it’s often what people are doing in the background. And so it was really important for them to see it. I know when I saw professional coaching for the first time, my mind was blown. I was like, “Oh, that’s really different, that’s a different approach.” There were 400 people in the room, and you know I didn’t pay attention to them.

MT: So it’s as if it was just you.

LA: It’s as if we were in some huddle room off the side in a conference room, in some corporation and someone had came to me with a problem and I said let’s just duck in here for a minute and talk about it.

MT: So, you were fully present with them.

LA: Yeah, and presence is a professional coaching skill, and so is listening fully. And so with those things on board, it’s easy just to be there with that person. And of course I’ve done enough demos now of this to know, you know, we’re gonna land this thing in 15 minutes, we’re taking the person through this general process of how this arc of the conversation goes. And I said to both of them at the beginning, and you know it’s true, “Don’t let this be some kind of fakie demo. Let it be good for you, let it be real for you. Don’t commit to an action, if you get to an action, don’t commit to it unless it’s real.”

MT: Right.

LA: So that makes it all the more impactful, not only for them but for the whole room, to see that you could move a conversation. You could move a problem that clearly in 15 minutes for someone.

MT: So, for the folks who weren’t there, what did they see in the difference between the coaching interaction and mentoring interaction?

LA: Well, both people brought real Agile problems, real problems they’re facing in their Agile transformation, real stuck points for them. In the coaching one, the idea is to coach the person, not the problem. If you coach the person, they’ll solve their own problem. So we work on both the doing aspect — what’s this person gonna do about their problem? — and the being aspect — who are they being, that’s gonna enable their doing? And so I’m using skills like fully listening, asking powerful questions, a lot of self-management.


MT: Management of your self.

LA: (Management of) myself — of these thoughts that come in my head, I wanna give advice. But I think, you know, “Giving advice here is not gonna be as useful as sticking with this person and helping them explore what’s really holding them back.” That’s kind of what coaching looks like, it’s following the other persons agenda, not mine. And in mentoring we still have a focus on their agenda, but now — in addition to this coaching skills — you can add, offering advice, giving resources, telling stories about your experience, maybe teaching about a model you think might be useful. And so it’s much more about selecting from options and the other person come up with options and primarily the way Agile Coaching Institute teaches mentoring is still: end with professional coaching. It doesn’t matter as a mentor if you have the most brilliant idea on the planet, if they’re not willing to do it. Or they give you lip service and say, “Yes, I will” because they feel like they’re some kind of guru and that they need to say yes, but then they actually don’t do it.


MT: Until sitting here listening to you describe the difference, I would have thought coaching was harder, but you just made mentoring sound even harder. Cause you can give advice but…

LA: Its not like it’s free reign to just cram your information toward that other person and make them swallow it.

MT: So how do you balance?

LA: That’s that self-management thing. Some of the thoughts that happen in my head, when I feel myself getting enamored with my own idea and mentoring and I’ve said it once and they haven’t quite taken it and I find myself saying it again, I think “Whoa, whoa, whoa. Back up here, chick. They’re not ready for your idea.” And I might say that: “Seems like you’re not ready for my idea.” That’s cool. (I’ll) get (that) from them. They’re like, “Yeah, it’s a good idea but it really doesn’t kinda fit” — and they’ll tell me why. But if I don’t catch myself, that ambition I have to have them go my way…

MT: Yeah, that’s the hard part.

LA: Right? Right? Then they’re gonna just give me lip service, or think that they actually agree and find out later that, no, they really don’t want to do that.

MT: I was taking with Christopher Avery yesterday about catching yourself, how do you, when you have that “I’m gonna help them whether they like it or not” moment — how do you catch yourself?

LA: They’re are a couple phrases I constantly say in my head. One of them is that this person is already naturally creative, resourceful, and whole. They don’t need me to fix them. That’s one. The other is, if you throw out another idea, that’s just another opinion. We got plenty of opinions in the world! That’s another thought that comes into my head. And besides those thoughts that bring me back, just having presence with the person, in both cases coaching and mentoring, and the intention to serve them more than me. That’s what really does it for me.

MT: I’ve found what you taught me — this person is creative, resourceful, and whole — being the thing that helps so much. I’m not trying to fix them, they already are fixed.

LA: Everyone is doing the best where they are. And sometimes you have great ideas, but your ideas are ten steps ahead of where they are. It’s not very useful to keep yelling from the sidelines, “Come over here! Come over here!”

MT: When we were starting, before we started filming, you mentioned the Competence Cohort that ACI is starting in September.

LA: I’m so excited about this, yes. We’re finally at the point where we’ve trained almost three thousand people now in our primary courses: The Agile Facilitator and Coaching Agile Teams. And those cover off the learning objectives in the Agile Coaching and Facilitation learning path. Now we all know that classroom knowledge does not necessarily equal skill when you get back to work. Plus, plenty of the things we teach in our classes are really hard to do when you get back to work, it’s not the same. The environments are not necessarily set up for it.

MT: It’s not the same…

LA: It’s not the same. The Competence Cohort is based on our own experience in our own professional coaching certification programs. It’s a ten month program, where you are really practicing, immersing, dicing and really pulling apart the skills you learned in the five days of training. And there’s a real compulsion to bring it in to your daily work, which really helps people ground in it. And along the way, if people are interested, we build people up to the level where they have demonstrable skill because we actually do supervisions. People bring in recordings of themselves coaching, mentoring or facilitating or teaching, and they get assessed against a known set of competencies we’ve been working on in the calls and they see where they are, and they get another shot at it. That builds them up to the level of equal to or even above what’s called ICAgile Expert. And so along the way, if people want that certification, it’s easy for them, it’s like an administrative task to get that certification, because its built in to our pathway. Our program is going to be accredited by ICAgile and then it doesn’t stop there, though — because what Agile Coaching Institute creates are transformation coaches. So there’s an additional four-month piece and a ten month overall, and the last four months starts with the residential of the people you’ve been with in your Competence Cohort on the phone, now you’re in person. Isn’t that incredible?

MT: That sounds fantastic.

LA: I know.

MT: I want to do this.

LA: I think you should. You’re gonna get deeper skills in transformational facilitation and transformational coaching.

MT: Excellent, and that starts in September?

LA: It starts on September 21st, there are still a few slots open. You have to have taken the courses, like you have. Then you go on four months of quests to bring in all that new skill you have.

MT: I can’t wait.

LA: I know. And at the end of all that, it’s ACI’s first certification — which we’re finally ready to say we have our first certification because it’s based on real competence — it’s called the Certified Transformational Coach Teams Level. So, multi-team program-level certified transformation coach.

MT: So, I want to talk to you for 20 more minutes but Joanne won’t let me. If folks who are watching want to start talking to you, how do they get in touch?

LA: Go to and my email is — and learn. The website is a good place to start and see what we have to offer and see if it matches what you need.

MT: Thanks so much. Thanks for coming.

LA: You’re welcome.

Want more Agile Amped? Subscribe below!


The post What’s the Difference Between Mentoring vs Coaching? appeared first on SolutionsIQ.

Categories: Companies