The Agile Modeling (AM) Method

Stakeholders of Software Development Teams

Let’s start with some definitions:

  • Solution. This is the product or service that your team is providing to its customers. A solution will typically include software, a platform to run the software on, business processes, and supporting artifacts such as documentation,
  • Initiative. An intiative may be a solution development project, the ongoing evolution of an existing solution, or the creation of an artifact such as a model or roadmap.
  • Stakeholder. A stakeholder is anyone who is materially impacted by the outcome of an initiative.

A stakeholder could be:

  • A direct user
  • Indirect user
  • Manager of users
  • Senior manager
  • Operations staff member
  • The “gold owner” who funds the initiative
  • Support (help desk) engineer
  • Auditors
  • Your program/portfolio manager
  • Developers working on other systems that integrate or interact with the one under development
  • Maintenance professionals potentially affected by the development and/or deployment of your solution.

From this definition you can see that business people, such as direct users and their managers, aren’t the only stakeholders of an initiative. As you know there is a wide range of people potentially affected by a new solution, therefore to succeed you must understand and then synthesize their requirements into a cohesive vision. This is one of the things that makes software development hard: each stakeholder will have their own requirements, their own vision, and their own priorities. But it also makes software development fun.

Agile Modeling (AM)’s definition of stakeholder and developer may be different than yours, or perhaps you prefer different terms. For example, XP discusses the concepts of customer and programmer, not stakeholder and team member, and has slightly different definitions because they use the terms differently than AM does.

Categories of Stakeholder

AM distinguishes between four types of stakeholder:

  1. Business stakeholders. This includes end users, their managers, and the decision makers who pay for and oversee your initiative. Business stakeholders are also known as domain stakeholders.
  2. Supporting stakeholders. These are people who oversee, guide, or collaborate with the team to help them successfully produce their solution. This includes enterprise architects, database administrators, security experts, network experts, and toolsmiths to name a few.
  3. Downstream stakeholders. These are the people who operate your solution in production, who market and sell your solution to customers, who support your customers using your solution, and the people who evolve your solution (this may be the original team) after it has been deployed.
  4. The team. The team clearly has an important stake in what they do.

A Team and Their Stakeholders

For ease of discussion, AM talks in terms of the team and their stakeholders. Yes, as indicated above, the team is definitely a type of stakeholder. But, for ease of conversation, AM separates the two concepts.