Agile: ItΓÇÖs the business stupid!

26 November 2007

Ian Wilson
Gazelle Software Solutions

Just recently I read an article that underlined the extent to which agile software development is now “ready for prime time.” It was the July 2007 CNN Money Business 2.0The 50 Who Matter Now” survey. In it, agile software development ranked at position eighteen out of fifty, with Steve Jobs at number two and the founders of Google at number one. Agile development is definitely in the spotlight—but this level of attention can have a negative side. There is a danger that as more and more organizations join the rush to start using agile development methods, they will fail to realize how much change is required to be truly successful with agile. Unless these organizations make fundamental process, organizational, and cultural changes, they are unlikely to be successful and will be disappointed.

One critical area that must change is the relationship between the technical team and the internal customers for a particular software project, hereafter referred to as “the business.” Agile processes don’t just affect the technical team; they affect the business as well. The business must adopt a fundamentally different approach to planning, such as using adaptive planning. Rather than create so-called complete specifications, schedules, and estimates in advance, the business instead must learn to plan in detail for the next iteration and for a sequence of iterations that together will deliver the highest possible value in the shortest time. The business may feel the loss of the false reassurances that they had in the past from schedules and plans that were actually divorced from reality.

Agile also increases the level of direct involvement from the business on projects and in project teams. They must provide a dedicated, and usually full-time, product owner to prioritise the product backlog and set goals for each iteration (if using Scrum), or to write stories and acceptance tests in addition to prioritizing stories (if using XP). In addition participants from the business (e.g. Business Analysts) need to be a direct part of the project team in order to provide timely inputs and feedback to the developers. A lack of commitment to providing resources from the business to an agile project team is often the source of failure for agile projects. Managing stakeholders so that the business delivers on these commitments is critical.

Stakeholder Management

Now let us look at how Stakeholder Management is applied to ‘managing the business’ in the case of Agile projects. If the business is not involved, or if they do not deliver on their commitments, even an agile project with the best team of developers in the world will fail. The key steps in managing the business stakeholders for an agile project include:

  • Correct identification of stakeholders
  • Mapping of stakeholders to understand their current level of support
  • Understand what is needed from each of the stakeholders
  • Develop and implement an action plan to influence and get the required support from the stakeholders

For a successful agile project these stakeholders will generally align with particular roles both on the business and technical side of the house. Table 1 details the seven principles of effective stakeholder management. These principles are centered around communication, cooperation, and consideration. A key part of stakeholder management is identifying the real stakeholders and then deciding which strategies and actions to implement with each stakeholder to ensure that he or she has a positive impact on the project (or at least has a minimal negative impact). Table 2 lists some of the key stakeholders on the business side.

Table 1.

 Seven Principles of Stakeholder Management

  • Acknowledge legitimate stakeholders.
  • Listen and openly communicate.
  • Adopt processes and behaviors.
  • Recognize interdependence, risks and rewards.
  • Work cooperatively.
  • Avoid unacceptable risk.
  • Acknowledge and address conflicts.

Source: Clarkson Centre for Ethics and Board Effectiveness at the Joseph L. Rotman School of Management, University of Toronto

Table 2.

 Key Business Roles

  • Executive Sponsor
  • Business Unit Leader
  • Program and Project Owner(s)
  • Business Project Managers (BPM)
  • Product Owners
  • Business Analysts

Stakeholders can be categorized according to their potential to positively or negatively impact a project, as well as their potential to cooperate with the project team. Figure 1 illustrates this categorization. The goal of stakeholder management is to minimize the number of business stakeholders in the top right hand quadrant of Figure 1 and to maximize the number of business stakeholders in the lower row of Figure 1. Stakeholders in the bottom right quadrant are considered a mixed blessing because they can have a strong positive impact on a project. But if they stop being cooperative towards the project there could be a significant negative impact. This is an important point to remember when managing stakeholders in that quadrant.

Figure 1 

Figure 1. Stakeholders can be categorized according to their potential to impact a project.

Stakeholder management for agile projects differs in two important areas from classic stakeholder management, where business involvement is minimal after requirements gathering. First, if the organization is new to using agile methods there is the need to “sell” stakeholders on the concepts and benefits of agile methods. Second, there is a critical need for specific business involvement within agile projects. Unless stakeholder management in these two areas is successful, agile projects are highly unlikely to succeed.

Stakeholder Roles

Consider each of the roles listed in Table 2 and look at how stakeholder management would work from the perspective of the technical project manager who is responsible for successful agile software development:

  • Executive Sponsor – A key role! This individual will need to be sold on the potential business benefits of agile methods, i.e., how adopting agile can improve the company’s bottom line. Discussions with the executive sponsor need to be couched in terms of Business Value Indicators, e.g., how adopting agile methods for a particular project could bring a product to market faster and increase revenues by hitting a market window. Once on board, the executive sponsor can be an agent to drive change and the adoption of agile methods throughout the organization. Executive sponsors fall into the bottom right quadrant of Figure 1; they are a mixed blessing. So long as they are supportive, they can be a very powerful ally, but keep in mind that if you lose their support, they can be an equally powerful negative force. They must be kept on board if a project is to succeed.
  • Business Unit Leader – As the owner of a business area and/or a business unit, the business unit leader is another potential key ally for driving change and the adoption of agile methods. The business unit leader is influenced by debates  and discussions similar to those you would have with the executive sponsor; however with the business unit leader, the business benefit arguments need to be framed specifically around his or her particular business segment. For example, the business unit leader would be interested in how adopting agile methods could enable the success of projects that are key to  business unit plans for the current financial year. I was once involved with the introduction of new business processes to expedite customer change order requests at a large manufacturing company. Using agile development processes on a number of key applications enabled the right business processes to be developed and deployed ahead of the original schedule, with positive impacts on business unit performance. These impacts are what concern business unit leaders and are the kind of changes that turn them quickly into agile allies. From a stakeholder management perspective it is vital that business unit leaders are at the very least neutral on adopting agile methods, but ideally they should be supportive. If they are only neutral, then the active positive support of the Executive Sponsor is even more critical (and vice versa).
  • Business Program and Project Owners – These are the individuals who have the responsibility for one or more programs or projects. These programs and projects may reside within a single business unit, or may extend across a number of business units. These are the individuals who often have responsibility for program and project budgets and have to put forward the business case for undertaking these programs and projects. If agile methods are going to be adopted successfully on the projects for which they ultimately have responsibility, then they need to understand how agile can help them meet cost targets and deliver functionality to the business within given timelines. They also need to know how agile can deliver the critical functionality to the business more rapidly. In terms of stakeholder management these individuals have to be supportive of adopting agile methods and are usually the first stakeholders to be addressed when stakeholder management is undertaken. Business program and project owners are a liability if they are in the non-supportive quadrant. Manage them towards the mixed blessing quadrant.
  • Business Project Manager (BPM) – In real life projects, the Project Manager may come from the business side of the house or the technical side of the house depending on whether the center of mass for the project is business (e.g. a new sales and marketing system for processing orders) or technical (e.g. a new system for monitoring network availability). As agile software development projects are usually about delivering functionality to business users it is often the case that the project manager will come from the business side, although the business and technical project management roles can be combined. The BPM has to be just as committed to the success of using agile methods as the technical project manager (TPM). A high level of trust and openness must exist between the TPM and BPM so that they truly operate as partners. The BPM must reside in the bottom right quadrant of the chart in Figure 1. The TPM should be prepared to take all necessary action to keep the BPM in that quadrant. Stakeholder management of the Business Project Manager (BPM) is needed so that the BPM is committed to using agile methods on his or her project and in particular gets the commitment and the resources from the business to ensure project success. This includes:
    • An identified and empowered Product Owner from the business who is sufficiently knowledgeable and skilled to prioritize the product backlog and set goals for each iteration (or write stories and acceptance tests and prioritize those stories, if using XP). This is not usually a part-time role! The higher quality the product owner the higher the project’s probability of success.
    • The commitment to have representatives from the business directly involved in the project (e.g., within an XP project room) or at least to designate appropriate customer proxies to work on the project team.
  • Product Owners and Business Analysts – These are the customer representatives from the business who are usually engaged in the day-to-day business of an agile project. They are the business content experts who can prioritize stories and give real-time feedback throughout iterations. Successful stakeholder management of these individuals should ensure that they remain fully committed to the project throughout its lifetime, and they do not get deflected away from the needs of the project by other activities within their business group. Product Owners and Business Analysts should typically be in the bottom right quadrant of the chart in Figure 1; in other words, actively supporting the project and actively involved.

All the activities listed above underline the amount of time and focus that needs to be spent by an agile project manager in managing the business. Let me give some real examples of successful stakeholder management from past projects. In my experience demos have been very powerful in winning over the support of executive sponsors at the board or senior management level. In one case the output from an iteration (an early release of a new supply chain application) was demonstrated to a senior vice-president to show how a key new business process could be implemented ahead of original schedules. The success of the demonstration was a key factor in moving this executive sponsor into the bottom right quadrant (the mixed blessing quadrant) of the chart in Figure 1.

In another example a business unit leader traveled to meet with the offshore agile development team and was able to see the team working in action. From this experience, the business unit leader was able to understand how the agile processes that the team was using would give his business the functionality from a new system faster. He quickly moved into the mixed blessing category. Definitely a case of seeing is believing, this experience provided a great foundation for the stakeholder management of this individual.

The business is critical to a successful agile project. If the business is not involved, or they do not deliver on their commitments, even the best team of developers in the world will not be able to rescue the project. Strong stakeholder management of the business is essential ensure success. To adapt a slogan used in a recent US Presidential election campaign: “Agile: It’s the business, stupid!”


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Rahul Sawhney, CSP,CSM, 2/2/2008 1:07:51 PM
Interesting article. Management of business stakeholders is indeed important for successful deployment of Scrum. While adaptive planning is easier in smaller companies, it's more difficult in larger companies since money spent is often tied to organization strategy workshops and heavyweight processes for product management. While all product companies using scrum are not lean enough to integrate their business departments so well with project teams, it is in most cases possible to involve business in intermediate stages. Adaptive planning therefore may not be a fundamental change, once benefits of evolution and need to review plans are understood by the organization.

You must Login or Signup to comment.