Common Project Risks and Agile Mitigations, Part 5, Technology

Part 4 addressed the topic of creating an initial plan (i.e., planning and estimation). This part will address a category of issues that can lead to project failure which was surprisingly high in the number of times mentioned: technology.

Technology Related Issues

The particular issues related to technology mentioned in the various survey sources include two types. The first is application technology, revealing itself through

• Complex technical details (often hard to recognize or address early in a project)
• Lack of sufficient technology competence to address the complexity.

The second is development process technology, revealing itself through

• Poor up-front (inflexible, inadequate) architectural planning
• Lack of effective, practical ways to show one approach is better than another.

Another item also mentioned in connection with these was that technical decisions may be made by people without expertise in the domain, but with the managerial authority to make those decisions. One could argue that that this is not a technology matter, per se, as non-technical decisions could as easily be made under the same circumstances. But it was mentioned, so I wanted to note it.

Applicable Agile Values and Principles

The Agile Values and Principles that seem to apply are those associated with individual & team performance and design approaches as well as frequent software delivery.

With regard to application technology, if a commitment has to be made early to such directions before other work occurs, such commitments, if “wrong,” will unquestionably have a strong, negative impact on project success. The Agile approach is characterized by two phrases often seen in Agile literature: making decisions at “the last responsible moment” and focusing on “the simplest thing that could possibly work.” Key here, of course, are “responsible” and “could possibly work.” While Agile “embraces change” and seeks to “inspect and adapt,” that does not mean things are done ad hoc. It would be irresponsible not to make decisions using the best information possible, at that moment. However, to make progress and gain more information usually requires moving ahead, incrementally, at the point when a decision must be made (“the last responsible moment”) using that information in the most direct, clear manner known at that time (“simplest thing that could possibly work”). (Naturally, in a very complex domain, “the simplest thing” is still going to be complex, but likely better to deal with than a more complicated complex thing.)

Regarding technical competence, especially in software, it can be quite difficult to assess because the evidence is often buried within the code and not obvious, especially in phased, sequential efforts, until very late in the project schedule when various pieces are integrated into the larger system. Agile techniques such as collective code ownership, pairing and general visibility within the team are one way this information can be revealed sooner rather than later. Also the Principles of commitment to continuing technical growth and regular reflection on how to work better provide a path toward increasing individual, team and project competence on a regular basis.

These latter Agile techniques and Principles apply equally as much to the issue of development process technology, including architectural planning. There is always the question of how much up front work is necessary before useful progress can begin. The answer is usually less than might otherwise be expected if working software is delivered early and frequently thereafter since there will be concrete evidence of what “works” and what does not. In a complex project, what this will require is close communication between any architecture groups and development teams and a willingness of the former to work iteratively and incrementally rather than in a purely phased, sequential manner.

This latter point is often the most challenging organizational issue faced early in an Agile adoption effort since adoption efforts often start within development teams, perhaps with some test participation, but often without direct involvement of other technology-based teams. Architectural teams are one; configuration and change control teams are another; very often build and deployment teams are a third. Failure to incorporate these areas into the Agile effort can produce, at best, delays and limitations on the velocity achieved by teams since other groups usually work in a less iterative manner. They will engage in more up-front planning, expect less frequent changes and follow well-defined timelines for availability later in a typical project cycle as they do for non-Agile projects.