I came into the Agile world actually just before the manifesto was written, I had some colleagues who had been looking atand extending Extreme Programming and other things, and they kept saying to me “we think you’d be really interested in this stream of things”, because my background was in work process design and organizational design. So, I got introduced to Agile and I really fell for it and I said “we are going to have some issues here around organizational change and getting managers on board and helping customers understand their role”, and so in the intervening years that’s been the message I’ve been carrying and the work I’ve been doing. And along the way there was a lot that had to do with team development and how to help teams be really successful and so I wrote a couple of books, one with Esther Derby called Agile Retrospectives and then another one with Ainsley Nies called Liftoff and now I am still very much interested in how do we get managers on board and how do we manage the change and I am also really finding a strong interest in how do people learn, because learning is so integral to change, and how do organizations learn and how do teams learn as whole entities, how do individual folks learn. And so, that’s one of my current streams of thought and study and writing and so on.
Craig's full question: It’s interesting how those things kind of all wind together, I guess myself and most of my colleagues know you through your original Agile Retrospectives book. I guess that’s been a huge success because it’s a book that I see on bookshelves all over the world that I pass by. Without delving into that, that was written so many years ago now, how is the world of retrospectives changed, especially given that you are saying that you are interested in how people learn and improve?
Right. The book was written in 2006, or it was published in 2006, it took a couple of years to write it and in that time, a number of things have come online, many folks have very much embraced the practice, other folks are kind of abusing it but that always happens. The folks who have embraced the practice have joined Esther and I and some of the other folks who were early on doing retrospectives, we have an annual Retrospectives Facilitators gathering, where people come together and they share ideas and how to extend the practice, some when I hear ideas for good activities and things I put them on our FutureWorks Consulting blog, there have popped up several other websites that are aggregators, there’s one called retrospectives.com, is Norm Kerth’s, but there are a couple of other ones out there, websites that are starting to collect various new retrospective activities to keep them alive.
And what I am learning about learning is that one of the primary things that you have to do if you want to help people learn or if you want to learn yourself is figure out how to really keep it alive, how do we get in touch with the humanness, make sure it’s connecting, that it’s empathetic, that people are having a chance to connect with each other and those kinds of things. And I think some of the retrospectives that I hear about that don’t work so well are the list maker ones, that’s how I think of them, where people come into a room, first thing they do is “OK let’s brainstorm, what worked well and what should we do differently”, they make the lists in a whole big group there is not that much interaction, they look at the list, they say “yes, that’s right” and then they leave. Because they’ve only got 20 minutes or something to hold the retrospective, that doesn’t lead to any improvement and it doesn’t lead to improvement for a lot of reasons. But one of the reasons is it’s just kind of a dead kind of meeting, there’s no real spark there. So, I am looking at those kinds of things for how do we really apply what we know about learning to help our retrospectives be more effective.
Craig: I think the interesting thing about that book to me, and it’s something I’ve been hearing here at the conference this year a lot and resonates with my own thinking as well, is as an Agile community we have to be mindful that there are people that haven’t been on the journey as long as you and I have.
That’s right.
Craig: And I still, when you and I teach Agile 101 courses, the amount of people that still only come in and know the two or three questions.
Yes, two, or three, or four questions.
Craig's full question: And you point them that there is a wealth of other things in a book that was written in 2006, which is really awesome, I think that’s the nice thing about that book, that it hasn’t really gone away. But if you were rewriting it now or you were doing a second edition, is there anything that you would say has changed in the time since you’ve written it, that you really wish you could put in there?
Well, I would put in more activities, I think there is a bigger repertoire available to people out there now.
Craig: And luckily, they can get those online.
Yes. Actually Patrick Kua recently wrote a book through Leanpub, called Retrospective Facilitator’s Guide, I think or something like that, no, it’s The Retrospective Handbook, is what that one’s called, and it really carries a lot of the information about how leaders prepare themselves to facilitate retrospectives. So, I don’t think we need to add that in, he really has covered that in a very nice, very lovely way. I think at the time we sort of assumed that the need for continuous improvement was self-evident, and it turns out it’s not. So, I might put more in there about why are we focused on this and why is it important to do retrospectives? There is a little bit in there, I think I would emphasize that more.
Well, the full title is Liftoff: Launching Agile Teams and Projects and it’s about that part of product development where we’ve decided what product we are going to build, we know we are going to build it, we’ve done all the due diligence, the project management initiation activities, and we know we are going ahead and it’s time to pull a team together now and get them started on doing the work.
So, what my co-author, Ainsley Nies, and I found in our experience was that if we really paid attention to that moment in the project and gave team members a real understanding of what their purpose is, how they are going to work together in alignment, what context they are building this product in, taking a pause to do that, only takes a day or so, and then also some of the other activities around a launch, a liftoff, maybe getting the architecture together, building the initial backlog, spending time there paid off in accelerated project performance later on. And so we wanted to share that with people, that seemed like retrospectives what a lot of people don’t know is the number 12 principle was always in the list in the Manifesto about reflect, tune and adjust, but there was no retrospective practice until Esther and I started talking about it and wrote the book. And Ainsley and I were looking at the landscape and saying “you know, there is no practice about how to really start teams off effectively and yet we know there are some techniques for doing that” and so we wanted to collect that together in a book. We also in that book included some stories from a lot of our colleagues about how they have effectively started teams and what was interesting about that is, we have I think nine stories in there, and four of them are about restarts. So, if you didn’t do it at the beginning, it’s never too late, you can get some benefits by holding a restart liftoff, but of course you get the most benefit if you do it right away.
6. [...] I guess the whole thing with Liftoff is really about collaborating with teams, right?
Craig's full question: And I guess that book’s interesting, I have read, there are books like Jonathan Rasmusson’s, for example The Agile Samurai, which talks a lot about that, but having been in organizations that use that, their liftoff is not days, like you talk about, but sometimes weeks or perhaps even worse than that, so I really like the fact that it’s that short timeframe. So I guess the whole thing with Liftoff is really about collaborating with teams, right?
Absolutely. Well, it’s about really starting the collaboration between the product owner and the teams, making that tight right at the beginning. Because the product owner or product manager, however a given company decides to frame that, is the carrier of the purpose. And that purpose is about the vision and the mission, how success is going to be measured and knowing that is a strong motivator. We know from Dan Pink’s book, Drive, that purpose, autonomy and mastery, purpose is one of the strongest motivators there is and so, getting the whole team to understand what is the purpose of this work, why does it have meaning for them and why does it add something useful to the world is huge.
Craig: So, one of the things that I notice you have been speaking about quite a lot lately is something called the Agile Enterprise Adoption program.
Right. We actually call it Supporting Agile Adoption and it’s in the program list on the Agile Alliance website. Esther Derby and I had a brainstorm about it and she initially got it going, then she handed it off to me and last December I handed it off to Jorgen Hesselberg who is now the director of that program. And we are really looking at what have we learned so far, about how to move Agile into the enterprise space in a way that really works and because it has so many more implications around structure change and culture change. Hendrik Esser, who is one of the people who has been really helping us with that program, did a presentation just a few minutes ago about what he is doing at Ericsson, and he talked about the importance of lived values, practices and culture and how culture has structure and operations and governance and all those things in it and then all those things make up a culture. And that Agile does better in certain kinds of cultures than others. You can make it fit anywhere, but you can also give it a better chance of success and a better chance of delivery. The other thing I’ve been working on a lot is this Agile Fluency Model with Jim Shore, and it’s a similar kind of thing, we talk in there about at what point do you really look at at the enterprise level, what do we need from our teams, what benefits do we want to get by adopting Agile and what trade-offs or investments are we willing to make? And that those are really critical to think about, both pieces of that and the trade-offs and investments have to match the benefits that you want.
Well, what Jim and I began to notice was that there was a lot of talk at conferences and on the various discussion groups on the web that you’re either Agile or you’re not. And again, that didn’t match our experience. We saw that there were, methodologies aside, there were different flavors of Agile that we saw being very effective in different organizations, and it wasn’t all the same but there were some commonalities, so we began trying to tease out what those were and we did several iterations on the model, we took it to some open space conferences where we could just have conversations with people about where were we on target, where weren’t we, what matched their experiences, until we got to a place where we were getting a lot of validation back that said, yes, that seems to be pretty much what it is. And what we discovered is that, we don’t think of it so much as a competency model exactly, although that’s a piece of it, what do you do in that sense it’s competency, but it’s not a maturity model. What we are saying is it really does depend on what benefits you want and what you are willing to invest, what’s the right Agile for you.
And in my home state of Oregon, Portland where I live is at the very north border and Medford is at the very south border, but the thing is, and you could drive all the way from Portland to Medford but if what you really want is the state capital, you should probably stop in Salem, and Medford isn’t any better than Salem if what you need is state business. So the same thing is true of these different forms of Agile. If what you really need is consistent delivery on a cadence that matches the customer’s need, well then what you need is two-star, and you don’t need more than that, but you certainly don’t need less, but you need that. And that requires certain kinds of trade-offs. So, that’s how we built the model, we’re still thinking about it, still extending it, still exploring it, we have been thinking a lot about what metrics are attached to that, how do we validate that in a certain setting, how do you know where your teams are, what metrics do you look at. So we’ve been playing around with that and we’re coming up with some good stuff there. So, we’re continuing to work on it some, the article is on Martin Fowler’s website or you can find it just by agilefluency.com.
Well, part of it it’s what we embedded in the model. So, the first-star fluency, that we’re calling it, is a team that really can shift its focus to delivering value, business value, customer value. There are a lot of software teams out there that are very good at building code, but what their real focus is on the elegance of the code, and that’s great, you kind of need that as a baseline, but Agile has this shift that says working software, we’re delivering working software, and it’s a customer collaboration and we really want this value to be attained and just that, the idea of working in teams and focusing on value is already a lot. So we can look, we can go into an organization and we can say are the teams consistently pulling the highest priority items and working on those and delivering those? Is the team working as a cross-functional team? Do they have all the skill sets they need? Have they been able to minimize hand-offs? So, those are observable metrics and we can go in at various periods of time and say is that still happening, is that still happening, is that still happening. And we know that if those conditions are present, you’re going to get certain benefits from that. So, it’s those kinds of things, very observable kind of metrics, but not necessarily quantitative, how many dollars are there.
Craig: It comes back to the conversation.
It comes back to the conversation.
Craig: Like you all have to understand what value means in order to know if you are delivering it.
Well and I think that for those of us who work in the Agile space, that starts at the story level, card, confirmation, conversation, it’s fractal, it goes all the way through. So, everything you look at in Agile you really need to be saying “what is the statement, the card, how do we know when we have achieved it and what conversations do we need to have to get there?” and whatever you are trying to accomplish in Agile, going back to that is a touch stone is not a bad idea.
Craig: You spent a number of years involved with the Agile Alliance and they put on this wonderful conference every year, I know you’ve been Chair in the past and as someone who has attended for the last six years, thank you very much for your contribution.
You are welcome.
I like to start things, so I’ve been very happy being a part of the early days of this organization and I feel like the work that we’ve done, particularly in the last six years has been to, as we brought Phil Brock on as our Managing Director, and have really worked on getting the organizational infrastructure in place so that we can go out and do a lot of other kinds of explorations and support other kinds of things. So I’m very proud that we’ve done that. We have a very highly functioning, high performing board which works as a distributed team because it has members from all over the world and so we have to wrestle with some of those same issues, although we’re not working together every day, we are working together frequently or have worked together frequently, so I am just looking at the opportunity to continue to extend. One of the ways that we have just really put our toe in the water with is how do we serve a more international audience?
Sometimes when I am doing presentations now I put up this photograph I found of the Earth from space at night, all the way around the world, they took a progressive photo. And all the places where the cities are there are lots of lights and where the dark places are there is not a lot of electricity and so on. I put that up and I say “everywhere you see light here, there is software development going on now and there is Agile going on now”, because it really has become a worldwide practice, worldwide approach, because everybody wants the most value. So, the Agile Alliance needs to extend itself to making sure that we are staying in touch with all those folks, because our purpose really is to help the software industry be more productive, humane and sustainable and we do that by helping to promote Agile.
I think Agile is still somewhat in its infancy, we’ve come a long way, we’ve learnt a lot, there is more to be learnt, I think it’s still evolving, lots of new threads coming in that are very exciting, in the last few years DevOps and Kanban and Lean Startup and all of these very aligned kind of ways of thinking have come about, I think there are more out there that we are going to be seeing and I am just really excited about the future, because this whole idea of a new way to think about how we do work, collaboratively, in-tune with humanity, in a way that is sustainable for both the people and the companies and the Earth and that is still producing value, that’s a new idea, it really is a new idea, and we are a part of many, many, many streams of global thought right now, that are moving in that same direction.
Yes and no. Like I said, some of the people in the Agile community may not be aware of all of the other streams of very similar thought that is out there that are contributing to this and that are getting people ready to accept these ideas. So I don’t think we have to do at all, I think that if we could do it in the industries where software is important, which is pretty much every industry at this point, but if we could do it there, then it’s a demonstration project and there are other folks working on the other stuff. There’s the Stoos movement, and Gary Hamel and his Management Innovation eXchange, there are just a lot of things out there that are all looking toward creating these better work places and I think the new generations are going to demand it, so we don’t have to do it all, right?
I think we can do that. We have invited, at this conference there are two folks that I know about for sure, that are both speaking, that are both from outside the Agile community, Steve Bell from Lean IT is speaking in the Stalwarts track and Gene Kim who wrote The Phoenix Project who is very much from the Lean tradition and DevOps is one of our key-noters and so I think we just naturally do that. We naturally go out and look for those similar streams of thought, bring them in and share and collaborate. That’s what we are about. To the extent that collaboration needs to happen I think the Agile Alliance will be right there. To the extent that do we want to become all things to all people, I think that makes the job harder, not easier.
Last year, last fall, we started doing a podcast called Partnerships and Possibilities and it’s available on iTunes, we focus primarily on issues that affect leaders. So leaders at every level of the organization, as it turns out some of the conversations end up being about managers or executives, but we really do talk about how leadership happens throughout, we want to see leaderful organizations. So, every podcast, we pick a topic and my partner, Sharon Buckmaster and I have a conversation about it, we’ve been getting really good feedback on it. We’ve also started doing a monthly newsletter where we are highlighting some of the things that we think are important for people to think about if they are trying to move into an Agile space or into any new thinking kind of space. So those have both been very satisfying this year and new experiments that we’ve tried that seem to have paid off.
14. And if they want to find your work, where is the best place to go?
Just google Diana Larsen.
Craig: Excellent. Just make sure you spell it right!
Yes, spell it with an e, and not an o.
Craig: Well, thanks very much for your time, Diana. Thank you.