Are developers a stakeholder in a system

Question

Are developers of a product considered stakeholders?

Answer 1

Generally, yes, developers are stakeholders on a software project. That's consistent with the dictionary definition of the term. Here are a few definitions of stakeholder, from various publications:

Karl Wieger's Software Requirements:

stakeholder A person, group, or organization that is actively involved in a project, is affected by its outcome, or can influence its outcome.

Ian Sommverville's Software Engineering 8:

The term stakeholder is used to refer to any person or group who will be affected by the system, directly or indirectly. Stakeholders include end-users who interact with the system and everyone else in an organisation that may be affected by its installation. Other system stakeholders may be engineers who are developing or maintaining related systems, business managers, domain experts, and trade union representatives.

Roger S. Pressman's Software Engineering: A Practitioner's Approach (6th Edition) defines five groups or stakeholders: senior managers who define business issues, project/technical managers who organize and control the practitioners, the practitioners who engineer the system, customers who specify the requirements for the software, and end-users who will interact with the delivered system.

Scott Ambler's Active Stakeholder Participation: An Agile Best Practice:

My definition of a project stakeholder is anyone who is 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, or maintenance professionals potentially affected by the development and/or deployment of a software project.

...

In this definition I have chosen to exclude the developers who are working on the project. This may seem strange at first because developers clearly have an important stake in the projects that they work on. Yes, developers are definitely project stakeholders. Why do I continue to distinguish between developers and project stakeholders? Because I want convenient terms to distinguish them, I really don’t like “developer stakeholder” and “non-developer stakeholder”, and because they have different roles to play on a project.

In practice, I've typically seen stakeholders broken down into groups, and one group contains the people building the system. It is important to recognize that, when building a system, the developers do have needs and concerns that need to be balanced with the needs of everyone else. However, these need to be prioritized and taken into consideration with every other need.

Answer 2

Usually no, but there can be exceptions. "Eating your own dog food" comes to mind as the main exception as in this case the developers may be using what they build directly and thus they are stakeholders to some extent. However, I'd question if this was more than a few percent of developers overall though.

Answer 3

If this is being asked in relation to Scrum then no...

...definition of a project stakeholder is anyone who is 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, or maintenance professionals potentially affected by the development and/or deployment of a software project...

Stakeholders are individuals external to the current product development team in one form or another. If you are on team X and another developer is on team Y and you are working on differing products which interact with each other at a later point in time then you become a stakeholder in each others product.

Answer 4

Yes - for a system that will live on and be maintained. Developers are likely to work with the code to fix bugs and introduce new features long after the initial team closed the project. An important requirement for long lived systems are maintainability and who should put their stakes in this if not developers?

Answer 5

After a bit of googling, I must say that this is an unanswerable question. There is no one definition of a stakeholder and different sources use it differently.

As the Scott Ambler reference by Aaron points out, more than one methodology avoids the term altogether. Others try to break it down into different categories of stakeholders. The result is that while there's a general meaning that stakeholder is "someone with interest", the precise meaning is lost.

What that interest is comes down to one of two meanings in my mind:

• Those who expect to derive primary value from the application

or

• Those who will invest in the outcome of the project.

The sponsorship body fits either definition. How end users fit into the sponsorship body is another topic entirely. For now, lets assume they do fit in because I'm not willing to split hairs on it. Anyone on the project team fits the second meaning as well.

In the end what matters is that value is derived from our applications and we understand that the sponsors get the final word.

My general feeling is that people who want to lump in developers into the "Stakeholders" group largely care because they have seen situations where developers are treated as cogs in a machine and often treated poorly as a result. Feedback on requirements is not allowed, significant unpaid overtime is mandatory, etc. Because you're giving up time and sanity above what should be expected, there are people inclined to see that as an investment. Investment = stake so in their minds the development team are stakeholders.

As a result, I'm not a fan of the term. "Sponsors" is clear. "Stakeholders" is not.

Answer 6

No, they're not.

Stakeholder: A person or organization that may be affected by the success or failure of a project or organization

Source: http://www.site.uottawa.ca:4321/oose/index.html#stakeholder

Answer 7

They may be. If their postion after the product is finished will be different than before, they are a stakeholder. For instance, if a developer is paid a salary to develop software for a company, chances are he is not a stakeholder because nothing will change afer the product is delivered. However, if he is a partner in a startup, where his financial position depends on the product being successful, I would argue that he is a stakeholder.

Another example would be the (admittedly rare) case of a developer making software that he will use. In that case, he definately is a stakeholder because he has a vested interest in having that software work correctly.

Answer 8

Developers are indeed stakeholders (affected by what is produced): both those who initially develop a system, and those who maintain it. The former tend to be interested in new technologies and increasing their skill base, whereas the latter want to be able to keep up with the usually large number of systems they have to maintain.

However, 'legitimate' stakeholders is another question. When balancing requirements, all stakeholders are certainly not going to find their concerns addressed to their satisfaction. Is your company worried about losing top developers? Bump up developer concerns. If not, developers tend to end up fairly low on the totem pole. Unfortunately, this can have the effect of ignoring maintainability as well, building up technical debt like there's no tomorrow.

Answer 9

Basically, a Stakeholder is an individual or organization or, put it simply, "is an entity which is having good/bad influence on the project completion".

Stakeholders are very important in project accomplishment. Stakeholders may be a client, usergroup, project manager, project leader or coordinator.

You have to satisfy expectations of stakeholders in project completion.

Answer 10

I think it depends on the project.

A stake holder includes anyone who has a stake or interest in what the system does because then they will have some requirements to say what it should do. Therefore I wouldn't include developers in a project where the code is simply pushed out the door and forgotten but would include them if they are supporting the project or extending it as it is then the developers require the system to be maintainable/extendable.