Common Project Risks and Agile Mitigations, Part 7, Everything Else

Part 6 addressed the topics of quality and stakeholders. This part will address the remaining categories of issues that the various sources identified as contributing to project failure. They involve issues with and between people, availability of information, failure to apply lessons learned, testing process and vendor performance.

Remaining Issues

While a number of the issues noted below have impacts in many other categories, there are some specific instances if problems that were not assigned to other areas and mentioned on their own in the various surveys of problem failure risks. The remaining categories/issues are:

• tension in social relationships; people (often respected staff) who, for one reason or another, block progress.
• missing, or delayed access to, information resulting in untimely decision-making. (Shari Pfleeger [May] notes the common situation that “there isn’t one person who has an overview of the whole project.”)
• not learning from past problems and/or ignoring the need to act on what has been learned.
• inadequate procedures, strategies, and tools to be used in testing; late involvement of the test team in the project.
• poor vendor performance delivering on a contract; for vendors of contract staff, a concern was offshore-outsourcing relationships as engineers sometimes must train colleagues who do the same work for much less pay. (Vendor contract issues were not mentioned much, but were a high % item when they were.)

Applicable Agile Values and Principles

Regarding people issues, Agile’s emphasis on transparency, regular improvement, and a team-based approach, while not automatically solving problems, will surface them sooner and in a more constructive atmosphere when it can be less costly to address them.

Agile’s expectation of frequent, direct communication between development team, business staff, and stakeholders, while not solving all information availability problems, can reduce them significantly and surface them earlier. Agile’s approach can also mitigate “stonewalling” around information that can occur in phase-based, sequential approaches.

The inspection and adaptation potential in daily meetings and regular retrospectives greatly increases the opportunity for, and expectation of, improvement. Reflection occurs close to, if not immediately after, an opportunity to learn and improve. Improvements, then, take place or are identified almost immediately rather than waiting, sometimes months, before consideration of them and any action is taken in a traditional project cycle.

Testing is given first-class status by most Agile methods and test staff are very much expected to be a part of the development team. In this way a quality focus not only drives development work but confirms its success in meeting customer functionality expectations. Agile’s expectation of working software as the primary measure of project progress and success, backed by a strong regression test suite, not only moves concern for quality to the forefront of the project but help ensure that changes can be made with confidence. There is also significant emphasis on test automation in Agile methods.

[A side note here regarding the latter. In 1989-90, I conducted some interviews with many large, technology-based companies in the US regarding the technologies they found most important in addressing quality. I asked what 3 things, if they were denied use of them, would have the most negative impact on their development work/quality. Two of the things mentioned most frequently were automated source code control and automated builds. Today, these two are almost always found present in development organizations. The third thing mentioned was automated regression testing. Interestingly, today, test automation is still a subject of much concern, even after 20 years.]

With regard to vendor performance, Agile Values and Principles do not directly address the issues noted. However, Agile’s team structure, communication expectations, collaboration emphasis, and success-focused contracting all provide a basis for working more effectively with vendors as with other participants and stakeholders. At the very least, an Agile approach will surface the issues of everyone’s performance from the very beginning of the project and offer the potential for a more constructive, early solution to problems when they are far less costly to address.

[One thing I have personally noted in working on some large, distributed efforts, was the lack of Agile experience of and training offered to off-shore teams. I believe this was because, at least in those instances, the on-shore company making use of off-shore, contract staff had been working with the off-shore companies in traditional project situations for many years and just stayed with them. The problem was the lack of training off-shore folks were given though many on-shore people went to some level of Agile training. More than once, as a consultant myself, I was asked to train off-shore personnel when their lack of experience/familiarity with Agile methods became clear.]

A final Part 8 will be posted within the next few days where I look back on the first 7 parts and make some summary comments.