Getting Agile Right

~ Andrew Stellman ~ Leave a comment

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.

Admitting that you have a problem

~ Andrew Stellman ~ 2 Comments

It’s not always easy to recognize when your project is in trouble. Yes, if your project crashes and burns and completely fails to deliver, it’s failed. But sometimes you don’t realize that you’ve  or you’ve built the wrong software and are about to make your users very unhappy. That’s why Jenny and I put together our Why Projects Fail talk [pdf] a few years ago: to help people recognize when their projects are starting to go off the rails, and learn a few simple techniques for fixing them. If you learn to recognize the signs of project problems, it’s easier to take action quickly and turn your project around:

Software projects are a lot like cheesy horror movies. After you’ve seen a few of them, you know that the first guy to leave the group is going to get an axe in his head. Projects are the same way. People keep making the same mistakes over and over, and it keeps getting their projects killed.

– Why Projects Fail presentation, slide 6

But what happens when your problems are bigger than just one project? What happens when you’ve got a team, a department, or a whole organization that runs into trouble repeatedly on projects?

When Jenny and I were doing research for our first book, Applied Software Project Management (O’Reilly, 2005), we talked to many different people on all kinds of teams. And when we did, we started to notice something funny. We specifically reached out to people who had bad experiences with requirements, project management, Agile development—really, any way of trying to do things better. We were surprised that we kept hearing the same things over and over again, and started to suspect that they were symptoms of deep-rooted project management problems… and teams that were resistant to changing them.

Taking the first step

A list of the most common excuses—excuses that we’ve heard dozens or even hundreds of times, over and over again, from many different teams—is a surprisingly powerful tool. There have been many times when I’ve been brought in to try to help a team improve the way they build software. I’d be in the middle of an explanation of, say, why Agile has worked well for me in the past, and someone would give me an excuse that’s almost exactly word-for-word right out of our book. It’s actually pretty uncanny: how were we able to predict exactly what he would say in advance? But there it is, written down and printed in black and white.

That was the inspiration for the chapter in our book called Understanding Change. In it, we outline the most common excuses for sticking with a poor way of building software and not adopting something better. If you’ve ever tried to help your software team adopt a new tool, technique, or practice, you’ll see some very familiar arguments there.

Here are the top excuses that we’ve heard from teams that can’t admit that they have a problem. They’re all straight out of Applied Software Project Management. Treat each of these excuses as a big red flag, and you can use this to your advantage. If you’ve ever watched an episode of Intervention, you probably know that the first step to fixing a serious issue is admitting that you have a problem. Do they sound familiar to you? Have you ever heard any of them before? If so, it’s time to take the first step.

But if you do take the step and admit that you have project problems, that’s good news! It means that there are plenty of time-tested, tried-and-true ways to help your team. (Of course, if you’re a regular reader of Building Better Software, you already know that!)

Each of the following excuses is excerpted from pages 206 through 213 of Applied Software Project Management (Stellman A and Greene J, O’Reilly 2005). You can read a lot more about each one (and what you can do when you hear them from your team) in that chapter.

We Already Build Software Well

Denial is a common response to change. You may have identified a glaring problem, but people around you fail to even recognize it (or simply refuse to acknowledge it). Many professional software engineers and managers have never experienced a project that did not have enormous delays and serious problems; it’s often assumed that this is just part of how software is built. After all, they usually delivered something—most projects were eventually completed, and the software they built is now being used. Sure, some projects seem to always be eternally 90% done (with 90% left to go), but most of them seem to get something onto the users’ desktops (although many patches and bug fixes needed to be rolled out afterward). Isn’t that good enough?

“Not Invented Here” Syndrome

“Not Invented Here” syndrome (NIH syndrome) is a name given to a common type of organizational culture where people intentionally avoid research or innovations that were not developed within the organization. When faced with a problem, the people in the organization will typically reject a solution that is known to have worked elsewhere in the industry, solely on the grounds that it did not originate from inside the organization. They opt instead to build their own solution, often at far greater cost.

It’s “Too Theoretical”

When an idea does not make intuitive sense, many people will dismiss it as a result of “academic research,” which could not possibly apply to the world they live in. For example, to someone without a project management or software  engineering background, it may not be immediately obvious that reviews reduce defects, or that it’s important to write a specification before building software. To him, these procedures are time-consuming, with no obvious benefit. They sound good in a book, but would never work in the organization. In other words, they are “too theoretical.”

It Just Adds More Bureaucracy

An especially damaging attitude in some organizations holds that programming is the only important activity in a software project. Project management tools and techniques are seen as distractions that drain energy and effort away from the programmers’ “real job” of writing code. Any project activity that takes place before the programmers begin writing code simply amounts to “spinning our wheels,” and the goal of all early project activities should be to get the programmers doing the “real work” as quickly as possible.

You Can’t Give Me More Work!

Most of the changes that a project manager makes will increase the workload of other people. Software engineers, managers, and stakeholders who were not directly involved in building software will suddenly find themselves expected to attend status and review meetings, participate in planning and estimation activities, work with someone creating a vision and scope document or eliciting requirements, or perform other tasks that were never expected of them before. If you are making these changes, then you are the person piling additional work onto someone’s already overflowing plate. Not surprisingly, there are people who will not be happy with this arrangement.

It’s Too Risky

The economist John Maynard Keynes once wrote, “Worldly wisdom teaches that it is better for the reputation to fail conventionally than to succeed unconventionally.“ Legendary investor Warren Buffett put it this way: “Lemmings as a class may be derided but never does an individual lemming get criticized.” In other words, any manager who backs a change puts his reputation on the line; if that manager does nothing, he will not be criticized for maintaining the status quo.


Confessions of a jerk

~ Andrew Stellman ~ Leave a comment

The worst kind of jackass is the kind that knows he's good

The other day I made this short, shameful confession in response to a Slashdot story about a Forbes blog post called When Smart People are Bad Employees. The post outlines three distinct types of bad employees. The third one was called “The Jerk,” and it sounded eerily familiar:

If a member of your staff is a raging jerk, it may be impossible. Some people are so belligerent in their communication style that people just stop talking when they are in the room. If every time anyone brings up an issue with the marketing organization, the VP of marketing jumps down their throat, then guess what topic will never come up? This behavior can become so bad that nobody brings up any topic when the jerk is in the room.

Here’s my confession: I’ve been that jerk in the past.

I was that really smart programmer that everyone listened to because I made really good software really quickly. But people hated dealing with me because I was obnoxious to deal with—and worse, I knew it and was openly arrogant about it. If snarky geek t-shirts had been around at the time (this was back in the mid-90s) I would definitely have worn them. When someone was wrong, I definitely let them know. If I didn’t respect someone, I would make myself unpleasant to deal with, enough so that it was easiest to just shut up anytime I was in the room.

I was a kid in my early 20s, and it was only my second job out of college, so I was really eager to prove myself. I came up with some pretty ingenious solutions to a couple of vexing problems. It was a small company, and one of the systems I built produced an entirely new product for their salespeople to sell to clients. They had some serious problems managing client information for their help desk, serious problems where their programming team wasn’t able to track bugs properly (these were the days well before tools like JIRA and Bugzilla were cheap or free), and managing large amounts of data. I built some pretty good tools, and they made a big difference. So people put up with my attitude, because it was a net win for everyone. But it made their jobs more difficult, just so I could engage in some personal ego gratification.

Actually, here’s something from that time that I find really funny. The company I was working for had all prospective employees take a Caliper Assessment test as part of the interview process. At the time, it was basically a combination of an IQ  (abstract reasoning) test and a personality profile, and the results were compiled into a report with a page of scores and a two-page writeup. My boss gave me a copy of my results when I came on board. My abstract reasoning score was 100%, and scores on the “extroverted” and “ego-driven” scales were both over 90%. The writeup said that I would be “a loose cannon,” but if I was “aimed properly, I would knock down any barrier in front of me.” It also warned that I would not play nice with people who I did not respect.

In other words, the Caliper report certified me as an extremely smart, highly capable, grade-A jerk.

So, first of all, kudos to the folks at Caliper. They definitely had my number, which was pretty impressive considering that it was based on a 100-or-so-question fill-in-the-bubble timed test. And they got that profile exactly right.

This all presented a really frustrating problem for the people at the company. Here I was, this kid who kept hitting projects out of the park. But I was truly impossible to deal with. I would barely let people finish sentences before cutting them off (“Okay, I know exactly what you want. You go away now.”) I perfected all of the programmer stonewalling tricks to get people to stop asking me questions: interrupting people with pedantic questions before they’d barely started getting to the point, sending people back with half-answers so I didn’t have to think through the question I was being asked, answering questions in a way that was obviously far too technical for whoever I was talking to so. And heaven help anyone who said something to me that was technically inaccurate.

I was belligerent to people around me. I was definitely immature and naïve. But people respected me and knew that I was worth dealing with, because I did really good work.

Eventually, though, a funny thing happened.

I slowly discovered that if I stopped acting like a jerk, life got a lot easier. I mean, obviously, it got easier for the people around me. But it got easier for me, too.

Unthinkingly, I felt that I needed to be a jerk to make people respect me. I think, on an intuitive level, that it was a kind of litmus test. People had to respect me, because if they didn’t respect me they never would have put up with my attitude. But what I found was that when I stopped acting like a jerk, people still respected me. Not only did they stop fighting me, but they actually went out of their way to help me.

Once I stopped being a jerk, it was a lot easier to do my job, and I’m convinced that I was actually able to produce better code because of the reduced number of bureaucratic headaches.

I wish I’d figured it out earlier.

(Hmm, on the other hand, I was asked to do more stuff because people were less afraid of me. So I guess… be careful what you wish for?)