Liftoff: Launching Agile Teams and Projects, with Ainsley Nies

Episode 36

November 30, 2011

26:18

Interviews

interviews

The Agile Weekly Crew and Ainsley Nies discuss the book Liftoff: Launching Agile Teams and Projects

Episode Notes

Ainsley Nies joins Jade Meskill, Derek Neighbors and Roy van de Water in discussing the book “Liftoff: Launching Agile Teams & Projects”, which Ainsley co-authored with Diana Larsen.

Formallizing the start of a project or team

Chartering a team increases the communication

Helps align the team around the project vision

Transcript

Jade Meskill:  Hello, and thank you for listening to another episode of the Scrum Cast. I am Jade Meskill.

Roy van de Water:  I am Roy Van de Water.

Derek Neighbors:  I am Derek Neighbors.

Jade:  We have with us a special guest today, Ainsley Nies.

Ainsley Nies:  Hello. [laughs]

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.

Jade:  OK. Awesome. What was your motivation for writing this book?

Ainsley:  Well, both Diane 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, Diane 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.

Ainsley:  Wonderful.

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.

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.

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.

Derek:  I think a lot of people that come into teams do not realize how often an organization adapts something say Agile, Scrum 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.

[laughter]

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.

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 dependin

Related episodes