It's an old story. Those of us who are techies cave in to the marketing guys, managers - the business side - because we don't know how to push back. As a result, developers are seen as negative and resistant by the business guys and the business guys are labeled clueless or even 'lying' by developers. It’s an on-going war of ‘Us against Them.’ Linda Rising suggest a basic misunderstanding may underlie this problem, because the business guys more often use numbers to make decisions about people and teams, while developers use numbers primarily for computation.
Is there no hope of reconciliation? Linda's answer is "Yes!" -- with a little coaching, developers can learn just enough business-speak to get their point across and bridge that gap. As the "Spirit of Agile" points out in this story, the trick lies in turning non-computational problems and issues into number-language that is helpful for decision-making.
Rick saw them coming out of the corner of his eye. He wanted to run away, hide under the desk, escape somehow, but it was too late. They were both in his cube, standing over him—Jim, his team lead, and Sam, their marketing guy.
"Hi, Rick!" said Sam. "You're just the guy who can help us. We've got a new customer who's really interested in our Framits. Thing is, he just needs the Whatsis module and he needs it sooner than our current customer. He's willing to pay us a bonus if we can get it to him by the end of the month. I know that's pushing you, but you've always come through in the past under pressure. Whadya say? Can you help us out? It means a lot to the company, our third quarter isn't lookin' too good right now."
Rick shifted uneasily. Caught like a rat in a trap. He couldn't even make eye contact and Jim wasn't helping. Rick knew that Jim was being coerced, too. It wasn't that this wheeling and dealing hadn't happened before. But Rick had somehow believed that since the team had gone "agile" that things would change. But they hadn't. These guys were still playing their old games. All he could say was, "I'm not sure I can make that deadline. I mean, the end of the month, well, there's a lot to do on that module and I haven't even done enough to know what the problems will be. I think…"
"Sure, Rick, sure," said Sam. "You developers are all the same. Where's your 'can do' attitude? Listen, I think I heard there's a bonus for overtime if you're willing to work weekends."
"It's not the money, Sam," protested Rick. "I just don't know. I'm not sure how long it will take, but…"
"But, what, Rick?" Sam jumped in. "Throw some numbers at us! Let's talk! I don't have time to hear the same ol', same ol', I'm going to get back to this customer and say it's a deal." Sam walked off.
Jim stood there and looked at Rick with a helpless expression on his face. "Sorry, Rick. I'm new at this "agile" stuff. I didn't know what to tell those marketing guys. And you know how it is. The customer. The customer. Say, that's part of agile, right? The customer?"
Rick nodded, "I guess."
"I'll talk to you later," Jim gave a half-hearted wave and left.
Rick sat there with his head in his hands. He wanted the company to do well. He wanted people to think he was a "team player" and ready to do his part. He felt stonewalled. He was telling the truth. He really didn't know much about that module…yet. There were some story cards but no one had really started working on them. Suddenly he heard a noise. He started. There it was again. He looked around and saw. Actually, he wasn't sure what he was seeing, some kind of apparition, and it was giggling!
"Who, what the heck are you?" Rick whispered.
"Shhhh, people will think you're talking to yourself!" the ghostly figure smiled. "I'm here to help. You're not seeing things or maybe you are!"
"What do you mean, 'you're here to help'?" Rick stared. "What are you and what are you doing in my cube?"
"It's OK, Rick," the apparition was suddenly serious. "You've got a big problem and it's something a lot of developers struggle with, so I decided to step in. If I can help you, then maybe you can spread the word to others. I don't have time to do it all. Even though I'm really agile!" The apparition giggled again.
Seeing Rick's puzzled face, the apparition nodded and said, "Let me first introduce myself. I'm the Spirit of Agile. I'm what "agile" of any flavor is all about. I don't care if you're doing XP or Scrum or, as Gary McGraw says, 'slaughtering goats,' love that 'slaughtering goats'—it's a joke, get it?" The spirit was doubled over but Rick just shook his head.
The spirit cleared his throat and continued, "I see this all the time. Developers caving in to marketing guys, managers—the business side. The developers perceived as negative and resistant by the business guys and the business guys labeled as clueless and lying by developers. It's an on-going war. 'Us against Them' with no hope of reconciliation."
"Yep," agreed Rick. "You're right about that. Those guys are clueless. They throw around dates and numbers and it doesn't matter to them that they don't mean a thing. If guys on my team put numbers on the table, we mean it. Numbers have to make sense, not like those business guys!"
"That's the problem," said the spirit. "You've hit the proverbial nail with the proverbial logical hammer. The developers believe that numbers mean one thing and the business side believes that numbers mean something else."
"Wait!" Rick raised his voice and then jumped up and looked down the corridor. He was OK. No one had heard him or if they had they just thought he was talking to himself again. "Numbers mean what numbers mean," Rick shook his fist in the air. "You can't say that a number, like 2, can mean one thing to one person and something else to another. That's nonsense! Numbers are numbers are…"
"Hold on," interrupted the spirit. "Give me a chance. Let's look at an example. When I use a word in a language we both know, I assume that you know what I mean and then we can have a conversation, right?"
"Right!" said Rick. "That's just it! Words make sense just like numbers make sense. Otherwise we end up saying what we think is the same thing - but meaning different things."
"But, surely, you've had times when you've said something and someone has mis-understood your meaning? When you and someone else were using the same words but intending different interpretations?"
"Yeah, you're right," Rick agreed. "It happens all the time. Half of what I say around here is mis-interpreted, especially about deadlines."
"I'd like to return to something you said earlier, Rick," and the spirit hunkered down and got an earnest look on its face. "You said a 2 was a 2, period, the end. Am I right?"
"Right!" shouted Rick and put his hand over his mouth. "Right!" he whispered.
"But," continued the spirit, "isn't it also true that numbers are, well, 'made up' – you can't go out into the real world and dig up a '2'?"
"Well, yes," agreed Rick. "It's an artificial system that mathematicians created, but that doesn't mean that a 2 doesn't have a consistent specific interpretation."
"But what if it's just like the mis-understanding of words we talked about earlier? What if there really are different interpretations of numbers? Did you say the business guys were 'lying' with numbers'?"
"All the time!"
"Couldn't they just be interpreting the numbers differently?"
"No way!"
"Steady on," cautioned the spirit. "Let's think about the role of the marketing or business guys or your managers. In the reality they face, there are many shades of 'exact.' Sometimes, 'exact' is a range, say of time or cost. They are perfectly happy with that and don't care what the 'real' result is as long as it's in that range. Sometimes the range can be pretty big, other times it's small—depending on the risks and what they're trying to do. It depends on the environment. Of course, there may be times when it's critical to be exact or at least, no later than some specific date. For example is if they have a budget projection tied to a specific delivery or they expect sales to increase by a certain percentage when they deliver a new product to the customer. The revenue expectation from the sales increase is likely factored in all over the place in budgets and the corporate plan in increased expenses such as new staff hires or new equipment. If it doesn't happen, it could be very expensive, since they may have already incurred some of the increased expense as they prepare to support the increase in sales when it hits."
"Well," Rick tilted his head to one side. "I can see that they're just 'using numbers,' but that doesn't mean I like it."
"Here's something else you might not have considered," continued the spirit. "The business guys use numbers to make decisions. They don't necessarily use numbers for computation. You know that guy on your team who didn't want to go along with the agile adoption? Fred?"
"Whoa! You know about that? How long have you been hanging around here?"
"I can be pretty scary sometimes," laughed the spirit. "Anyway, you went to Jim, your team lead, and said that there was no way the agile experiment was going to work with Fred on board. You weren't happy when Jim basically told you to suck it up and find something for Fred to do. But what did you expect? Jim can't fire and transfer people just because someone complains. Fred is a valuable contributor. He's an expert on the Whatsis and has implemented a bunch of them on past projects. You might need his help, especially with this new customer, even if he isn't agile. But, back to the numbers thing.
"What's interesting about this discussion is that managers love to deal with numbers, so if you had gone to Jim and converted the issue to something numeric instead of personal, the issue would have been much clearer and easier for him to understand the impact. Then you would have been more likely to get a response and some action—unless the decision is a no-brainer. One of my mentors told me that if a decision is easy, then it's not a decision! Managers have to think in terms of costs and benefits. What will happen if they say 'Yes' vs. what will happen if they say 'No.' Costs and benefits are tangible or intangible. They love tangible ones because they're almost always based on numbers. They're impersonal. You can't argue with them. They're easy to justify and back up if you are challenged or questioned. Also, numbers will always align in some way with the short-term and long-term corporate strategic plan. It could be a big deal or a little deal but they'll still align plus or minus. Intangible ones are trickier, harder to justify, harder to put your finger on. There's more chance of being wrong, and open to personal interpretation and challenge. They're there and they use them if they need them but managers prefer tangible ones if they're enough to justify the decision.
"So the message for you, Rick, is to turn your intangible reasons into tangible ones. The reasons you put before Jim were intangible—stuff about a team member's attitudes and actions and very personal, that is, all about that person, open to interpretation. When the issues are tangible: cost to the company, rework, extra time to get something done, wasted time in meetings, whatever the true costs were to the company, then you're getting your point across in a way the manager understands. Next time, give Jim something concrete to work with, something he can take to his boss so they can make a decision that you'll be happier with."
"You mean just make up stuff?"
"I mean no one can predict the future, but if you don't use numbers to communicate then the people you're talking to have nothing to hang on to except your word."
"My word isn't good enough?"
"That's right. You can't base business decisions on opinions from one person without any data to back it up. Jim may even have agreed with you, but he couldn't justify making the decision or presenting a case to his boss without something to back it up."
"Here's the big message," said the spirit. "This is the real reason I'm here. Developers use numbers primarily for computation. This is your 'a 2 is a 2' argument. That's a valid use for numbers, of course, but it's not the only use. The business guys use numbers for making decisions. In fact, they need numbers to make decisions. The business guys are not engineers. They have a different kind of problem-solving approach and they will never learn yours. The only solution for this dilemma is for you engineers to learn to speak their language. If you can do this, you will not only not lose credibility, you will enhance your standing with the business guys, because you are helping them understand your point of view. The other benefit is a purely selfish one. You need to have a better understanding of your own point of view. One of the messages from the agile world is to make estimates and then learn how to improve them. If you don't put numbers on the table, if you don't use numbers in your estimates, you can't improve those estimates. You can't learn how long it will take and you can't make progress toward communicating that knowledge to the business side. Trying to take an agile approach, trying to use numbers effectively, not only for computation but as a language, will improve your engineering ability. Does that sound like a win-win-win to you?"
"That's a lot to think about," mused Rick. "But I think I can sorta understand what you are saying. I think! Maybe I'll start by trying my hand at some numbers for Sam on this Whatsis. Maybe I could even get Fred to help? Geesh, what am I saying? Now you're going to have me talking to Fred as well as talking to myself!" As Rick stood up, he looked around and saw that he was again the sole occupant of his cube. He shook his head but he was smiling and nodding as he headed over to Fred's cube.
About the Authors
Linda Rising has a Ph.D. from Arizona State University in the field of object-based design metrics and a background that includes university teaching and industry work in telecommunications, avionics, and strategic weapons systems. An internationally known presenter on topics related to patterns, retrospectives, agile development approaches, and the change process, Linda is the author Fearless Change: Patterns for Introducing New Ideas, written with Mary Lynn Manns, and editor of Design Patterns in Communications Software, The Pattern Almanac 2000, and The Patterns Handbook. In the past, InfoQ readers really enjoyed Linda's "Bonobos" interview, talking about the science of the brain, and her article Questioning the Retrospective Prime Directive.
Barbara Chauvin has a background that includes industry experience in business system design, project and portfolio management with IBM, 3M, the DMR Group, and LinkAge. She is currently the Director of Business Support - Nonstandard Auto Insurance, for Sentry Insurance.