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

Transcript

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 better, maybe, than they could have envisioned.

There’s also some work being done with Scrum in the scientific research field about how scientific research teams can work together. I’ll say a little more about that at the end, but I’m not involved in that. I’m only peripherally aware of it. I hope to become involved in it, but not quite yet.

Roy:  We’ve definitely had some experience trying to implement Scrum and some of the agile practices in things outside of the software development world, and with some great successes, but we find that, a lot of times, organizations that are implementing Scrum within a development team just want more, better, faster and don’t really understand that a lot of it is an organizational change.

Especially with a distributed team, how do you deal with that type of feedback cycle? You mentioned having a team that manages your organizational change using a Kanban board, I believe you mentioned. Who are these people? Are these the management? And then, do they bring it to the teams that they must now try these new things? How do you structure that?

Derek:  Exactly. Think of it as double reinforcing loops. You’ve got the teams on one hand…ultimately, you need to couple this exploring to reality. There’s way too much abstract conceptualization in our field, in software, designing the perfect architecture before we implement it, designing the perfect process before we implement it.

The bad news, or the good news, really, is that, in the scheme of things, reality bats last. When we can have the teams trying to make the code do what they wanted to, and, as they try to do this, they encounter problems, whether it’s organizational issues, code issues, technical issues, and even interpersonal issues.

Those problems can become almost the input to these people’s managers, to the people who want [inaudible 14:34] , the stakeholders who want the benefits of more, better, faster.

That’s [inaudible 14:37] between their input. When they act on that input, that improves the teams, and they start seeing the more, better, faster. So, on the lowest level, you’ve got the reality of the systems in the organization, the teams trying to wrestle that reality into something valuable, like a website or an iPhone app.

Then, as an extension of that, the management team that really ‑‑ their role is to facilitate this change, using the same sort of cycle to help the teams make that change. You can even go up one level above that and into the organizations, starting to discover what it should be. I’ve only had that happen with two clients, though.

Drew:  Great, yeah, a lot of great stuff here. Thanks a lot. Before we wrap it up here, do you have anything you’d like to promote or tell the listeners?

Derek:  Yeah. First of all, as I said, Scrum is a learning cycle, and, for a little, tiny bit of information about that, you can feel free to go to a resources site that I set up and I can maybe send this to you later, but it’s kumido.com/resources/scrumbeyond. In there, you can get a little more information about the extensibility of Scrum.

I would invite anybody to contact me with challenges, disagreements, debates. I bet we can do it here, because those are the kinds of things that interest me.

Drew:  Great. Thanks a lot. For the listeners, we invite you to join in on more of that at facebook.com/AgileWeekly.

[music]

Announcer:  If there’s something you’d like to hear in a future episode, head over to integrumtech.com/podcast, or you can suggest a topic or a guest.

Looking for an easy way to stay up‑to‑date with the latest news, techniques, and events in the Agile community? Sign up today at agileweekly.com. It’s the best agile content delivered weekly for free.

The Agile Weekly podcast is brought to you by Integrum Technologies and recorded at Gangplank Studios in Chandler, Arizona. For old episodes, check out integrumtech.com or subscribe on iTunes.