The Learning Organization and Scrum with Derek Wade

Episode 75

August 22, 2012




The Agile Weekly Crew and Derek Wade discuss distributed teams and Scrum in different industries.

Episode Notes

Drew LeSueur, Roy van de Water, and Derek Wade discuss:

Distributed teams

Working with teams in non-software situations

Scrum as a learning framework

Scrum in different industries


Drew LeSueur:  Hi and welcome to another episode of the Agile Weekly Podcast. I’m Drew LeSueur.

Roy van de Water:  I’m Roy van de Water.

Drew:  With us we have Derek Wade, who is a collaboration expert and an organizational change expert as well. Derek, tell us a little bit about yourself.

Derek Wade:  I started off in the software world and it really grew from a creative bent. I liked to hacking out with my VIC‑20 and Commodore 64. I love the fact that it was basically like painting ‑‑ but not by numbers but with numbers. I could type some keys and follow a few rules and cause things to come into being.

Many, many years past through many misadventures, failed projects, and succeeded projects, and succeeded projects that were not terribly interesting and failed in a business sense. I am now basically doing the same thing, helping people be creative, except in a large format.

What I like to say is ‑‑ and I just stumbled upon this metaphor a little while back ‑‑ I am really interested in lasers. I am making human lasers by helping groups of people organize, shine their light, their creative light, all in one direction, and get it amplified.

We can really cut through some incredibly hard and complex problems, and we can send that energy for a really long distance. This shows up in software, it shows up in education, it shows up in scientific research, it shows up in some civic problems. I’ve been trying to use some of these tenets of, for example, Scrum, towards these problems and it’s been very rewarding.

Drew:  In reading a little bit about you, one big thing that I’ve picked up is teams and collaboration ‑‑ you’re really big on ‑‑ getting teams to work together.

Why such a strong emphasis on that?

Derek:  It’s probably some kind of neurosis that I have to find out inside myself some day, but ultimately I think that the problems that are really interesting, things like cosmology, things like finding out the secrets of the universe, things like effective markets, things like poverty, things like civic government, things like making really cool, complex, gnarly systems that almost have a life of their own, are not really individual creations.

I recently saw “Prometheus,” and no matter what your feelings are of on it, I just don’t think it lived up to the ’79 “Alien.” If you look at “Alien,” it’s not just Ridley Scott’s masterpiece. It’s so many people coming together to make it happen.

Einstein and Edison did not work in a vacuum. When people come together and share and align their hopes, and fears, and dreams, and skills, and differences, and arguments, and experiences, and questions, some really magnificent work happens.

That’s the problem that interests me. Something that one person can crack on their own, I’m inclined to let that one person crack on their own.

Roy:  Awesome!

Drew:  Reading a little bit more, I see that you co‑authored or authored a book having to do with distributed teams.

Derek:  Paper! [laughs] We can call it a book, but it’s a very, very thin one.

Drew:  OK. So, now you’ve got a huge emphasis on teams and working together. To me, the distributed team model seems a difficult thing to conquer.

Roy:  It almost seems like the opposite of a team working closely, and working really well together.

Drew:  How do you get all that oomph that you have behind team work, and use it distributively?

Derek:  Right. It’s very seductive, isn’t it? Wow! You mean, really, I can get all this cool human‑oriented team stuff with people spread out across the globe?

In one of my former lives, I was a pilot and flight instructor, and we had this saying about the J‑3 Cub, which was a 90 hp airplane, “That it’s the safest airplane in the world. It can just barely kill you.”

Distributed teams are the maybe most effective, barely effective teams that I have run into. That said, people seem to keep doing it. One can sort of take a philosophical stance of, “Don’t do it,” in which case you’re really helping a group of people who are ‑‑ when you’re focusing only on those folks who are willing to put together physically collocated teams ‑‑ you’re really helping them optimize what they already know how to do.

When you can work with people who, for whatever reason, and globalization is real, who want to work together across time zones there are still things that you can do that don’t have to suck and that can get that gestalt, that the team is bigger and better than the sum of its parts.

I would rather see those kind of teams brought into existence to introduce people to the power of teams over a collection of people, because a team is not a collection of people. I would too strictly live in the world of the collocated teams. Still, it is a bit of an evil.

Roy:  Have you found any distributed teams that are able to perform as well as a collocated team? It seems to me you run up into a glass ceiling eventually where like…

Derek:  Yeah, that’s a really good point. The limits are there. If you histogram the number of effectiveness teams along the vertical axis along the different degrees of distribution along the horizontal axis. What you’ll tend to find is that the distribution for collocated teams is higher and you tend to see this clumping towards greater effectiveness for collocated teams. You tend to see a clumping of less effectiveness for distributed teams.

That said, probably one of the absolute best teams that I have ever worked with ‑‑ not the ‑‑ but one of the absolute best teams that I’ve ever worked with was spread across three countries. One of the, probably, three or five of the most embarrassing “you’re not a team you’re a time‑bomb,” groups I’ve worked with have been collocated. You see a strong correlation between collocation and effectiveness but it’s not cause.

Drew:  I’m thinking like, I’ve got a lot of software development experience working with teams that do a lot of pair programming and pair programming is one way to work. When you’re doing a software project and you’re both working on the same project that’s one way to work efficiently and well as a team.

At other levels, in the organizations that you work with, what are other ways that people work as teams well that are not specifically software‑related?

Derek:  Distributed or otherwise?

Drew:  Either one.

Derek:  For the most part what I’ve been, as I’ve moved away from pure software teams, the thing is that Scrum, we focus fairly strongly on Scrum because as a friend of mine David Koonzt said, “Agile didn’t work, Scrum worked because it was something people could grab and hold onto.”

As Scrum has taken hold, people really look at it in a narrow sense as it’s a software development methodology, but it’s really a learning framework. If you consider learning as one or many people navigating and creating a map of an unknown domain and gradually mapping it in pursuit of an objective, that describes change.

That describes learning. That describes product development and then finally way down at the smallest subset that also describes software development, but software development alone is a small subset of what we can use for example the Agile framework Scrum for.

When you consider that it’s important for people to go through these cycles of having experience, reflecting upon them, making some concepts in their head, experimenting trying stuff out and continually going round through this thing that’s called the “Kolb’s Learning Cycle,” Scrum sets people up for that magnificently.

When they’re distributed and working on software they’re going through this cycle between planning, experimenting, trying stuff out, sharing information, reflecting, and getting better and better, meanwhile improving their code.

You can bump that up a level, and you can start applying the exact same framework as a means for navigating an unknown domain to problems like organizational change. We are organization X. We would love to become organization Y. We don’t know how. It’s the same kind of problem as we have a list of items in a backlog. We would love the have software. We’re not exactly sure how, but we’ll iterate our way to it.

That’s one area that I worked at. It’s basically in agile adoptions, when people say, “Please come install the Scrum for us.” The first explanation is that people’s minds aren’t buckets to be filled. It’s something that we navigate and learn together. So I set up a management team as a scrum team.

Another area that I’ve just recently had the good fortune to work in, this has been in instructional design for universities. Instructional designers do things where they take, basically, offline courses from faculty and professors and turn them into some online modules. It’s not as straightforward as you might think.

For years, they’ve been treated as a transcription problem. Just like you transcribe software requirements into code, and it’s so easy and anybody should be able to do it, the same sort of myth is present in the instructional design world.

By setting up a team to go through these cycles of experience, observation, conceptualizing, and experimenting round and round as they make their work visible to each other on a Kanban board, they’re actually navigating that same sort of unknown domain to arrive at solutions that are bett