BT

Diana Larsen on the Conditions for Best Job Ever, Team Communication and Five Rules of Learning
Recorded at:

| Interview with Diana Larsen Follow 0 Followers by Shane Hastie Follow 28 Followers on Jan 06, 2015 |
17:47

Bio Diana Larsen consults with leaders and teams to create work processes and environments where innovation, inspiration, and imagination flourish. She is considered an international authority in the areas of Agile software development, team leadership, and Agile transitions. Diana co-authored Agile Retrospectives: Making Good Teams Great! and Liftoff: Launching Agile Teams and Projects.

Sponsored Content

Every day, Agile practitioners and thought leaders are defining and refining new and existing practices that bring Agile’s values and principles to our world of work, play and service. Agile2014 reinforces our understanding of proven methods and illuminates some of the exciting new innovations that represent the future of Agile.

   

2. Let’s delve a little bit deeper into that keynote, your keynote was Best Job Ever, tell us a bit about that, what’s the best job ever?

Well my best job ever isn’t necessarily your best job ever or anyone else’s. That’s an important point as we each have to find our own and that’s really what the keynote talk was about: how do you get in the place where you can just say: “I love what I’m doing, this is the best job I’ve ever had”, knowing that there might be even something better down the road. That was the theme of the talk. We talked about 3 different aims, 3 different ways to get there, conditions you have to satisfy: knowing that you are doing the kind of work you love doing; then also feeling like there is a purpose for that work, knowing what contribution you are making, why that work has meaning, and then knowing who you want to do that work with and for. We call that carrying for your tribe. Knowing how we put our tribes together and how we find our existing tribes. I’m lucky, of course, because I found my tribe a number of years ago and it’s the Agile Community. So it’s just a delight to be able to give back.

   

3. One of the things that you showed in your keynote was a really great model of team communication, can we delve a little bit deeper into that?

Sure. That model is one that I developed probably 20 years ago. I used it a lot when I was working with teams doing work process redesign and focusing on team development in those days, and management development that’s related to managers understanding how to manage teams. There was a shift for folks then.

Those work process design days were very interesting because I was working with knowledge workers, highly skilled professional people, who had formerly been individual contributors, when we ask them to redesign their work – this is work I did with my partner Sharon Buckmaster – when we ask them, gave them some principles for redesigning their own work. We never did it for them, we guided them, and inevitably they would come up with some kind of teams, at that time we called them self-managing, now we call them self-organizing, cross functional teams. And then they would say: “Ok, now how do we do our work?” We looked at a lot of things, we looked at the Tuckman model, all of those things that are out there, and we said: “How do you really distill the behaviors, how do you help people understand what behaviors they are going to need to look for and develop in themselves”. We discovered that there is a sequence, but each part of the sequence feeds the other parts .Today I’m talking about it as kind of an ecosystem of interactions– “individuals and interactions,” where have we heard that before? Those interactions are really important. Technical people who have good collaboration skills, that can be very effective at collaborating, produce the best results and the most satisfying work for themselves.

The model is a reflection of that and it’s about the need to start with establishing trust–at least enough trust that everybody is willing to say: “Ok, I’ll work with this group of people, we can move forward and really get to work.” Then there is the question of: what is the work? And are we really committed to it? Am I committed to this work because it’s seems like worthy work to me? (That’s about purpose again) Am I committed to doing the work with these people? Is this a group of people I think I can be effective with?

To some extent, those are the first two parts of what Ainsley and I talk about in the Agile Chartering Model: purpose and alignment. When you have that, it really feeds the trust and the trust begins to grow a little more as we understand that we are both very committed to the work. It becomes easier to deal with the conflicts that come up because I know we are working toward to the same goal. Even if you and I have a disagreement about how we are going to approach something, knowing that we really are committed to get to the same end, that we really want to serve the same customer, makes those conflicts, those differences of work style or opinion or whatever it might be come up, it makes working through those a little bit easier and a little bit simpler. Still not simple or easy necessarily, but a little bit better.

As we continue to do that, face that kind of adversity together–we’ve got a problem in the team, we have to work through it–as teams gain skill in that, they feel more committed to each other, more trust grows, the loop keeps going, and that enables folks to be much more creative and innovative together. Because what’s group creativity and innovation other than working through the clash of multiple ideas and really finding out how to make that diversity work for you and come up with something. That is synergy, right? Our collective efforts are greater than any of us could have produced. Then you get that kind of creativity and innovation. Anybody will tell you who’s been on a team that’s done that, that’s had that kind of a creative group experience, they will say, “that was the best job I ever had.” “That was awesome.” And as people trust each other more, and learn more about how each other works, it keeps going, and that’s how you get to high performance.

So that’s the model, it’s really thinking through, why are we interacting? To what end - so we are passing information back and forth - but what is that doing for us as a team? How is that really building us as a team? Why would we focused on individuals interacting with each other being so much more important than process and tools? Well it’s because of that. It’s so imperative to getting to the kind of high performance that every organization wants and everyone wants to be a part of.

So in a nutshell that’s the model.

   

4. Great model, one that I personally I’m going to use. Another model that you’ve been working on, I know, and the work that you’ve done with Jim Shore, the Agile Fluency, what’s happening there?

Well we did a little experiment this spring, and we had been getting a lot of requests to reprise a 5 day workshop that we’ve done many times, called The Art of Agile, somewhat based on Jim’s Art of Agile Development book, then incorporating the kinds of work that I’ve done around teams and helping teams be effective. We put together this workshop and people liked it. We did it several times. I don’t know maybe almost 10 times. But we hadn’t done it for a while, and we were getting some requests from people saying: “When are you going to do this again, we want to sign up for it!” So there was this. We hadn’t heard from companies that wanted us to come in and do the whole group. People were asking for a public workshop. Of course, if that’s not your business putting on public events, that’s a tricky thing.

At the same time we were getting a lot of requests for more information about Agile FluencyTM model and the Agile Fluency Path and those kinds of things. We were getting some interesting contacts from people who said, “I’m using it and I’m using it in these ways and here is how it’s working for us.” Of course Jim was using it in his practice, and I’m using it at mine. We thought, “what if mashed these two up, what if we said we are going to do a kind of the Art of Agile Bootcamp, but it’s going to have this Agile Fluency material built into it?” Because we knew that’s the best way for people to learn it. So we decided to give ourselves one more challenge, which was: Let’s treat this like a Lean Startup. Let’s do some kind of a test to see if there is really a market, and we decided to do that through KickStarter.

Well we didn’t get to our Kick Starter goal, and that’s jumping to the climax of the story. But we learned a tremendous amount about who is interested in the model, what they are interested in, and how they are using it, because a lot of people communicated with us. We learned about places where they had developed a whole game around it that they use internally in their organization. We learned about people who have been using it with leadership teams. We learned about people who are using it with other teams, and so on.

We haven’t really decided where we are going to go with it next, but it is getting this greater body of work around it. At some point we are going to figure out how to coalesce that and pull it together, move that forward. We’ve both been very, very busy over the past several months. So we really haven’t a chance to put our heads together and figure it out. We are still getting requests, so we know there is interest there. We just have to figure out how to serve it in the right way.

   

5. Another area that you touched on in our conversation earlier is the Five Rules of Learning, this is something that you’ve been working and you’ve come up with, you and Willem?

Yes, my son, Willem, is a brilliant young man if I do say so myself. He has been focused on how people learn? What are the conditions that people need for learning? By coming at it from the perspective of learning languages, and trying to find new and better ways to really help people gain fluency in other languages, so that more people can be multi-lingual.

I came at it from the point of view of the more I observe teams working together and think about retrospectives and some of the other tools that I’ve help to bring into the community, the more it seems to me that it’s all about learning.

Continuous improvement is all about learning what we are doing and how it’s serving us and how it isn’t. The chartering model is all about learning about our purpose. When I visit software teams I see them learning about their customer and learning about the behavior of the code. TDD is about learning how to pass a test and then learning what we need to do to refactor it, to make it as simple and elegant as possible. I kept seeing all of this learning going on, and Willem and I were having these conversations about what we from each of our perspective were seeing in this area of learning and we came up with what we call “The Five Rules.” I’m comfortable calling them rules because I think of them like the five rules of Open Space. They are like laws of physics, they are observations. There are things that we see that consistently seem to be true. They are not like rules we are imposing. They are rules that we observe happen when people are in really good and effective learning situations. They are:
1) “Keep it Alive” and that has to do with remembering that it’s the humans, who are doing it, right? How do we tap in to what we need as humans, is everybody hydrated, can everyone hear, what do we need as human beings? Emotional connection very often. So on many levels how do we help to keep it alive for the people who are doing the learning?
2) The next one that we talk about is “Do it for real” and this is about how do we develop fluency, what is the skill that we want to go after and how can we get as close as possible to actually practicing that skill? It’s the best way to learn it. So, if we want to look for something in a retrospective, and we really want to continue to improve in some area, how can we begin doing that for real? How can we begin designing an experiment or something so we can actually test it out? That’s how we best learn about it.
3) The third one is “Setting first,” and it has to do with what’s the physical setting? Actually what kind of cultural atmosphere are we doing the work in? Does that support these other rules? Basically, setting first has to do with, Are we keeping it alive? Are we enabling people to do it for real? Those kinds of things.
4) The 4th one is “Start obvious, stay obvious,” and that is that we want to be as clear as possible. We want to have the strongest possible signal strength, cut through the noise so that we really know what it is we are focusing on, what it is we need to learn and eliminate the confusion and ambiguity and hesitation from just really jumping in and doing it.
5) And then the last one is “Focus on the flow” and that’s about how we sequence the learning. How do we think about the flow of learning? What are the, Willem calls them bite-sized pieces, that we want to take so that want we want to learn is consumable for us? It’s not either overwhelming and panicking us or boring us. There is a place in the middle there that is flow. We think of it as a dial. You go down to boredom or you can go up to panic, but somewhere in the middle there is just enough edge. There is just enough interest that I really want to keep learning–I’m not bored, but I’m not panicked. Finding that point for the person or the group or for managing our own learning for ourselves, gives us conditions under which the learning becomes more of a flow.

So those are the five: “Keep it alive”, “Do it for real”, “Setting first”, “Start obvious, stay obvious” and “Focus on the flow”.

Shane: Really great set of simple principles, simple rules.

They very much are simple rules for learning in the sense that the complex adaptive systems community uses simple rules, they really fit.

Shane: Diana thank you so much for taking the time to talk to us today and enjoy the rest of the conference!

I’m so happy to do it, thank you!

BT