White PapersMore >>
Ed Yourdon says it best: “Politics is a factor in every software development project, no matter how much we might want to deny it.” (Death March, 2nd Edition, Prentice Hall PTR, 2004). Everyone knows this unsavory truth, but we all seem to ignore it. Someone is added to a team so that an outside group can be part of the action, a development tool is chosen by someone who probably can’t even install it, or a status report is requested by someone you’ve never met before; that’s politics—and you can’t escape it. Since politics is an inherent part of software development, wouldn’t it be best to make it an explicit part of your process? By acknowledging it openly and analyzing its components, we’ll be able to best utilize it.
The Rational Unified Process (RUP) is arguably the leading choice within the well-defined/prescriptive process category. Therefore, it only makes sense to focus on extending RUP to explicitly address politics—anything we do for RUP could easily be modified for other prescriptive processes. I’ve added the Politics discipline to the traditional RUP lifecycle—something your organization should consider doing. The complexity of IT organization politics is truly amazing—often, entire groups exist solely to interfere with the occasional project team that’s actually trying to get things done. In fact, the majority of your IT staff may be focused on political activity rather than productivity. “Activities and Roles” depicts this complexity in a RUP activity diagram, introducing three new roles and many new activities.
[click for larger image]
Activities and Roles
Politician, political shield and pawn are useful role additions to RUP.
Politicians who are directly involved with your team try to control information flow, the lifeblood of any development project, or purposefully mismanage the team. An effective politician bends a project team to his will, regardless of the project’s actual goals, because he’s convinced that his own vision is of greater importance. Often smarter than everyone around him, the politician can usually see the bigger picture that others can’t, and is willing to do whatever it takes to ensure that his vision is achieved. This is why it’s critical to have well-documented procedures for politicians to follow—you want to ensure that the “best” people in your organization steer it effectively.
To ensure that the team is guided properly, politicians outside a project team can follow three categories of activities: increasing bureaucracy, supporting the “old boys” network and undermining the team. It’s important to recognize that internal politicians can follow these strategies, as well, although it’s instructive to consider ways that the team outsiders apply them.
Undermining a team that isn’t conforming to your will can be a spectacularly effective means to achieve your political goals. You often begin by gathering information via queries to naïve pawns. A casual discussion, perhaps over drinks to help cement a friendship, can be all it takes to obtain the team’s current plans and status because the pawn is gullible enough to trust you. Even if you have no intention of keeping your word, you can use the information you’ve gleaned from the pawn to determine what you must publicly agree to now—and later discard for your own purposes.
The beauty of the Politics discipline? It encompasses many everyday activities that you wouldn’t normally associate with political maneuvering, such as requiring detailed documents or promoting your friends. You may be working with politicians and not even realize it, so never underestimate the value of explicitly documenting your software process, because it identifies what’s actually going on around you.
You Need a Shield
Political shields are those people who try to minimize other politicians’ effects on a team. They may decide to block other groups (see “Running Interference,” The Agile Edge, July 2003) or simply spin the politics in favor of their team. Through open and honest communication and by revealing political maneuvering, they’ll protect the pawns close to them, giving them time to gain political skills. They may even decide to remove a team from the political landscape altogether by creating a separate “skunkworks” project.
The political shield role is typically filled by a senior team member, usually the project manager or coach. It’s a rewarding role—you can spend most of your time honing your skills in political battles, instead of wasting it building software that meets the needs of your stakeholders. Politics are paramount, after all!
Don’t Be a Pawn
Those team members playing the role of pawn are usually sad and pitiable people, with few political skills. They often hold the misguided belief that they should avoid politics altogether. As if! By refusing to be political, they’re merely being manipulated by those who are. Fortunately for the politicos, the pawn’s only political activity is to try to stay out of trouble—a futile endeavor.
You may notice that very few artifacts are created in the Politics discipline: Politics isn’t about building anything; it’s about achieving your goals. Granted, you may create or overbuild status reports and project plans as the result of political maneuverings. However, those artifacts are already claimed by other disciplines, so it wouldn’t be right to take credit for them here.
In “Activities and Roles,” I neglected to include a fourth role: The April Fool—someone who believes everything that he reads or is told. Though some may take issue with extending RUP with a Politics discipline, I believe the first day of April is the right time to be honest about what really goes on around the office.
Scott Ambler is a senior consultant with Ronin International Inc. His latest book is Agile Database Techniques from Wiley Publishing.