Stakeholders over Customers

A stakeholder is someone who is materially impacted by the outcome of the solution.  In this regard, the stakeholder is clearly more than an end-user: A stakeholder could be a direct user, indirect user, manager of users, senior manager, operations staff member, the “gold owner” who funds the project, support (help desk) staff member, 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 a software project.  To simplify the definition of stakeholders, we’ve adopted Outside In Software Development’s four stakeholder categories:

  1. End users.  These are the people who will use your system, often to fulfill the goals of your principals.  They typically want systems which are usable and enable them to do their jobs more effectively.
  2. Principals.  These are the decision makers who ultimately pay for and then put your system to use.  This includes gold owners, senior business management, and purchasers of the commercial systems.
  3. Partners.  These people make the system work in production.  This includes operations staff, support staff, trainers, legal experts, installers, application hosting companies, and application developers on external systems which integrate with yours.
  4. Insiders. These are members of the development team and people who provide technical and business services to your team.  This includes enterprise architects, database administrators, security experts, network experts, toolsmiths, marketing experts, and sales staff.

So why does DAD use the term stakeholder instead of customer?  Although customer is a perfectly good term, it’s very popular with agile adherents, we’ve found that many agile teams will inadvertently limit themselves to considering just end users and principals to be their customers and miss the partner stakeholders and sometimes even the insider stakeholders.  Granted, you’ll often work with some insider stakeholders as a matter of course throughout the project so it’s hard to miss these people, although both of us have seen core agile teams neglect working with their organization’s enterprise architects in the name of “having the courage to worry about tomorrow’s problem tomorrow.”  Our experience is that although the term stakeholder is a bit more formal than the term customer, in practice it seems to lead agile teams to a more mature strategy.

One challenge with the term stakeholder, which customer also suffers from, is that it reinforces the “them vs. us” mentality prevalent in many IT departments.  When we use terms such as “the stakeholders” or “the customers” or “the business” they imply that we see ourselves as a group set apart from them.  The reality is that it isn’t the business, it’s our business, that we’re all in this together.  It’s important to be careful with terminology.

12 thoughts on “Stakeholders over Customers

  1. Pingback: Roles in Disciplined Agile Delivery | Disciplined Agile Delivery

  2. Nick

    With respect to Enterprise Architecture (insiders in general as well), yes I do this needing to coalesce with them better at the start and during a project. Agile teams are usually blinkered to the overall strategy of the organization. On the other hand Enterprise Architecture should not be a device to constrain and limit. I would also make that statement of PMO and executive parts of bigger organisations. Ultimately finding the balance point between high ceremony and delivering a working solution is key. Yes integrating with the EA strategy does produce more mature delivery. EA can form a basis for design principles for a project. EA needs to inject itself more and vice versa, specifically with EA being proactive in all facets rather than throw a document over the wall.

  3. Nick Clare

    In support of the idea of “stakeholder” being a more inclusive term than “customer”, I have even occasionally experienced teams who seek to explicitly exclude other stakeholders and only deal with “real” customers’ needs. They didn’t do this out of malice but genuinely thought that is what Agility demanded. So “stakeholder” is altogether a far safer term.

  4. scottwambler

    Nick, you bring up good points about enterprise activities such as enterprise archiecture and the PMO. This is one of the reasons why the DAD framework promotes enterprise awareness and not just team awareness as other agile methods do. Disciplined agilists consider the bigger picture and actively seek to work with enterprise professionals.

    1. Nick

      Yes Scott, Agile methods in general don’t spell out the enterprise view and therefore promote that myopic view. Your work is addressing this and I hope to help others reach that sweet spot as well with the same Agile Manifesto principles still in tact.

      1. Nick

        I wanted to add, evolve designs like you say in your book. Alot of PMO world still likes Big Design Up Front and collecting signatures under the guise of governance.

  5. Pingback: Disciplined Agile Delivery » Roles in Disciplined Agile Delivery

  6. Keoni

    At what point do we decide that someone is NOT a stakeholder? It seems to me that with any non-trivial solution, one could quickly come to the conclusion that almost everyone in the entire company/world is a stakeholder.

        1. Scott Ambler

          Our philosophy in DAD is to be clear about the complexities that we actually face in practice. If you choose, in your environment, to restrict who you consider to be stakeholders then that’s your decision. But make that decision with your eyes wide open, understand the implications of what you’re doing and then act accordingly.

  7. Valentin Tudor Mocanu

    Regulatory authorities could be also default stakeholders, where the software is developed for customers that act in a regulated domain area (aviation , medicine etc.)


Leave a Reply

Your email address will not be published. Required fields are marked *