|
So your boss just doesn't get "agile"? Scott provides a "management speak" primer on how to effectively pitch your ideas.
May 07, 2007
URL:http://www.drdobbs.com/architecture-and-design/pitching-agile-to-senior-management/199300107
Scott is a DDJ Senior Contributing Editor and author of numerous IT books. He can be contacted at www.ambysoft.com/ scottAmbler.html.
A common lament amongst developers who want to adopt agile techniques is that they don't know how to convince senior management to let them do it. Until recently, agile software development was on the left-hand side of Moore's technology adoption chasm where it is relatively easy to convince people to try new ideas—often a 30-second elevator pitch was enough to get the go-ahead. Now that we're on the right-hand side of the chasm and dealing with early majority and late adopters, the elevator pitch at best might get you permission to give a detailed presentation sometime next quarter. The rules of the game have changed and many of us are struggling to adapt.
This inability to articulate to senior management why they should adopt agile techniques is ironic considering our focus on communication. My experience is that management is often very willing to become more agile if you're able to describe to them the costs and benefits in an understandable and meaningful way. This column shares some of my insight for doing so.
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."
You can often give yourself permission to adopt many agile techniques. For example, I sometimes run into people who don't refactor their code because they think that management won't let them. Refactorings are very small and simple changes, such as renaming an operation or reorganizing it into several more cohesive operations. With refactoring support in most IDEs, it's as easy as writing a loop or comparison statement. Surely you're not asking permission to write loops, so why would you ask permission to be allowed to rename operations? Similarly, other productivity-enhancing programming techniques, such as test-first design (TFD) and continuous integration, can be adopted without getting senior management involved. In fact, chances are pretty good that they'd be annoyed with you for wasting their time with such a trivial decision and might simply deny it out of hand. In summary, pick your battles wisely, and when you do decide to champion a cause, make sure you know how to effectively pitch your idea in "management speak."
|
A Financial Lingo Primer
One of the most important things that you can do as an IT professional is to learn and adopt common terms used by senior management and business stakeholders. Understanding these terms will improve your ability to communicate and will increase your appreciation of non-technical issues—the best developers know that there is more to development than development.
• Diminishing Returns. As more investment in something is made, the overall return on investment (ROI) increases at a declining rate until it reaches a point where it begins to decline. For example, if a diagram isn't yet good enough for the situation at hand, then you can keep working on it until it is good enough, at which point any more work on that diagram is a wasted effort. Although the continued work still adds value, it doesn't add as much value as when you first started because you likely addressed the critical issues right away. The concept of diminishing returns is critical because it enables you to recognize that it doesn't make sense to try to "complete" a work product.
• Discount Rate. The rate at which future cash flows are adjusted to reflect the time uncertainty of money—a dollar tomorrow is worth slightly less than a dollar today. Minimally the discount rate is at least the expected rate of inflation and it is required to calculate the NPV of a project.
• Internal Rate of Return (IRR). The discount rate that makes the project have a zero NPV. For a project, the IRR is equivalent to the interest rate at which you would need to invest your money to get the same value as a project. IRR is used to compare the value of projects. For example, say you have a project that initially cost $500,000 and generated net benefits of $300,000 in the first year, $400,000 in the second year, $250,000 in the third year, and $100,000 in its fourth and final year of production the IRR is 45.3%.
• Net Present Value (NPV). The NPV of a project is the sum of the present values of the annual cash flows (the revenues less the cost) minus the initial investment. The cash flows are discounted to take into account the time uncertainty of money. For example, with a discount rate of 10% per year, one dollar a year from now is only worth $0.91 today (1/1.10). NPV is a critical concept because it enables you to compare things that have varying initial costs and cash flows.
• Opportunity Cost. This is the cost of passing up a choice when making a decision. For example, if you could have spent $10,000 in additional testing and avoided a mistake that ended up costing you $15,000 to fix, then the opportunity cost of not testing was $5,000 ($15,000—$10,000). The concept of opportunity cost enables you to communicate the value in taking, or not taking, a course of action.
• Payback Period. This is the length of time required to recover an initial investment through the discounted cash flows generated by the investment. The shorter the payback period, the lower the financial risk of a project.
• Return on Investment (ROI). ROI is the number of times the net benefits (revenues minus costs) recover the original investment. The greater the ROI, the better the project. For example, assume a project initially costs $500,000, generates revenues of $250,000 a year with an annual operating cost of $50,000, and runs for ten years. With a discount rate of 0% the NPV of the project is $1.5 million (($250,000- $50,000) x 10 - $500,000), therefore, the ROI is 3. With a discount rate of 5% the NPV is $1,044,347, therefore, the ROI is 2.088.
• Time to Market. The length of time it takes to get a product from idea to marketplace. In the case of a software development project, the time it takes you to get your system into production. The longer the time to market, generally, the greater the risk.
• Total Cost of Ownership (TCO). TCO is the total costs over the lifetime of a work product. TCO captures the true costs of an item, such as a document, component, or system, not just the initial investment. For example, for the aforementioned system, the TCO with a discount rate of 0% is $1 million ($500,000 + 10 x $50,000) and with a discount rate of 5% the TCO is $886,087. |
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.