Liftoff: Launching Agile Teams and Projects, with Ainsley Nies
November 30, 2011
The Agile Weekly Crew and Ainsley Nies discuss the book Liftoff: Launching Agile Teams and Projects
- Launching Agile Teams
- Starting Project Right Matters. Project Chartering Helps.
- Project Kickoff Challenges
- The PAC Model (Purpose, Alignment, Context)
- Chartering Agile Teams
- Can Liftoff Help With Organizational Change
- Agile Adoption As A Project
- Benefits Of Understanding Context
- Applying Liftoff To An Existing Team/Project
- Chartering Doesn’t Mean Documentation
Jade Meskill: Hello, and thank you for listening to another episode of the Scrum Cast. I am Jade Meskill.
Roy vandeWater: I am Roy VandeWater.
Derek Neighbors: I am Derek Neighbors.
Jade: We have with us a special guest today, Ainsley Nies.
Ainsley Nies: Hello. [laughs]
Launching Agile Teams
Jade: All right. Ainsley has co‑written a book with Diana Larsen called “Liftoff: Launching Agile Teams & Projects towards Success.” Why don’t you tell us just a quick 30‑second overview of the book and what it’s about?
Ainsley: Well, as you can tell from the title, the book is about starting agile teams right and projects, of course. We talk about liftoff as the primary way to do that. Liftoff is when at first get together that you have once a project has been initiated.
Also, in that, we believe that chartering belongs in every lift off, although there are certainly many other things, activities that you can do during a lift‑off.
Starting Project Right Matters. Project Chartering Helps.
Jade: OK. Awesome. What was your motivation for writing this book?
Ainsley: Well, both Diana and I had done some chartering independently and on our own. We had both found that that’s an important step to take. However, we’ve both been involved in lots of retrospectives. As you know, Diana has written and co‑writes with direct respective books. So she knows a lot about that. But, I also have been doing a lot within HP.
One of the things that we discovered in just casual conversation, besides our interest in this, is that we had learned from doing as many. Literally hundreds between us of retrospectives that a lot of the things that come up. Especially repeatedly in retrospectives could have either been eliminated or mitigated had people really started their projects off right.
When we say “right” we mean with some kind of chartering effort. We looked around and although, we both know people who have been talking about this for a long time. We didn’t see anything written or any way to share what we knew. So we decided to fill the void.
Jade: Great. I’ve read an advanced copy of the book and really enjoyed it and have actually put quite a few of those techniques to use with great success.
Project Kickoff Challenges
Jade: What do you think are some of the biggest challenges when you are starting off a new project?
Ainsley: As we always say, it depends. Many things can get in the way. The first, of course, is communication. For instance, one of the bigger steps in chartering, besides understanding the framework for it, is that the chartering process, itself, really emphasizes understanding, practicing, and communication. Learning to trust each other so that you can have good communication. Some of the steps throughout chartering actually emphasize how to do this. Communication is a big one. If you don’t have clear communication, none of the work you do during chartering itself is going to stick.
We talk a lot about communication. We believe that chartering actually catalyzes the interactions needed to accomplish a lot of the project work. It accelerates the team in collaborating and communicating.
The PAC Model (Purpose, Alignment, Context)
Communication is really huge. There are more specifics, like common misunderstandings about what you are actually supposed to do. Again, communication is part of that. Part of our structure, we have something called the P ‑ A ‑ C ‑ model. The PAC model as part of our frame work. That’s purpose, alignment, and context.
In Purpose, that’s where we cover the product vision, the project mission, and project measures. Actually, management tests, we call them. Understanding those three elements of the larger purpose is part of what creates that sense of knowing what you are doing. The discussions that are involved in understanding and developing each one of those elements of purpose also helps create that clear understanding of what purpose is. Purpose is inspirational and it should add be motivating for the project work itself. Part of the reason we focus on purpose is to make sure that people have a common understanding.
Chartering Agile Teams
Derek: You mentioned that you guys did lift off also addressing creating teams as well, correct? In the book?
Ainsley: I’m not sure I got your first? Creating teams? Is that what you said?
Derek: Starting off teams or chartering teams.
Ainsley: Oh, yes. Because we believe that when a project first launches and all the initial steps are done. Somebody had a vision. This has agreed to finance the resources and the people to do it. There has been a sign off and you are ready to go. A team has been assembled. Then needs to be some and it usually always is some formal start that goes on. That is what we call a lift off.
In order really to start the project right, we believe, you can do things like have activities in your lift off, performing skill development, a boot camp or some kind of team building. But chartering, actually that process in composes a lot of the team building work just in the act of doing it. In the specific to teams, besides understanding this alignment of purpose, there is also a larger alignment. That has to do with the team itself. Understanding what are working agreements, what are values and principles, who are we, what makes us up.
Those are the three things to go in the alignment element. Not all teams go through this working together to understand this. Sometimes teams often have working agreements, of course, and those are operational things, what is the definition of done. That is excellent work that could go on. But understanding values and principles that the team holds and the project community, actually. It really speaks to the beliefs and ideas about how the work is done itself. Just like the manifesto has some values and principles back it up. It is the principles that really talk about behavior. As I said it is different than working agreements.
A principle helps with decision making. If the team is stuck, say “How they are going to manage something or deal with a certain situation”? The principles are often there as guides. One of the principles that we used at HP in the Agile special interest group, in our work, was quality trumps expediency. That is the activity, even just having the team pull together to sit down and have a good discussion about values and principles. Helps align the team and the project community because everyone that has or shared an understanding of the work itself and how it is going to happen.
Can Liftoff Help With Organizational Change
Derek: I think a lot of people that come into teams do not realize how often an organization adapts something say Agile, Scrum, exTreme Programming (XP). Something that comes up front high, that we have seen in numbers of engagements.
We have been into where a management says the want to do a quote on quote the agile and to management that means that stuff is going to get done faster and it is going to cost less money and the quality is going to be up. Then you talk to the project manager or the product development team or somebody doing the work, and they think of it as, “Oh, we get to be self‑organizing, and we get to be empowered.”
We had talked to one customer or one client that when asked, “What are the goals of why you guys are even doing agile?” because they didn’t seem to want to actually embrace any of the agile principles or values. So we said, “Why are you even doing this?” Their answer was, “Well, because the CEO says that they want the agile implemented by the end of the year by all of the teams.”
So if I’m in a company and I’m faced with implementing the agile by the end of the year, is “Liftoff” something that can help me maybe get the business side of the fence. The CEO, the CIO, and the project management team or the product development team to share its principles, or is it strictly really just for teams themselves?
Ainsley: You could certainly do chartering at multiple levels. An adoption, an agile adoption is a project undertaking in and of itself. If people’s answer of why they’re doing it is because the CEO said so, that’s sounds like an adoption that’s going to have difficulty.
Ainsley: It sounds like there hasn’t been communication, and people haven’t actually sat down together to talk about much. The purpose itself of even the adoption isn’t clear. What was the vision for this? Because purpose is comprised of, as I said, vision, mission, and mission test.
I assume it’s some high‑level executive that made this decision. What was their vision for? What did they see as a result of this? Then what’s the mission of this particular work team that’s got a product to deliver? Then what are the tests?
How is this executive going to know or the executive team going to have any sense that this adoption has been successful if they haven’t even thought about that when they start? The team has no guidance.
Agile Adoption As A Project
Jade: I like what you said that agile adoption itself is a project. That’s a great way of thinking about it.
Applying the techniques and the process that you outline in the book would be fantastic for a company embracing agile for the first time ‑‑ learning scrum, whatever it is that they’re doing ‑‑ to move themselves towards agility. That would be a great way to help them understand what it is that they’re doing, why they’re doing it, and how they’re going to get there.
Ainsley: I agree because in a liftoff, say, for adoption, as I mentioned, you could do many things in a liftoff depending on what the intention is. So you could do some scrum training as part of the liftoff because ideally of course you have people together, physically together. Even though some parts of the team may be distributed, if they’re ever going to be together, it needs to be during the liftoff.
So you could get your training done in any other of that team building stuff as well as the chartering. Which helps the team form not just in a standard team‑building exercise way but in a much deeper way because of the things that we cover.
The fact that dealing with not just the purpose and alignment…We haven’t even talked about context yet, which is very critical and probably one of the pieces of chartering that’s…The impact of understanding context is probably the less recognized of the other two pieces that I’ve talked about. So you could really design your liftoff to cover a broad spectrum of things while everybody’s there physically together and leverage it to the absolute best.
Jade: Yeah, that’s great. I worked with a team recently, like I said, using a lot of these techniques, and when we talked about context and drew out the context map and diagram, it was fascinating.
All of the issues that have not been thought of, all the communication pathways we’re just assumed by certain people on the team, and other members of the team had no clue what they were talking about. It was an incredibly useful exercise that was really, really important for that core team.
Ainsley: I’m glad to hear that.
Jade: I found that very valuable.
Benefits Of Understanding Context
Ainsley: That’s great. That’s great. Understanding context is so important. It really helps define the limits. The boundaries so much depends on that that people make assumptions about it.
Jade: Yeah. We like to talk a lot as a company about restoring humanity and bringing more humanness back into the organization. As I was working with this team who was a newly formed team who had known each other for many, many years but had never really worked on a project like this, I took them through a lot of these exercises.
It went from a chore to something that was really enjoyable. Watching them gel as a team over the week that I was there coaching them, talking about shared values and principles was just a really incredible experience. I got a lot out of it. The team got an amazing amount of value out of it. It really set them off on the right foot. The project is moving forward, going strong, and I think a lot of it does have to do with that good solid foundation that they were able to start with.
Ainsley: I’m glad to hear. That fits with most of the experience we’ve had using these techniques. I must say hearing you talk about it, my guess is, because this is certainly what I hear from other people too, is that as you facilitate this, you can’t help but start to internalize some of it yourself and take a look maybe at how you think about things, “What are my values about work?” Things like that.
Doing the work itself and facilitating other people, I think, also adds value because you get a chance to reevaluate yourself, do iteration through yourself while you’re doing it.
Jade: Yeah, that’s great. Do you have a good story or a good experience that you could tell us of a successful liftoff that you’ve been a part of?
Ainsley: Mine are pretty old for what I was doing at HP. Diana has a very recent story, so it has used the techniques that we’re talking about here, specifically. What her undertaking was an adoption kind of situation. I can tell you that they had multiple teams because this was a very large project with a number of teams.
All the teams sat down, and did a basic charter for themselves. The scrum masters got some training individually about how to facilitate this. They all sat together in one large place as a group, and did their chartering, each team.
And then got together afterward, and did a discussion about what each team had done, and how they compared and contrasted with each other. This was in a very large company, and it’s gone on. They are continuing on this project, and it’s been successful so far. That’s kind of an adoption story.
Applying Liftoff To An Existing Team/Project
Jade: What do you think about if we have a team that’s already been formed, we’ve already been moving forward on such‑and‑such a product or project? How does the advice and the techniques from your book come into play for a team that’s already halfway down the road on this project?
Ainsley: In a way, every time, as with many other things in Agile, anytime there’s new information, the charter needs to be updated. It’s a living document, once you’ve created your charter at the beginning, it’s an initial pass. The assumption is it will be updated whenever there’s new information.
So as you’re working through, as with working agreements, once you’ve got them down and useful, you usually roll one out and bring in a new one, right? Because you have to remember it, it goes up in your big, visible chart.
The same is true with the values and principles, or with anything else in the charter. Your context diagram changes, at least that’s been my experience, as work goes on. You wind up working with new people in different ways, the exchanges are different. Whenever there’s any kind of flow change, you want to change that context diagram as well.
Jade: If I have a team that…Let’s say we didn’t go through this at the beginning of our project, do you think we could at some point…Say we don’t have the vision, and mission, and mission tests, do you think it would be a good idea to stop and go through a lot of these exercises to get a better understanding of the project?
Ainsley: Absolutely, absolutely. Pretty much any time you see a place where there isn’t alignment, say between the core team and parts of the project community, or even within the core team itself, about the project work, you can go back to take a look at the alignment part of this model.
Also, you can re‑charter whenever it’s needed. In the same way people use retrospectives…There are retrospectives that you do on a rhythm basis at the end of an iteration or at the end of a release, there’s no reason you can’t do chartering or work on the elements of the charter whenever there’s a need.
It doesn’t have to be on a rhythm, but when something comes up that you need to deal with. It’s not just for the beginning of the project, it’s when the need arises.
Jade: That’s great. I think that’s really good advice to teams who maybe even if they did start off on the right foot, and have found themselves in a place where they’re just not getting along, or something’s going wrong. Always reevaluate everything that you’ve got, and take a look and try to identify where there’s an issue.
Ainsley: It just has to do with being agile. If there’s new information, did something change? What’s the best way to deal with it? Often that takes you back to looking at pieces of the charter.
Chartering Doesn’t Mean Documentation
Jade: As we’re wrapping up here, I’ve got one more question for you. What do you think will be the hardest thing for people to swallow from your book? What’s going to be the hardest technique or piece of advice that you’re giving them?
Ainsley: [laughs] I haven’t thought about what’s the hardest thing. My experiences is that every group has different people that…And the variety of people each have their own issues with certain parts. So a single part, I don’t know. I think there’s often a misconception which we try and dispel all the time.
The chartering means documentation, so that could be very off‑putting or difficult. However, this is really a limited documentation piece of work, and when we do talk about documentation, it’s often, or mostly actually, things that go up on big, visible charts. We’ve tried to keep it in line.
I think things having to do with communication and trust, especially if it’s a new team, could make this difficult, but that doesn’t make this process any different than any other kind of communication.
Jade: That’s great. When can we see this book? When’s it going to be out for everybody to read?
Ainsley: We’re looking at next month at this point. We’re working on some cover art, and a couple of other publishing level things. We’re, right now, looking at next month.
Jade: Where are people going to be able to find it?
Ainsley: The publisher is called Onyx Neon Press, and they’re in Portland.
Jade: How’s it going to be available? PDF?
Ainsley: Right now, we’ll probably have some kind of…I don’t know what format it’s going to be, but some kind of non‑paper version.
Jade: So Onyx Neon, you said?
Jade: All right. Well, thank you so much, Ainsley, for you time and for coming on the show with us.
Ainsley: You’re very welcome. It was good talking to you, and it was great to hear that you’ve been using this successfully.
Jade: Yeah, it’s been great. I can’t wait for the book to get out, and for more people to take a look at it and give it a try.
Jade: Awesome. Well, thanks, and we’ll talk to everyone next time.
Derek: Have a great one.
Ainsley: Bye, bye…
How Management Changes with Agile with Esther Derby
The Agile Weekly Crew and Esther Derby discuss the role of managers, management models and who makes decisions.
August 01, 2012
Extreme Programing (XP) Practices with Arlo Belshee
The Agile Weekly Crew and Arlo Belshee discuss XP practices, software craftmanship, pair programming and test driven development.
July 18, 2012
Managing Your Job Search with Johanna Rothman
The Agile Weekly Crew and Johanna Rothman discuss personal kanban for job search, decomposition of work, collecting feedback and holding yourself accountable.
June 07, 2012
Personal Kanban with Gerry Kirk
The Agile Weekly Crew and Gerry Kirk discuss personal kanban.
May 03, 2012