Skip to content

Getting Agile Right

Saturday, November 5, 2011, posted by

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.

Filed in Agile, Presentations | | Comments (0)

Admitting that you have a problem

Saturday, March 12, 2011, posted by

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.


Filed in Project Management, Software Development | | Comments (0)

Confessions of a jerk

Sunday, January 9, 2011, posted by

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?)

Filed in Careers | | Comments (0)

Demoralize Your Teams Quickly And Efficiently With Micromanagement

Monday, November 29, 2010, posted by

Apparently I’ve earned the dubious distinction of having become an expert in project failure. I’ve always had an interest in project failure—Jenny and I have been doing our “Why Projects Fail” talk for years now, and we’ve talked to many people in many different industries (like in our fourth book, Beautiful Teams) about what’s gone wrong on their projects. We’ve looked at failures on projects through the years, from small misfires on our own projects to dramatic failures like the Tacoma Narrows Bridge disaster, to try to figure out what software developers can learn from them.

One of my favorite ways that projects can fail is death by micromanagement. It’s a nasty, insidious problem for a couple of reasons. It’s easy for a boss to fall into the micromanagement trap, especially for a project that’s starting to spiral out of control, because when you feel like your project is slipping away from you, it’s hard to resist the urge to tighten your grip on every part of it that you can.

And the people on the team have trouble recognizing it because a lot of them have never worked any other way. I’ve said it before, and I’m sure I’ll say it again: I’m willing to bet that if someone was able to conduct an accurate survey, they would find that a surprisingly large number of managers are micromanagers.

On the other hand, if you’re a boss or a project manager looking for a great way to demoralize your team and cause your projects to fail, micromanagement is a great way to do it. Here are some handy tips to make sure your team hates you and your project runs into serious trouble:

  • Make sure you don’t give your team enough time to do the work, and then blame them for not getting it done on time.
  • Routinely ask people to stop working on whatever they’re doing right now to take care of urgent emergency work.
  • Then utterly fail to follow up on that urgent emergency work.
  • Never let anyone on your team release anything or even talk to a user without giving it to you to look over first.
  • When they give you that work, make sure you send it back with a whole lot of vague and poorly thought-out changes – but make sure you don’t give any extra time to make them.
  • In fact, try to constantly find many small changes that your team should make, just to keep them on their toes.
  • Your team needs constant attention! If it’s been more than two hours since you’ve talked to someone on your team, drop by and tap one of them on the shoulder and ask for an update.
  • All organizations run on status. If the status updates stop flowing, a company can crumble and perish! Also, developers feel lonely if they haven’t given a status update in the last few hours. So make sure everyone has to fill out elaborate status reports, and make sure you hold at least three two-hour-long status meetings every week.
  • Did someone on your team do something differently than how you would do it? Reprimand them! They might tell you that it works just fine, and that their way is just as good. But it’s not your way, so it’s not right.
  • Remember: reading your mind is part of every team member’s job. That’s how they stay proactive!

Most of all, though, remember rule #1: Nobody is ever allowed to make mistakes! If a developer makes a mistake, it reflects badly on you, and the whole team suffers. Never admit that you were wrong about anything. If you said it once, it’s now the law and should never be questioned.

If you follow this simple advice, then your team will be demoralized in no time. Also, they’ll hate you. Oddly, though, there’s a good chance that they won’t get their resumes together and start looking for new jobs. I have a theory about this: when you micromanage a team, it drains their will to such an extent that they no longer care. Psychologists call this state “learned helplessness.”  The Wikipedia article on learned helplessness has a good description of a classic experiment by Martin Seligman and Steve Maier:

In part one of Seligman and Steve Maier‘s experiment, three groups of dogs were placed in harnesses. Group One dogs were simply put in the harnesses for a period of time and later released. Groups Two and Three consisted of “yoked pairs.” A dog in Group 2 would be intentionally subjected to pain by being given electric shocks, which the dog could end by pressing a lever. A Group 3 dog was wired in parallel with a Group 2 dog, receiving shocks of identical intensity and duration, but his lever didn’t stop the electric shocks. To a dog in Group 3, it seemed that the shock ended at random, because it was his paired dog in Group 2 that was causing it to stop. For Group 3 dogs, the shock was apparently “inescapable.” Group 1 and Group 2 dogs quickly recovered from the experience, but Group 3 dogs learned to be helpless, and exhibited symptoms similar to chronic clinical depression.

In part two of the Seligman and Maier experiment, these three groups of dogs were tested in a shuttle-box apparatus, in which the dogs could escape electric shocks by jumping over a low partition. For the most part, the Group 3 dogs, who had previously “learned” that nothing they did had any effect on the shocks, simply lay down passively and whined. Even though they could have easily escaped the shocks, the dogs didn’t try.

If reading about the Group 3 dogs reminds you of work, then there’s a very good chance that you’re being micromanaged.

Filed in Project Management, Teams | | Comments (0)

Inflict bad UX on users you secretly hate

Saturday, November 20, 2010, posted by

About a year ago at a conference, a programmer came up to me for some advice about an unfortunate user interface he’d built. It was a pretty miserable affair: a combination of displaying too much information and offering too many choices, while at the same time burying the one thing that the user actually wanted to work with. It was full of classic UX – user experience – mistakes and usability problem, and I suggested the usual suspects: go back to user stories, develop some use cases, try to figure out what the users actually need.

That did not go over well. I’d assumed that the programmer was still working on gathering feedback, since he was asking me to look over his design. So I was surprised when he mentioned that it would be difficult to make changes to it, because it had already been rolled out and his users were using it.

That’s when I decided that this was a devious supervillian who secretly hated his users. Or, possibly, just a thoughtless jerk—I couldn’t really decide for certain without seeing his secret lair. (Hint: If he has a secret lair, it’s probably the former.)

My point is that if he did hate his users, then inflicting bad UX on them was a perfect way to make them really miserable.

You can’t just add usability at the end of the project

You’d be surprised at how often programmers are completely unaware that they have serious UX and usability problems. Just a few days ago, someone told me, “Our users are using our software, so we don’t have any usability issues!”

One of my favorite sayings is that there are only a few ways to do something right, but a million ways to do it wrong. Usability is no exception. And one problem with user experience and usability is that it’s not always easy to diagnose UX problems in software that you wrote. Good UX is designed in from the beginning; bad UX can show up at any point along your project.

That’s why an approach that I like for fixing usability problems is to concentrate on the team, not just the software. Here are a few quick questions to ask yourself. If any of these situations sound familiar, you might have usability problems:

  • A user is explaining what he needs you to build. Halfway through a sentence, you stop him and say, “That’s great! I know exactly what you need.”
  • The first thing you did on your new project was start up the form or page designer in an IDE and drag controls onto a window—before talking to any of the users.
  • You’ve gotten halfway thorough a project without knowing the name of anyone outside of the programming team who’s going to use the software.
  • When you deliver the first version of the software for users to test, it’s the first time they’ve seen the GUI.
  • You find out that there’s an entire feature that your users aren’t using… or a feature they don’t even know about.

If any of that sounds familiar—or, even worse, if you’re now pissed off at me because you don’t see what’s wrong with any of those scenarios—then you should definitely consider getting some UX help right now. (I’d offer to help you myself, but I’ve got my hands full with my own projects!)

One of these days I’m going to start an organization called PeTU: Programmers for the Ethical Treatment of Users. We’ll set up a protest outside the office of any development team that inflicts bad usability on their unsuspecting users. For the sake of all our sanity, please stop inflicting bad UI on unsuspecting users! If you don’t, I’ll have to stage an outlandish, somewhat juvenile protest outside your office.

Filed in Usabililty / UX, Users | | Comments (0)