Getting Agile Right

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.

Our new “Beautiful Teams” talk at Boston SPIN

Andrew and Jenny at Boston SPIN

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.

Beautiful Teams Slide

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!

Special guest apparance by JR

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

Speaking, training and writing

Training saves your kneecaps

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.

2007-10-09 presentation screenshot