Last week Jenny and I gave our new talk, Getting Agile Right [pdf], for the first time. We’re really excited, because it also marks our first public announcement of our current book project for  O’Reilly: a new book about agile development and project management. It’s aimed at people preparing for the PMI-ACP certification, but our goal is to help anyone who’s interested in agile really understand the ideas behind it.

We talk to a lot of teams and help  them understand what’s gone right and wrong with their projects, and look for common patterns of project problems and failure (that’s what our Why Projects Fail talk [pdf] is all about.) People starting with agile often us about something that we call “better-than-not-doing-it results.” Basically, they adopt a bunch of great agile practices, and they see a clear improvement. It was definitely worth going agile, but something feels a little hollow about it. They were expecting the “astonishing results” and “hyper-productive teams” that they’d read about in agile books and blog posts, but there’s a feeling that at its core, the team hasn’t really changed how they do things, they just made incremental improvements.

I recently read Lyssa Adkins’ excellent book, Coaching Agile Teams, and one of the really insightful things she points out is that “metaphor is a powerful thing.” Jenny and I put a lot of thought into coming up with a good metaphor to help explain what’s going on. We hit on a really good one: the story of the blind men and the elephant. I like the Jain version of the story (from Wikipedia):

A Jain version of the story says that six blind men were asked to determine what an elephant looked like by feeling different parts of the elephant’s body. The blind man who feels a leg says the elephant is like a pillar; the one who feels the tail says the elephant is like a rope; the one who feels the trunk says the elephant is like a tree branch; the one who feels the ear says the elephant is like a hand fan; the one who feels the belly says the elephant is like a wall; and the one who feels the tusk says the elephant is like a solid pipe.

A king explains to them: ”All of you are right. The reason every one of you is telling it differently is because each one of you touched the different part of the elephant. So, actually the elephant has all the features you mentioned.”

So what does this have to do with agile teams having trouble getting past better-than-not-doing-it results?

Teams that get better-than-not-doing-it results from agile are often the ones who were already able to get software out the door reasonably well before starting with agile, and were hoping that agile adoption would help them get a real improvement. The problem is that before the team started adopting agile practices, they were experiencing problems—not the serious, software crisis problems that caused their projects to fail outright, but problems that caused friction and discomfort on the team. The source of these problems is something that we call a “fractured perspective”: the developers think about developer stuff, project managers think about project manager stuff, and they throw the code over the wall to a business user who thinks about business stuff. Everyone is really busy thinking about his or her own project work. There isn’t a lot of communication between people, and they’re really functioning as individuals working separately towards compatible goals, not as a team.

That’s where the Blind Men and the Elephant story comes in—it’s a good metaphor for how a team with a fractured perspective adopts agile. Each person sees the practices that impact his or her work. Developers concentrate on, say, test-driven development, refactoring, and automated builds. Project managers like task boards, project velocity, and burndown charts. Business users use release planning and user stories to get a better grasp on what the team is doing. Team leads use daily standups and retrospectives to manage and improve the team. Everybody wants something different from the project, and they each see a few practices that do something specific to help them.

And that’s definitely going to improve things, because agile practices are generally really good. The problem is that since everyone—developers, project managers, business users, and team leads—sees the project from a different perspective, they’ll concentrate on only those practices that immediately appeal to them. There’s a paradoxical effect (we call it, “See! I was right all along”) where each person now sees only the part of agile that affects his specific project work, and draws the conclusion that agile is all about getting everyone else to come around to his point of view.

But agile is more than just practices. In fact, that’s one of the core ideas behind agile: principles over practices. So while the agile “elephant” is made up of many great practices, the whole thing is greater than the sum of the parts. And if you only see practices—especially if you’re only looking at the practices that directly affect your project work—then you’ll only see one small piece of agile. The “elephant” of agile is made up of the practices day to day, but it’s much bigger than just those practices.

A team whose members only see the practices and don’t think about the principles will miss out on the important interactions between people. Their perspective stays fractured, and they stay separate and don’t really function as an effective team. They’ll still get their work done, but they miss out on the great team interactions and collaboration that make agile really work.

This is built into agile. If it’s been a while since you’ve had a look at the agile manifesto, open it up again and have a look at the very first value:

Individuals and interactions over processes and tools

Processes, methodologies, and tools are still important (“…while there is value in the items on the right, we value the items on the left more.”). But even more important than specific practices are the individuals and interactions. It’s these values, and the twelve principles, that show us how the practices work together, and serve as a guide for how teams adopt those practices.

That’s one of the lessons of our “Getting Agile Right” talk [pdf]. It’s also going to be one of the big themes in our upcoming book, due out from O’Reilly next year, about agile development, project management, and the new PMI-ACP agile certification. We’ll continue to make posts to help connect these dots and learn more about agile.

We unveiled a new talk on Tuesday at Boston SPIN! We love Boston audiences/ We met some great people (hi Abby!), and things went really well. As promised, here’s a PDF of the slide deck.

We were especially pleased to finally meet Johanna Rothman in person. She was our first Beautiful Teams contributor — we’d spent plenty of time on the phone with her, but we’d never met in real life. She made a special cameo appearance, and told her story from the book!

Thanks again to everyone who attended and gave us such a warm welcome.

We’ve been keeping ourselves busy! What’s that? You want to know more? Well, certainly. We’ve got lots of news:

• Jenny and I are doing some guest blogging on the Head First Labs website, talking about what it’s like writing a Head First book (and whatever else we feel like talking about). I’ll be doing the posts this week, starting with one called “How We Made Head First C# Different”. I’ll probably get a little more technical near the end of the week — there’s only so much anyone wants to read about writing books. (Or is there?)
• We’ve put up a new training page, because we’ve been getting a lot of questions about training. It’s a list of the various courses we offer on project management and software development. Right now, we’re mainly concentrating on training corporate teams — we’ll go into a company and do a few days of training for a team. We’ve been getting an increasing number of inquiries about putting together classes that are open to the public, though. If you’re interested in that, please drop us a note using our contacts page and we’ll let you know the next time we’re offering one.
• Last week we were invited to do our “Why Projects Fail” talk for the PMINYC Breakfast Roundtable. After the talk, one of the audience members came up to me to thank us for doing a presentation that wasn’t boring. I thought that was pretty cool! Anyway, here are the slides from the talk.
• We’ve been doing our “Why Projects Fail” talk at companies around town. If you work at a company in New York City and want some insight into why projects fail, you’ve got a brown-bag lunch program (or some other kind of program where your company brings speakers in to do a talk), and you can get a reasonably-sized audience together, get in touch with us — we’re usually happy to come in and do it as part of our New York outreach program. It’s generally pretty fun, and a good way to take your mind off of the job for an hour.

We had a great time presenting at a NYC SPIN meeting on Tuesday — it was a joint gig with the PMINYC chapter, and we had a great crowd. We got a lot of great questions, which is always great. As promised, here’s a PDF of the slides. If anyone’s got any questions, feel free to contact us.

Hey, we’re super-busy, so I’ll have to keep this short and sweet. But Jenny and I have some news, and we wanted to share it with you.

1. We’re in the home stretch on Head First C#. We should be done with the manuscript in the next couple of weeks, which means that it should be in stores sometime in November (if we understand the production schedule correctly).
2. We’re doing a talk tomorrow at a NYC SPIN / PMINYC meeting. It’s a variant of our “Why Projects Fail” talk — we’ve been getting a lot of great feedback about it, so it should be fun. Unfortunately, registration has closed for it — it’s sold out — but we’ll post slides afterwards.
3. There was just a great article published on Inc. Magazine’s technology site that quotes us pretty extensively. We had a good talk with the author, Renee Oricchio, and she really got a good sense of what we were saying. It’s called “Getting In-house Software Shops Back on Track”.

Sorry about the quick update – we know we’re phoning it in, but we’ll be more chatty once the book’s out the door.

Here’s a PDF of the slides from the talk. The fourth slide is this video of the 1940 Tacoma Narrows Bridge disaster. And to anyone who attended, we’re always happy to answer questions — feel free to get in touch with us if you want to follow up on anything we spoke about.

We promised to upload the slides and post a couple of links, so here they are. Here’s the PowerPoint presentation [PPT] and a PDF version [PDF].You guys asked great questions — some of the best we’ve ever gotten at one of our talks. Here are a few of the answers that we promised:

• A few of you had questions about estimation, specifically the Wideband Delphi process that we’ve had a lot of success with. You can read about it in Chapter 3 of our first book, Applied Software Project Management– here’s a link to a PDF of the chapter [PDF]. We give a pretty detailed description of exactly how to hold a Wideband Delphi meeting, and how you can use it on your own projects to improve how they’re estimated.
• One person brought up a really good point about integration, and how that’s an important failure point that gets neglected, and we mentioned that we’d post a link to an article we wrote for Dr. Dobb’s Journal on integration testing called “Better, Stronger, Faster Integration Testing: Giving developers a personal stake in software quality.”
• I think a lot of the questions near the end of the talk about open source projects were answered in our ONLamp.com article called “What Corporate Projects Should Learn from Open Source”. Also, here’s a link to the “What Makes Open Source Projects Work” presentation I gave last January at the SD Best Practices India 2007 conference.
• No, we don’t have an official release date for “Head First C#” yet, but we’re definitely making good progress on it. Keep watching this blog — as soon as O’Reilly has an official release date for it, we’ll post about it. And yes, it is really fun to write a Head First book.
• After the talk, a few people asked about our availability to come in and do training. Our consulting schedule is a little tight because of our pretty aggressive writing schedule for O’Reilly, but we do have some availability. You can use our “Contact Us” page to get in touch with us about consulting and speaking — serious inquiries only, please.

We’re always happy to answer questions about anything we talk or write about. Feel free to get in touch with us any time!