Speaking to Management
Senior managers are generally smart people, regardless of what we might like to believe, although they will often be operating with less than perfect information and choosing from a multitude of alternatives. If you go in with an "us vs. them" or an "I'm smart and management is stupid" mentality, you're likely not going to get what you want. A better approach is to recognize that you need to provide sufficient information, or more importantly a coherent argument, to them using language that they understand. This language is invariably financially focused instead of technically focused—the sidebar lists several critical financial terms that everyone should understand.
First and foremost, the surest way to convince management to do something is to connect it to their personal success. To do this you need to understand the objectives against which they are judged. Chances are pretty good that they're not going to be rewarded for adopting brand-new "really cool" agile development techniques. Instead, they'll have objectives such as reducing average time-to-market of software development projects, increasing return on investment (ROI) in information technology, or increasing end-user effectiveness. Until you understand what motivates senior management, you have no chance of presenting a convincing pitch to them.
Figures 1 and 2 are two of my favorite diagrams for explaining to senior management why agile software development works. Figure 1 maps common development strategies to the cost-of-change curve (see www.ambysoft.com/essays/whyAgileWorksFeedback.html for details), very clearly showing that agile techniques are less costly than traditional techniques. Figure 2 compares the serial and incremental approaches to development, showing that the incremental approach favored by agile developers results in lower financial risk due to a shorter time-to-market and shorter payback period. Lower cost and lower risk are two issues that get management's attention.
Earlier, I pointed out that management would rarely have 100-percent information upon which to make decisions; a related issue is that they will often be working under misconceptions, which require you to help them to overcome. For example, many organizations are very wary about adopting pair programming, even though there is a fair bit of evidence supporting its adoption. A few months ago I was educating a client about agile development and they told me that they weren't interested in pair programming because of what they felt to be obvious loss of productivity in having two people do the work of one. I pointed out that with pair programming, when you're doing it right, both pairs are exhausted after five to six hours. One manager in the room pointed out that it would be better to have their programmers work alone for that same five to six hours. I said that in theory that might be correct, but in practice this likely wasn't happening within their organization. To prove my point, I asked a few of them to walk around the office with me and stick their heads in the cubicles of programmers to see what they were actually doing. At 10:30 in the morning, what should be prime time for programming at this organization, only about one in six appeared to be coding. The rest were checking e-mail, browsing the Web, or doing other things. Later that week, management decided to try pair programming on one team to see how well it worked for them—once they had adequate information in hand, and had overcome their misconceptions, management made the "right decision."
