The Politics of Agile
When product managers weren’t looking, the developers went agile. Droves of consultants descended upon development organizations and coached the teams on how to build software in a modern world. No more heavy-weight, NASA-style requirements and specifications. HOORAY! Let’s build something, show it to customers, incorporate their feedback. Lather, rinse, repeat.
While developers sprint through development cycles, one of three things happens to product managers. 1) They are ignored. 2) They are dragged deep into the development cycle. 3) They lead the team to build products people want to buy. The first two situations are lethal to a product manager’s career. The third alternative can lead to successful products and successful careers.
Politics is the process by which groups of people make decisions . In business, the process for building products requires hundreds of decisions every week. The challenge lies in who is involved, when do the decisions need to be made, how are decisions made, and who has the final authority.
To play politics is to deal with people in an opportunistic, manipulative, or devious way, as for job advancement. This is the most toxic form of politics which should be avoided at all costs. Unfortunately, in some organizations we are victims of this type of politics. The antidote for your career is to stay focused on the objective (building products people want to buy), to be messenger of the market, and to use facts rather than opinions to communicate.
Somewhere between the flakes in Marketing and the geeks in Development is product management. A strategic role designed to help companies stay tuned in to what the market wants and is willing to pay for.
What product managers say:
'My developers have gone agile and it is creating chaos.'
'My developers want me available every minute of the day to answer their questions. I have no time to visit customers.'
'The developers are delivering code every two weeks, but it doesn’t seem like we are making any progress towards delivering a useful product.'
'How can I market a product when I have no idea what will be in it or when it will be available?'
In fairness, we also have to listen to the developers and understand why agile methodologies have sprung up in the first place.
What developers say:
'We’re being asked to stop what we’re doing to respond to the deal of the day. We’d get something done if you’d just let us finish what you already asked us to do.'
'Market Requirements Documents are so nineties. We’re agile.' [Translation: 'We don’t need no stinkin’ requirements!']
'How can I estimate how long something is going to take when I have no idea what I’m being asked to do?'
'We’re tired of getting beaten up by management for not meeting our dates. How can we be blamed when the target keeps moving?'
'It’s about time we took back control. Product managers don’t know what they want.'
Angst. Frustration. Conflict. Mistrust.
What is the real problem? On the surface, the problem seems to be that everyone is trying to wrestle control from the other. Who will win the race? Product Management is frustrated at what appears to be a lack of commitment from Development. Development is frustrated because Product Management won’t commit to what they want and keep changing their minds. Even customers don’t know what they want.
The real point of all of this is to build products people want to buy. Ultimately, we’re on the same side. Ultimately, we all want successful products that help us all make lots of money.
What is agile anyway?
Agile development is an approach to planning development and engineering projects that relies on frequent delivery of products using quick teams and brief artifacts. In contrast, waterfall development is a sequential software development process where each phase is completed before moving to the next phase: requirements, software design, software development, system test, integration, and maintenance.
The implied promise of agile is to deliver products in a timely fashion without being burdened by heavy-weight documents and processes.
Based on the 2007 Pragmatic Institute Survey, the most common agile methods are:
Scrum – a software development method for project management. Work is delivered in two- or four-week sprints. After each sprint, the team demonstrates their results to the product owner (and others). There’s a prioritized backlog of problems to solve.
Rapid Application Design (RAD) – a development methodology that uses CASE (computer-aided software engineering) tools, prototypes, and user-interaction to achieve the goals of high quality and speed.
Extreme Programming (XP) – this methodology was created by Kent Beck in the late 1990’s during an internal project for Chrysler Corporation. He wrote about it in Extreme Programming Explained in 2000. This method embraces the values of communication, simplicity, feedback, courage, and respect. Traditional software engineering practices taken to so-called 'extreme' levels. For more, go to www.extremeprogramming.org.
In 2001, Beck and 16 other 'organizational anarchists' developed the oft-quoted Agile Manifesto.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Pragmatic Institute signed the Agile Manifesto in 2001. We believe in being agile. But simply adopting an agile development methodology is not the entire solution. Agile helps deliver something sooner, but without some planning and overall vision, what is being delivered may not actually help us sell more software. Our approach is:
Extreme Product Management (XPM) – an agile approach to product management. using minimum process and artifacts. The agile product manager communicates the vision of the product through a high-level product roadmap and keeps a prioritized list of problems to solve, all based on market data. The objective is to build products people want to buy.
Even when organizations are not agile, product managers need to be agile.
A Pragmatic approach
Pragmatic Institute’s agile approach to planning works regardless of which development methodology is used. A key concept is that the product manager must become the market expert and the single voice of priority on the team. Rather than just reacting to the list of requirements submitted by everyone (customers, sales, support, development, executives), the market-driven product manager visits a representative set of people in the market (including non-customers) on an ongoing basis. He keeps the team focused on the targeted market segments, buyer and user personas, and problems worth solving. He conducts surveys periodically to quantify the inputs and a keeps a prioritized list of open problems to solve.
To avoid Dilbert-style executive meddling and office politics, the product manager must establish credibility and deliver value to the team. Great communication skills are essential.
Listen to the market to gain an understanding of their problems. Not just what they tell you they want, but knowing them better than they know themselves. Look for urgent, pervasive problems to solve that the market is willing to pay to solve.
Listen to your internal team to gain the credibility you need to lead. Practice diplomacy without flip-flopping.
Become an active, empathetic listener both inside and outside the company.
In order to stay agile, the product manager must continuously distill inputs into a list of problems to solve. A vision of the product is articulated with a positioning document and high-level product roadmap.
Know your audience. Use market facts instead of opinions. When development and product management get stuck, listen carefully to what everyone is saying and propose a third alternative.
Maintain the single voice of priority by keeping everyone focused on the vision of what you’re trying to accomplish, backed by market facts. This does not mean getting into every detailed design discussion, picking out icons, writing error messages, and meddling in the development process.
In order for governments to operate effectively, roles need to be clearly established. In the United States, we have three branches of government (Executive, Legislative, Judicial); each branch has multiple roles (President, Vice-President, Senator, Justice, and so on). Roles, responsibilities, and interactions between the roles are established.
Technology companies should not become bureaucracies like our government, but having clear roles and responsibilities is essential. When building products for a market of customers (as opposed to a single customer), five roles are needed whether you practice agile or waterfall.
- Product manager: messenger for the market; defines what problems need to be solved and for whom
- Product designer: expert in design, defines how the problems will be solved
- Development team lead: liaison to the developers
- Quality assurance lead: assures that the product solves the problems identified by the product manager
- Project manager: manages the schedule and resource allocations
Even if there are not five people, these functions need to be performed. If the product manager takes on any of the other roles, it will be at the expense of becoming the market expert and having the right information to be the single voice of priority. Let the developers develop. The product manager identifies what needs to be built, not how to build it. Validate with the market that what the developers are building and how it is being built resonates with buyers and users.
The politics of how these team members interact and make decisions is determined by the development method employed. One of the reasons agile is so fraught with politics is the lack of clarity on who is supposed to do what. Ultimately, if the product manager is to lead the team as the single voice of priority, he needs to earn the right by being grounded in market expertise, facts, good listening skills, and respect.
Who will win?
The flakes in Marketing or the geeks in Development?
Although politics play a part in any business, building products people want to buy isn’t about who will win. Product managers and developers need to work as a team in order to get anything done. Establishing clear lines of responsibility, methods of communication, and respect for one another is essential. Agile or not.
Simply adopting an agile development methodology is not the entire solution to building products in today’s world. Agile helps deliver something sooner, but without planning and overall vision, what is being delivered may not actually help us sell more. To be an effective product manager in an agile environment, become the messenger of the market and keep the team focused on solving problems for markets of customers, problems they are willing to pay to solve.
Looking for the latest in product and data science? Get our articles, webinars and podcasts.