Common Project Risks and Agile Mitigations, Part 6, Quality & Stakeholders

Part 5 addressed the category of technology. This part will address the next two most frequently mentioned categories of issues that can lead to project failure: quality and stakeholders.

Quality Related Issues

The particular issues related to quality mentioned in the various survey sources include:

• general lack of focus on quality (i.e., assurance and control), leading to critical problems where quality and reliability end up being unacceptably poor.
• No practical way to show software meets non-functional criteria (i.e., “ilities”) or that the delivered software will "work" for the user.
• Misunderstanding of the role of quality assurance, giving it a secondary status to other activities and viewing it as just being about testing.

Applicable Agile Values and Principles

Agile’s major contributions to addressing quality issues are:

• the insistence on working software as the actual measure of progress (and success) on a project;
• early and frequent demonstration of functionality to the customer;
• clear acceptance criteria that define what it means for functionality to be “done.”

All of these work together to help reduce the possibility that what is built diverges from what the customer needs/expects and to increase the likelihood that what is built functions acceptably. Various development practices are used to implement these three main goals (e.g., TDD, continuous integration, pair programming, shared code ownership).

The brevity of this discussion on quality is not meant to trivialize its importance, just to indicate that an Agile approach has fairly straight-forward quality-related goals and techniques to met those goals.

Stakeholder Related Issues

It might have been expected that stakeholder related issues would be a bit higher, but some of the more frequently mentioned items have stakeholder impacts associated with them. The particular issues related to stakeholder attitudes and behaviors mentioned in the various survey sources include:

• Lack of sufficient user input/involvement leading to or as a result of most requirements coming from management or other user “proxies” who do not (or rarely) use the existing system.
• Stakeholders unable to agree on answers related to requirements, resources, etc. and the consequences of these things, who then “paper over their differences” early on, pushing problems into development where they are revealed when software implementation concerns demand a specific answer.
• Fear that project threatens their job: their influence (even working conditions) in the organization because many software projects result in one group assuming power and another losing it.
• Stakeholders who are partners on this project may be competitors in other areas.

Applicable Agile Values and Principles

Quite frankly, in my view, there aren’t significant Agile ideas that specifically address the last two of these issues. Certainly, the Value of “customer collaboration” applies here, but does not, in itself or in combination with any of the Principles, offer a solution to serious stakeholder personal or competitive differences.

As to the second issue, Agile advice is to give the development team a single individual to “represent” the customer(s) and deal with the differences before the team gets its direction on functionality and priorities. That person (e.g., Product Owner) deals with the stakeholder diversities. Not really a solution in itself as it just hands the issue to the business, saying it needs to handle this if the development team is going to be able to be as “agile” as desired.

With multiple, a perhaps disparate, stakeholders, there is not Agile “magic” to wipe away the problems. Early and frequent demonstration of working software, though, can help focus stakeholder attention on the work, giving them concrete functionality to consider. Being concrete often makes it easier to overcome, or at least discuss somewhat more openly, concerns of and differences between stakeholders.

The first issue is best addressed through Agile’s goal that there be regular, frequent involvement by the customer in discussing functionality and reviewing iteration output. However, this will not prevent the “customer” view from being dominated more by management than actual system user perspectives. Again, it is left up to the business side of the relationship to ensure the information the development team receives represents the actual needs of the business in a way that will allow the most benefit to be derived from the work produced.

[Note: In the case of both quality and stakeholder negotiation matters, there is a great deal of existing wisdom and practice that is not Agile-specific in nature, but certainly consistent with Agile Values and Principles. Indeed, one could say the same about all of the issues mentioned in this series. Certainly, the goal of the series has not been to suggest only Agile ideas exist to address them, just that Agile has something to contribute in the way it suggests conducting product development.]