Lyssa Adkins: This is a cross-quadrant conversation between myself and Dan Greening. I am in the Richmond Airport and Dan is working out of Jeff Sutherland’s office in Cambridge Massachusetts. We started to have this really rich conversation about a paper Dan just wrote called, “Agile Base Patterns in the Agile Canon” [in Hawaii International Conference on Systems Science, January 2016]. We recorded it because we thought it would be useful to other people. We were particularly talking about Agile Base Pattern #5: Solving Systemic Problems. How about you give a bottom-line about that base pattern and we’ll continue our conversation?
Dan Greening: Sure. I’ll quickly run through the five patterns, and then we’ll dive together into the fifth. Sound good?
Lyssa: Sure.
Dan: Basically I went through all the agile methodologies I could think of, looked at their particular practices, and tried to understand what the purpose of each practice was to serve agility. There are five of these patterns. The first is to measure some kind of leading indicators to figure out whether you are moving toward your goal. You have to use leading indicators, because agile requires you to be fast. You can’t be waiting for a measurement to emerge later down the road. By that time, you’ll be run over by a train.
Lyssa: Right.
Dan: The second pattern is you have to proactively experiment to improve. You could complacently just measure stuff, and as crises emerge in the measurements you can adapt to those, but that’s not going to be fast enough to deal with rapidly changing markets and economies.
The third pattern is limiting work in process, and that is a standard practice of every agile methodology. In Scrum, it’s Sprints and stories that can fit into Sprints, and the requirement that you have a feasibly releasable increment at the end of every Sprint. Those three patterns create agility. You can look at all the agile methodologies and find these patterns. Most major agile practices fall into one of these three buckets. The rest fall into the remaining two. The first three: if you are doing them, you are agile, period. The problem is agile is hard to sustain, and it’s going to be very fragile if those are the only three patterns you have.
So the fourth pattern is embrace collective responsibility. That’s the idea that when we individually join a team, we essentially create a contract between ourselves and the team that “I will be personally responsible for the collective output of the team.” This creates enormous weight on everyone to make sure they get something out the door. And that can mean, for example, developers start doing manual testing, or if there’s only one database person it creates a risk that the team might not be able to ship something out the door if the database programming load increases, so we learn database. That’s the fourth pattern, and that adds sustainability to the team.
These four patterns focus on the agility of the team as an independent entity. The fifth pattern is called “Solve Systemic Problems.” The idea is that as an independent team, not depending on anyone else, we can be agile all day long. But the minute we start depending on things outside us, like suppliers or outsource teams or bosses or the legal department, then those dependencies interfere with our agility. In order to maintain our agility, we have to pay attention to the whole system, even though we’re a cog in the system. In order to solve those problems, we have to start exerting new types of skills that you and I have talked about, Lyssa, related to convincing people, explaining, teaching, coaching and mentoring to get the agility our team needs to get stuff done, as well as the agility the system needs to succeed.
So that’s the five patterns in a nutshell.
When we realized we should start recording this, we were talking about the transition from being a ScrumMaster, which I think is something that deals with the first four patterns, and being a Coach, where you are starting to exert some skills that are very new.
Lyssa: Before we get into that, I think it might be useful to talk about my reaction to these patterns overall, because it reveals my difficulty in accessing the right-hand quadrants, especially the IT quadrant. So you know that I’m an “I” and “WE” kind of gal. It’s not like I don’t like “ITS”, and I am good at dealing with “ITS”. But the way I look at the world is from the left-hand quadrants, the “I” and “WE” side. [Ed: For more information on these perspectives, and Integral Agile in general, see The Agile Coaches' Coach Shares Her View on SAFe in InfoQ.]
I think the way you look at the world is “IT” first, right?
Dan: You mean I look at things as actors, right? Like objects that interact with each other? Is that what you’re saying?
Lyssa: Yeah. That would be an IT point of view. Like looking at something to be measured or dissected in some way to, well, put it into a pattern.
Dan: Right, right. That’s exactly right.
Lyssa: That’s a cool thing.
Dan: It’s interesting. I don’t know if you noticed the conclusion of this paper. I talked about the Agile Manifesto as being descriptive, meaning that it helps give us a sense for what agility looks like, and what I have written is prescriptive, which is basically telling you what to do. It’s almost blasphemy among people in the agile community to even use the word “prescriptive,” right, and I’m just going to go out there and embrace it. The fact that prescriptive work has been dysfunctional, I think, is largely due to people writing the wrong prescriptions. (laughs)
Lyssa: Oh interesting! I first encountered prescriptive stuff when I read, “Software for Your Head” and “Fearless Change.” I looked at those and said, “Oh! Interesting. I kind of don't get why someone needs this level of detail, but OK if people need it, that’s fine.” And then I watched what people did with it and I got kind of allergic to those kinds of prescriptions. Like, in “Software for Your Head,” there’s this whole check-in called “Mad Sad Glad.” I would pay attention to how ScrumMasters and Agile Coaches were using that by how they were talking to me about how they used it in my classes. And they were using it as this lifeless thing: “OK, everyone go around and say mad, sad, glad.” It’s done so mechanically!
And I think, “Oh, holy crap, that’s not what it was meant for.” The pattern expresses it as a right-hand quadrant redux of something that has a lot of left-hand quadrant aliveness in it. I can see the purpose for this and I also get worried about when there’s not enough information and people don’t understand the intention. But, what I wanted you to know is that I didn’t have that feeling when I read your paper.
Dan: That’s nice. Thanks. It’s probably because the pattern language format—or the way I use it anyway—emphasizes stating the problem and all the major forces that constrain a solution, before laying out the solution. So these patterns have a lot of “Why” in them.
There’s also the converse problem when you go for holistic over analytic, one of the things we see in the agile community is a lot of people saying “Well, self-organization is what it’s all about, and you managers and the market itself, you can just go to Hell, we’re going to do what we want to do within our team.”
Lyssa: Right, which also doesn’t have very good results, and certainly doesn’t have sustainable results.
Dan: You and I appreciate that there are two sides to these equations, and we each bring something to the table. That’s one of the reasons we like to talk to each other. I’m crazy analytical guy, and you’re crazy holistic person. Together we create a better yin-yang sort of approach to agile.
Lyssa: Yeah. The thing I’m trying to do, is to let people know that all those perspectives, the “I”, “WE”, “IT” and “ITS”perspectives, are completely important to be active. Because as we get more and more into these patterns, like solving systemic problems, if we as individual actors …
… See how I’m using your language? See, this is what an “I” and “WE” person will do, Dan, we use your language …
Dan: (laughs) Thank you!
Lyssa: If we as individual actors don’t know that all we are doing is looking through a small window at this giant landscape, and were not getting the whole thing, then we are going to make an intervention; try to fix something, or influence something, or convince someone, without having enough of a picture of the whole complex mess that most of us are dealing with. As you say, “This is the place where we break our teeth.”
Dan: Yeah, right. We’ve seen that so many times. I’ve done it many times myself. I think one of the most important things is not to give up, because even with the best of intentions, we’re going to make a lot of assumptions about what executives want or what the whole system needs. But by making the attempt, we often can learn a lot more. The big take-away from my breaking my teeth is to appreciate your approach, Lyssa, and ask a lot of questions and try to understand the perspective of the person you’re talking to.
The analytical people among us, me included, the way we think of interacting with people to find out more about a system is that we create a hypothesis and then we plow ahead with this sort-of arrogant hypothesis and expect the system to push back when we do something inappropriate, and, guess what, we discover more faster by doing that. Well, that’s true … as long as the system doesn’t marginalize you as a result of this inappropriate hypothesis.
Lyssa: Isn’t that amazing! Is that what you do? OK, that’s cool. Good to figure that out.
Dan: We do. It definitely works. But I don’t think it works very well in the Solve Systemic Problems pattern. Your approach is far more effective, long term, but it’s slower.
Lyssa: Just one more thing on the “IT” nature of this paper that struck me and then let’s talk about some other approaches to this fifth pattern. When I wrote the Coaching Agile Teams book, I couldn’t write it in the third person. I tried. I tried really hard. And I couldn’t. Finally, someone said to me, you’re a first-person kind of person, so just write it as if you were talking to the people that you’re working with. So that’s what I ended up doing.
In some ways, it comes across as fuzzy or new-agey. In fact, one Amazon reviewer said, “This is like the worst yoga instructor you ever had.”
Dan: (laughs) Wow!
Lyssa: So clearly this approach doesn’t work for everyone, right? (laughs)
Dan: That’s hilarious. Well, I think I wrote the patterns paper in first-person as an “analyst.” I do like writing in first-person, because then I can use active voice. But I think you’re right, I’m looking at the system as a third person.
Lyssa: Yes! And, you’re bringing in all this third-party evidence. Your sentences are really short. They almost sound like they’re coming from the mouth of God.
It’s really fascinating to me. My approach to a fuzzy world has been to become one with fuzziness.
Dan: Right. I like fuzziness. I’m not sure I can become one with it though.
Lyssa: (laughs) So let’s talk about pattern 5, Solve Systemic Problems. You’ve got a lot of good approaches to this, like analyzing the ecosystem, mitigating system dysfunction, like five-whys, value stream mapping, static dependency mapping, dynamic analysis, and all that really cool stuff. What were we were talking about, when we started to record this?
Dan: I made the assertion that you’re a ScrumMaster up to the point that you get the team to Embrace Collective Responsibility, the fourth pattern, but to be effective transitioning to the fifth pattern, you have to become a coach.
Lyssa: And the coach would probably use a lot of these techniques, especially if they have an “IT” or an “ITS” bias.
Now bias doesn’t necessarily mean bad. Let’s get that straight for ourselves and everyone that might be reading this. Bias just means that’s what you naturally do. It’s the place you have to be wary of.
Dan: Right.
Lyssa: And… it’s still useful. Because the thoughts you have in your native bias are still useful.
Dan: Yes. I do have a bias toward analytical techniques, and so of course those emerge in this paper. In some sense, the pattern structure encourages analytical approaches. The patterns always start with the problem and enumerate the forces that constrain a solution, and then there’s usually only one way to reconcile the forces to come up with a solution and that’s the conclusion you assert in the pattern.
One of the reasons I like talking with you, is that I’d like to layer in these more holistic strategies. For me, of course, it would be to interpret these holistic strategies in an analytical way. (laughs)
Lyssa: Yeah! We’ll probably have to go into quantum physics to go there.
Dan: I can go there. I can be non-deterministic!
Lyssa: (laughs) One of the things you were saying was that you would try to find someone to convince or influence in some way. Tell me about that approach. Let’s say you have some professional facilitation skills on board, and you talk to influential actors in the system, to get more information about what they’re doing and why they’re doing it.
Dan: Well, there’s the A3 problem solving approach, pioneered by Toyota. The idea is that you take a tabloid sized piece of paper, or an equivalent A3-sized piece of paper in Japan or Europe. You basically analyze the problem on one side of this piece of paper with a pencil: you describe the problem, you perform a five-whys cause analysis, you propose a solution, you describe how you would incrementally implement the solution, and describe the outcomes you forecast will arise if you implement the solution. You then shop this A3 sized proposal around to key leaders in the organization. Each time you talk to a person, you have your eraser ready. So they’re going to tell you something new you didn’t know before, so you’re going to erase some old stuff and add new stuff to make it more simpatico with the actual system you’re dealing with. And then you do that many times, with different people.
The A3 format constrains you to this one-page tabloid format, so you can’t spend tons of time writing details about stuff. Oftentimes through the process of doing this A3, the system itself changes. You’re actually informing people about the problem as you go, and then each time you’re adjusting the A3 you’re getting a more accurate representation. And then ultimately someone goes, “Oh, this totally makes sense. We’re just going to do this.” And then, (laughs) that piece of A3 paper sometimes gets lost in the history of the organization and is never heard from again. So, it’s kind of sad, in a way, because the person that actually motivates the change in the system perhaps never gets rewarded for those changes.
Lyssa: Yes, they probably never will.
Dan: Nevertheless, the system improves.
Lyssa: So that is a cool approach. And what if I told you that you could get a result like that in a day, instead of months?
Dan: That would be awesome.
Lyssa: What I’m about to tell is pretty advanced professional coaching skill. I have to give my, “Don’t try this at home, folks,” warning, unless you really go and get training in this. So here is what is what I would tend to do in a situation like that. I would tend to go work with some primary people in the system. It’s probably the agile transformation lead, a couple of vice-presidents, a couple representatives of main parts of the organization that are in gridlock together, or in conflict or have a dysfunction together. And just talk with them a little bit to get a lay of the land, but not very much actually. Because then I would stage something that is basically a human systems coaching intervention.
What it looks like is getting all the actors or at least a significant number of representatives of actors from each of the major pieces of the system. Let’s say we’re having problem with how we release code, and how we deal with compliance stuff way down the line and it’s causing a lot of rework. In this case, we might have people at the program level, team level, release planning, compliance.
So just getting these people even for just a day, in what essentially seems like a workshop to them, but is really a systems intervention, can result in totally unexpected outcomes where those actors themselves will move to solve a dysfunction. All without you, the analyst, being some kind of uber-actor trying to over time…adjust, adjust, adjust, adjust, adjust.
Dan: That’s cool.
Lyssa: There are techniques. One of them is called “Lands Work.” It’s a coaching process from Organization and Relationship Systems CoachingTM (ORSC). Lands Work is the simplest and most powerful thing ever. You have a big pie chart on the floor. Let’s say there are six different groups, so you have six different wedges on the floor. Each representative occupies their native wedge. A program manager wedge, a compliance wedge, etc. Of course, you set up context: “we’re here to talk about this particular issue” and “we’re here today to figure out how to move forward around this issue.” And then you have each wedge tell all the other wedges what it’s like for them in the issue. Each wedge gets to speak that. And then you have everyone vacate all the wedges. Then, let’s say we’re going to work with the wedge for release management. You say, “All the release management people, you stay outside and everyone else come into the release management wedge.” And then you ask some really simple open access questions to these other actors who are now in the release management wedge. Like: “So, having landed in this wedge, what is it like for you in this issue?” They say all kinds of stuff, and then you say to the release management people, “What did they get right?”What you’re doing is injecting positivity into the system. Positive feedback. And you do that for all the other wedges.
What that does, Dan, is that it unleashes the intelligence in the human system. The theory behind Relationship Systems Coaching is that when the system becomes more intelligence, it naturally moves toward a healthier expression of itself, without you, as an agile coach (or whomever), having to figure it out. They figure it out. It’s powerful stuff.
Dan: I like that. Can I give some feedback from the analytical side? One pattern we often see in agile is that we do group decision-making processes in a two phase approach, where in the first phase we each speak from an individual perspective and share it with the group. In the second phase, we try to combine those ideas together. We see that with sticky notes and affinity mapping and stuff like that. And we see it in parallel processing with map-reduce and a bunch of other things.
Anyway, we have so much to talk about. I know you need to catch a plane. It’s been a delight to talk to you.
Lyssa: We do, we do. I really want to tell you more about the things that are possible. I can imagine putting myself in your “IT” quadrant. It might be dissatisfying in some way, because in order to do what I just described, to do this intervention, you actually have to not know. You have be willing to believe that the group is actually smarter than you. Which is actually really hard one for me.
Dan: (laughs) Me, too.
Lyssa: I really do believe it now, but only after I have had a lot of evidence from doing stuff like this. It causes us to live into what we say we believe in, in the agile community, which is emergence.
Dan: Right.
Lyssa: Emergence is a scary thing, when we actually want to be more in control.
Dan: There’s a huge mine full of awesome gems in this discussion. We need to have it again.
Lyssa: We do, we do. I think we’ve started our cross-quadrant conversations that we wanted to expose!
Dan: I think we have! I think we’re going to be writing some things together soon.
Lyssa: I’m really excited about this. I’m so glad you said, “Let’s not let this go. Let’s get on the phone.” And I said, “OK fine, I’ll do it while I’m at the airport.”
Man, I’m digging you. You really opened my eyes to the usefulness of breaking things down into patterns, where I was really leery of them before.
Dan: And you’ve made me happy, just because you’re really famous and you actually will talk to me. (laughs)
Lyssa: Get outta here. You’re hilarious.
Dan: Know that while you’re in Boston I’ll be sending my vibes to you in the best way an analytical person can do.
About the Authors
Daniel R. Greening, Ph.D., is Managing Director of Senex Rex and Enterprise Transformation Consultant at LeadingAgile. He led agile coaching at Skype and Citrix. He has trained and coached hundreds of executives and teams in agile and Scrum practices. Previously, Dan was a serial entrepreneur, statistician and computer scientist, developing the first collaborative recommendation systems for Netflix and Overstock.com. Dan is currently researching, coaching and writing about organizational values, behaviors and structures that produce and support agility, for enterprises, executives, product managers and engineers. He can be reached at dan@senexrex.com.
Lyssa Adkins believes that Agile is an emergent response that helps us thrive in our ever-increasingly complex, changeable and interconnected world. She is a passionate contributor to the discipline and profession of agile coaching and has trained over 2,000 agilists in the knowledge, skills, and mindsets needed to coach teams and organizations to get full benefits from agile. In 2010, she authored “Coaching Agile Teams,” which is still a best seller four years later. Lyssa blogs on AgileCoachingInstitute.com and CoachingAgileTeams.com, an important outlet for #WomeninAgile.