Common Project Risks and Agile Mitigations, Part 8, Epilogue

Part 7 closed out the discussion of issues that the various sources identified as contributing to project failure. As promised at the end of that Part, this Part looks back on the first 7 parts and offers some summary comments. I’ve also added some further bibliography entries that I encountered them while doing this series. While they were not used to compile the list of failure issues, they do discuss project failure issues.

As implied in Part 1, the series was inspired by my having reviewed a number of surveys and articles on why projects failures occur. It seemed to me that the Agile Values and Principles, if adopted using a number of generally accepted Agile practices and techniques, could mitigate many of these issues. While an Agile approach cannot pretend to solve all the identified problems, its communication and feedback model for team-based work is far more likely to surface and deal directly with such problems when they are usually less severe and less costly to address.

However, these project failure risks have existed, in some cases, for decades. People have been dealing with them long before the Agile Manifesto was created. Over the years, the failure rate has been declining, as some of the source surveys have noted. The recommended solutions have been codified in various bodies of knowledge (e.g., PMIBoK, SWEBoK, CSQE BoK), models (e.g., CMM®/CMMI®), and standards (e.g., ISO 9001, IEEE S2ESC, ISO/IEC JTC1/SC7). These approaches to the problems have been (often unfairly) characterized by voluminous documentation, significant cost, and bureaucracy. Agile methods have (equally as unfairly) been characterized by applicability only to small, low-risk efforts. The BoK, models, and standards approach is a reflection of what people believe to be currently understood “best” practices derived from those used in other (non-software) engineering and project domains. Agile methods reflect the view that a less complex, less prescriptive approach is possible which relies less on detailed process guidance and more on process transparency and person-to-person communication.

What is interesting, however, is the position often taken by both approaches with regard to why projects employing them continue to have problems. From a phase-based, sequential project perspective, the view is that such problems can be avoided if only project personnel would follow the existing, accepted, and well-defined project management and software engineering BoKs, models, and standards. That is, projects fail because people do not follow known methods and procedures effectively, i.e., they do not carry out such guidance “right.” Interestingly, when an Agile project is not successful, we often hear the same things, i.e., it failed because people did not do Agile (or a specific method) “right.”

So the question, in either case, is: can it merely be a matter of doing what is predetermined to be “right,” whether traditional or Agile? And, why is it so hard to do what is “right” to achieve the results expected from doing so in either case? Proponents of an Agile approach say the BoK/model/standards approach suffers from too much overhead, inapplicable detail, and inflexibility causing an inability to respond promptly to the circumstances and changes that lead to failures. Proponents of the BoK/model/standards approach say Agile methods suffer from ad hoc behavior, short-term thinking, and transfer of significant risk responsibility to the business and customers.

What may be most true of either approach is that a formulaic application of their practices and techniques, with insufficient knowledge and understanding of their basic principles can produce an inflexibility (or inability) to respond when circumstances require. It may be that the “best” approach would be to ensure that the guidance in the BoKs, models, and standards is understood by those working on projects, but that the Agile Values and Principles are used as the structure within which to apply that knowledge.

Related Bibliographical Items

• Ellis, Keith, Business Analysis Benchmark – 2009. IAG Consulting, 2009. http://www.iag.biz/register.html (free, but must register with an email address)
• Pedersen, Alf A., “Project management failure - Why projects fail,” from his Database Design Resource website. http://www.databasedesign-resource.com/project-management-failure.html
• Software Engineering Institute, Insights on Program Success, A Joint Publication of the Software Engineering Institute and the Systems and Software Consortium, Inc., October 2009, CMU/SEI-2009-SR-023. http://www.sei.cmu.edu/reports/09sr023.pdf
• Ward, J. LeRoy, “What Troubled Projects Are Costing Us,” from PMStudent blog (Josh Nankivel). http://pmstudent.com/what-troubled-projects-are-costing-us/
• Winters, Frank, “The Top 10 reasons Projects Fail,” a 13-part series from Gantthead.com. Part 1 is at http://www.gantthead.com/content/articles/147229.cfm with links to all other parts.

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.

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.]

My First “Agile” Experience in the Early 80s

Of course, it wasn’t actually Agile according to any currently understood practices and techniques. But it did have aspects of some of the ideas now viewed as Agile and was the experience that came to mind when I first read Kent beck’s 1st edition of eXtreme Programming Explained. I’ll describe the working environment, the product (a bit) and how we interacted. You can judge for yourself where the experience fit on any scale of being or not being Agile.

We were doing a commercial 4GL product (non-procedural language and associated database) known as RAMISII. It was written in FORTRAN and IBM 370 assembler so, of course, ran on IBM mainframes. There were 9 of us in the development group. Two focused mainly on the database code (and an access module to IMS DB/DC so the “language” could do reporting from those databases as if they were our own database). Two did “support” and non-development (regression) testing. So five of us worked on the language/reporting side. There were also a couple documentation folks who worked under the Marketing group which had 4-5 other folks in it. Marketing was our internal “customer,” though we never used that term or really thought of them that way formally.

Once year, after relational databases started catching on but before DB2 was big in the IBM environment, it was decided we would redo the reporting/language side of the product to add substantial functionality, including language constructs to allow relational operations for reporting extract purposes. Since we were going to change some 70% of the system, it was also decided we’d get rid of all the FORTRAN and replace it with Assembler. That’ll give you an idea of the technical scope of what the five of us would tackle over the course of 9 months or so. The 9 month target was because it was early summer and the next major customer gathering/conference was the next Spring, so we needed to have a major release ready then as we did each Spring.

[An aside on why assembler and not C, Pascal, even PL/I. We had to stick with languages that IBM was currently supporting on mainframes and an IBM C compiler was many years away at that point. But we could have used PL/I except that, at least back then, there were dynamic libraries associated with it that the customer would already have had to have, i.e., they had to be using PL/I, to then run our delivered system. Or the customer would have to license those libraries separately from IBM. Or we would have had to license them and pay IBM for each copy of our system that we released with them. Company senior management did not want to get involved with any of these concerns. So no PL/I.]

As to our environment, besides just saying it as assembler and IBM mainframes. Our (two) machines were mid-sized mainframes running VM/CMS (a virtual memory system that allowed each of us to feel like we had a machine all to ourselves). We worked on, wait for it, TI Silent 700s, i.e., thermal printer terminals. No CRTs as it was before even 3270s were widely used. (A year or so later, we had to get into supporting 3270 full-screen, but, at that time, it was command-line interfacing.) Each of us had our own private office in a nice building in the suburbs of Princeton, NJ. Of the five of us, 3 were relatively new to the company (<1 year), one was just a bit over a year, and I had been there between 2-3 years. (The database access and support folks were more senior than I.) Everyone, save one very junior person, had several years of experience at that point (i.e., 5+ at least) in IBM or Honeywell mainframe environments with assembler (and other languages).

Our immediate bosses were really fine folks with development experience from an operations research background. There was no obvious hierarchy among us. (Indeed. while I was there, I was "promoted" 3 times and never knew it.  It never affected how I related to or was noticebly viewed by anyone, at least as far as I could see.) We each, and our managers, valued good ideas and enjoyed one another’s ideas as there was always lots of room for people to contribute. The product was thousands of lines of code.  I can’t remember exactly how big but we had some 50-60 uniquely named FORTRAN and assembler modules that ranged from a couple hundred to a thousand lines each. Back then, it was a large footprint product that employed dynamically loaded overlays to limit memory use.

That summer, those of us in development spent a month or so determining every module we felt we’d have to touch based on some very high-level specs from Marketing. These specs came from the last Spring’s meeting where customers would annually “vote” on the features they wanted from a long list compiled from everything they all had been submitting for the 6 months before that. As this was pre-32 bit addressing, we also had some decisions to make about how to restructure our pointer approach for our report record sorting. One of the features desired was the ability to print summary data before all the data actually printed on the page, so we had look-ahead selection and calculation issues to deal with so we could create, carry and sort summary data records within the detailed records.

I have no recollection of how this started, but near the end of the summer, we started having regular meetings with the Marketing and documentation folks to flesh out functionality in more detail. We never had a formal requirements spec, but the user/support manuals became our “spec” as were interactively decided on features, new language syntax, etc. We would not have new functionality to show at each meeting, but we had ideas to present and questions to cover so Marketing and documentation knew, throughout, what we were up to and what it was going to look like. (Being syntax and command-line focused helped a lot since we did not have GUIs and full-screen formatting to worry about.)

After a couple months, though, we did have features to show since we had updated/rewritten enough to have threads of functionality able to work. We could also start testing functionality, at least within development, though we were also sharing what we were doing (as was Marketing and documentation) with the support group so they could work on tests at their level to incorporate into the test suite. (We would give them ours, but they’d always enhance them and then move them into their large test suite where they thought the new tests would work best with existing test cases.)

As we saw how our design ideas were working out, we began to offer to Marketing ideas we had on features, related to ones clients had requested, that we felt could “fall out” of work we were doing with little or no additional effort. If Marketing liked them and management accepted our evidence that it would not impact the Spring client meeting demo date, we’d put them in. An example of this were various summary calculations and totals we saw we could add if Marketing felt they’d be useful to clients. In some cases, we suggested ideas the clients had literally suggested but which were lower on the voting list than ones the Marketing identified as committed to the release. So, as we began to announce what features would be in the release, end customers were really happy to see everything they had voted for making it as well as other things they had not expected we would deliver.

A couple months before the meeting, all the functionality was done as was all the user documentation. Actually, the documentation had been settled upon a month before that. The doc folks were just doing their own formatting and example insertion work. Examples often came from our test examples.  In deed, tests we used often came from ideas Marketing had for typical user request streams. During the last two months, we started working more with performance improvements and internal structural changes. No new functionality was being worked. All defects found during that time were due to internal issues and had no functionality impacts, i.e., no missing or misunderstood requirements.

At the Spring meeting, customers seemed really excited by the work we had done. They loved all the functionality as well as hearing, despite all that was added, that both memory footprint had been reduced and performance had been improved. There was also an explosion of functionality ideas from clients coming out of the meeting. (As the formal release date was early summer each year, we were able to incorporate a number of these successfully before the actual release, so clients did not have to wait a year for them.)

In the process of making all these changes, we introduced no major defects and, in fact, found two serious defects that had been plaguing us on large reports and on customer system configuration changes, i.e., whether they allocated dynamic memory above or below the base load address of the main system modules.

We never had a name for how we operated. It clearly wasn’t “Agile” in many aspects, but I think we hit every Manifesto Value dead on and several of the Principles.

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.

And More Quotes From Twitter

A fourth installment of interesting things I've captured from Twitter that people have said (including some of my own) either individually or as part of a thread of discussion (again sorted by first name):

Alan Shalloway - biggest difference between adopting Lean now from adopting agile 10 yrs ago is customers r now more open-minded than th consultant community

Bob Marshall - Common insight from Reinertsen, Goldratt, Seddon: Manage *queues*, not schedules, capacity, efficiency or costs.

David Hussman - Detailed requirements are poorly written tests or what I call "tests in disguise".

David Hussman: Project communities are bonded by common goals not by percentage of availability on org charts.

Declan Whelan - I tire of people saying we were successful w/o agile as if success is binary. Agility fosters the ability to expand success.

Eric Hoffer (via Steve Freeman) - “Every great cause begins as a movement, becomes a business, and eventually degenerates into a racket.”

Gloria Steinem (via Suhas Walanjoo) - The truth will set you free. But first, it will piss you off.

James Bach - 3-word critical thinking process: Huh? Really? So? (question meaning, then question fact, then question significance)

Jason Gorman - 1. Hire good programmers. 2. Give them clear goals. 3. Give regular constructive feedback. 4. Stay out of the way!

Jason Yip - Isn't it kind of weird that Japan has a Deming prize and the US has a Shingo prize?

Jean Tabaka - Scrum vs Kanban vs other systems/certification debates distract vs focus. Continuous systems improvement jazzes me. Pick & focus.

Marcin Niebudeck - What I find the most difficult in #agile transition is not the legacy code, but the legacy people. For legacy code we have already good engineering techniques from #xp. What do we have for legacy people?

Mark Twain (via Will Green) - Never argue with an idiot. He will drag you down to his level and beat you with his experience. Scott Duncan - A variation "Never argue with an idiot. Onlookers may not be able to tell the difference." Both from Twain, I think.

Niklas Bjørnerstedt (via Kent Beck blog) - A good team can learn a new domain much faster than a bad one can learn good practices.

Scott Duncan - I am just not convinced the way to combat dysfunction is with more easily dismissed forms of dysfunction.

Scott Duncan (From the movie "Nightwatch") - "It's easier for a man to destroy the light within himself than to defeat the darkness all around him." (Anna Nachesa said the actual translation from the original Russian is: “It's always easier to put out the light within yourself than to cast away the darkness outside.”)

Tim Ottinger - I think that the agile motto should be "Building a better next week."

Timothy L. Johnson (via Josh Nankivel from Twitter)- Changing the world, surprisingly, looks a lot like living your life... day to day... with purpose... with focus... and with love. And there are days when looking at yourself in the mirror at the end of it all... and smiling... is really the best accomplishment. (28 September 2009)

Tobias Mayer - Scrum & XP are incomparable. Scrum is a framework for organizational change, XP for individual craftsmanship.

Unknown (via Kim Coles) - "The world is so fast that there are days when the person who says it can't be done is interrupted by the person doing it.”

Vasco Duarte - My def: "a method scales iff the effort needed to manage "things" grows at a slower rate than the number of "things"."

Will Rogers (via Ainsley Nies) - “Even if you're on the right track, you'll get run over if you just sit there.”

William W. (Woody) Williams - Highly motivated, productive people working in the wrong direction do huge damage in a short time.

Willie Colon (via Roy Atkinson) - The capacity to learn is a gift; The ability to learn is a skill; The WILLINGNESS to learn is a choice.

Yves Hanoulle - "A shared vision is about shared state, not about a shared statement."

Common Project Risks and Agile Mitigations, Part 4, Project & Risk Management

Part 3 addressed the topic of creating an initial plan (i.e., planning and estimation). This part will address related categories of issues that can lead to project failure: project and risk management.

Project Management Related Issues

To hearken back a bit to the last part, consider some thoughts from Tom DeMarco [May] in noting how a “Lean and Mean” emphasis in companies has “goaded” managers and staff into unreasonable estimates and the need for overtime work. “Any failure will be viewed as a direct result of underperformance,” DeMarco says. However, underperformance is “not even a significant [project failure] factor” for most projects compared to simply having initially unattainable goals.

Now consider some remarks from Ed Yourdon, quoted in [May] saying, “Nobody seems to acknowledge that disaster is approaching” even when they recognize it. “There is no early warning signal.” May goes on to state Yourdon’s belief that, “Until more organizations abandon waterfall-style development in favor of processes that demand early working code or prototypes…this scenario will continue to be familiar.”

The particular issues related to project and risk management mentioned in the various survey sources include:

• Failure to apply (or understand) essential project management techniques and/or project control systems (e.g., tracking, measurement).
• Inadequate visibility of progress (not just resources used) generally due to status reporting being misleading (e.g., generally more optimistic than pessimistic) or not having effective means of tracing a software development from requirements to completed code.
• Not proactively managing risk or basing actions on “catching up” later (e.g., counting on overtime to handle contingencies).
• Lack of knowledge of the actual probability of success, late failure warning signals, and reduction in resources needed for the project.

The first of the issues noted above argues for traditional project management capabilities being needed. Yet, though such capabilities might, on the surface, be present, the latter three problems could still occur because of the things DeMarco and Yourdon mention. Part 3 mentioned some ways to try to address DeMarco’s concerns. In this part, Yourdon’s concern should also be addressed.

Applicable Agile Values and Principles

Again, all the Agile Values and most of the Principles seem to apply in one way or the other.

The first problem noted above could just as easily be an issue in an Agile project if the techniques and principles for how to conduct one are either not applied or understood. The key in an Agile project is that these techniques are very near-term, direct and based on visible indicators of what is happening every day rather than at weekly/monthly status reporting occasions. This promotes the Agile Principle of simplicity, especially in process and tools, applied to project management by taking advantage of close, regular communication among project stakeholders and regular reflection on and adjustment to plans and project conduct. Because of all this, an Agile project will not engage in “Project Management Chicken” where everyone waits to see who will be the first to have to admit they are behind schedule.

Another important concept is how Agile projects measure progress based on working software rather than tasks accomplished. While it is true that an iteration burndown may track task, the ultimate measure of success will be completion of the committed to functionality and its acceptance by the customer. This is Agile’s “highest priority” and, as in planning, employs short timeframes (e.g., a few weeks) as the cycle for ensuring project direction meets customer expectations. And, as the demonstration of achievement of iteration goals is a very visible event, surprises are very unlikely if stakeholders maintain involvement with the team(s).

Finally, as noted in Part 3, planning is organized to make changes easier, less costly, and very visible. Agile project management, then, is focused on how to best respond to change and address risks right away. Indeed, a risk-based approach to managing projects is very much in keeping with Agile principles. However, rather than try to defend against change and risk, Agile projects take advantage of the near-term focus and visibility to accommodate change and surface risks early. (Jim Highsmith has some good advice related to what he calls a “Planning and Scanning” approach to managing projects, encouraging us to “expand our anticipation practices to include both planning (working with what we know), and scanning (looking ahead to learn the unknown as quickly as possible).”)

Regarding surfacing issues early, I have experienced managers responding to an Agile approach with the feeling, at least initially, that all they hear about day after day are the impediments the team is dealing with and the issues that need to be addressed. However, after a while, they see that these are issues that usually get dealt with immediately and which go on all the time, but are often not made visible in traditional projects. It is the visibility of the issues that initially produces the discomfort but, as time progresses, then produces greater confidence that teams are managing work well and ensuring stakeholders are kept informed. In this way, if large issues emerge, they are recognized earlier and addressed more promptly. This does not necessarily make them automatically easier to deal with, but does mean you’ll be dealing with them earlier, rather than later, increasing the likelihood of dealing with them at the least cost to the project.

Common Project Risks and Agile Mitigations, Part 3, Planning & Estimation

Part 2 covered issues related to requirements as the number one issue plaguing projects. This part will address two of the next most frequently mentioned category of issues that can lead to project failure: planning and estimation. Planning was the next most frequently mentioned category, but estimation, which is highly related to planning, was also high on the list. Therefore, these two have been combined to be discussed together.

Planning & Estimation Related Issues

As with requirements, the fact that planning is a problem area should come as no surprise. Making plans, getting agreement to them, managing the project using the plan, and making changes to a plan all involve substantial effort. Later, project management will be discussed. But, for this post, the focus will be on creating a plan.

The particular issues related to plan creation/initiation mentioned in the various survey sources include:

• Allowing a plan to diverge from project reality, or to be created which diverges from that reality in the first place, due to lack of estimation experience, estimation under pressure, rejection of reasonable estimates (usually resulting in underestimation), ignoring the obvious (e.g., back-of-the-envelope calculations), and/or not revising plans if scope changes.
• Failure to plan, adequately or at all, to consider all project activities, to address risk management, or to inadequately document decisions and commitments (leading to later disagreements, disappointments, and costly rework).
• Infrequent project milestones (i.e., project "chunks" too large), allowing too much time to elapse between opportunities to validate that work done meets intended needs.

A telling comment from Watts Humphrey (as quoted in [May]) is that “any plan [project managers] put together won’t meet the [desired release] date, so they can’t plan.” Additionally, May asks states, “It is unfair to call a project a failure if it fails to meet budget and schedule goals that were inherently unattainable. Attempts to circumvent a project’s natural minimum limits will backfire. This problem occurs any time someone ‘makes up a number and won’t listen to anyone about how long other projects took,’ said Capers Jones.”

There are also famous quotes (mostly from the military) about planning and what happens when plans start to be executed such as “a battleplan never survives contact with the enemy” and “plans are not important, but planning is everything.” Interestingly, the formality, rigor, and hierarchical control structure of the military is classic, but the military also realizes how important it is for the people on the front lines to be prepared to inspect and adapt. Remember Clint Eastwood’s comment as Gunny Highway in “Heartbreak Ridge” regarding plans and response to situations in the field: “Improvise. Adapt. Overcome.”

Applicable Agile Values and Principles

As with the requirements category, most of the Values and Principles also seem to apply to planning and estimation.

The key in Agile-based planning (as with requirements specification) is simplicity born of close collaboration with the stakeholder(s) and frequent validation that work is meeting needs. Because of the iterative and incremental nature of an Agile approach, detail is reserved for the near-term with progressively less detail the further out the planning goes. This approach is taken to reduce the initial cost of detailed plans which, in all likelihood, will be changing anyway.

Because of this willingness to change plans if stakeholder needs and priorities change, Agile planning (and validation of the planning), as an activity, occurs frequently (i.e., daily, every few weeks). In this way, the plan will not diverge far from reality, can be adapted easily when changes occur, and will not consume significant effort to maintain. Most importantly, all planning is based on the regular, frequent delivery of working functionality as the basis for assessing the validity of the development activity.

Common Project Risks and Agile Mitigations, Part 2, Requirements

As noted in Part 1, this series is intended to “identify the various reasons cited for project problems and suggest how elements of an Agile approach might minimize the risk of them occurring.” That first part set some background to where the categories of project difficulty have come from and identified a list of some 17 such categories. A number of the latter categories mentioned far less often in the sources of failure data and observations. So I’m going to cover the categories from most to least frequently cited in the belief that’s how people would like to see the parts in this series emerge.

This part will address the most frequently mentioned category of issues that can lead to project failure: requirements.

Requirements Related Issues

It probably comes as no surprise that requirements related issues are at the top of the list. After all, there would be no project unless someone felt a need to have some work done; however, problems eliciting and defining requirements “completely” are likely no surprise. The traditional phased-sequential process expects someone to explain everything they want, analysts to translate that into formats (often text-based) understandable to all others who need to know, and rigorous control over changes. This is aggravated by the fact that many “someones” (i.e., stakeholders) may be involved. (Stakeholder issues related to project problems are covered later in this series and, no doubt, contribute to requirements being at the top.)

The particular issues related to requirements mentioned in the various survey sources seem to fall into two groups:

First, late discovery of information that was assumed to be true or was not known when work began.

• Discovery that there is no more need for certain requirements (or the system as a whole) to be developed.
• Late recognition of the seriousness of requirements repercussions.
• Mid/late-development changes in requirements and scope.

Second, misperception in what could be expected and how satisfaction of expectations would be determined.

• Inadequate acceptance criteria, which results in "poor-quality" delivered software.
• Incomplete, ambiguous, inconsistent, and/or unmeasurable requirements (and other project objectives).
• Unrealistic Expectations.

One could look at this list and also say the items are communication problems. That is, inability to be capable of communicating what is needed early enough to avoid the problems described. That would be true enough. But it is also clear that change constitutes a good bit of the concern over the role of requirements in project problems. Finally, it seems that “knowledge” is another possible theme. All of these are focused here on requirements and contribute to project instability of one sort or another.

A couple of things are suggested by the above two groups of issues. In the first, much effort is usually expended based on assuming, one way or the other, that the information available after “due diligence” has occurred is, in fact, accurate. In the second, even without significant change, if criteria for assessing satisfaction of requirements are inadequate or applied only after much effort has been expended, disagreements are likely as to whether the result satisfies what was intended.

A large, up-front investment in very detailed descriptions of functionality and stringent change control procedures are often not justified by later project occurrences and lead to both of the difficulties noted above. We are asking much of stakeholders to insist they can, and should, be fully explicit up front and incur large costs when changes become necessary. However, knowing this, stakeholders must acknowledge that to avoid such problems both regular, direct communication and effective prioritization of requirements will be necessary on their part.

An interesting remark comes from Watts Humphrey [May] who has said, “You can’t design a process that assumes [requirements] are stable” so “learning what the requirements really are while building the product” should be expected.

Applicable Agile Values and Principles

When it comes to this category of issues, every Agile Value and most of the Principles apply.

From a change perspective, an Agile approach seeks a development process designed to adapt to, rather than resist, change. It does this by focusing on working software rather than documentation as its measure of achievement. This does not mean all documentation is rejected, just that it be kept as simple and direct as possible in leading to working software.

Up front specifications are kept simple (e.g., stories) with stakeholder involvement used to replace extensive documentation passed from one person/group to another. Given short iterations and frequent demonstrations of working software, simplicity and brevity in specifications is possible. Simplicity in requirements is also achieved through emphasis on the importance of test cases as executable requirements specifications. Hence, less is written in static text/diagrams and more in executable scripts.

Given that individuals on a project (e.g., developers, testers, product owners, etc.) work on effective, direct interaction between one another (on a daily basis), collaboration can replace extensive written specifications. Then, with software demonstrated and delivered within a few weeks of the start of the work (and every few weeks after that), there is significantly less chance that stakeholder expectations and development work will diverge greatly before a correction can be made.

This last point is an important one in reducing the cost of change and addressing the concern that full, up-front specification is needed to prevent disappointments at the end of the work. An Agile approach seeks validation of all aspects of the work on a frequent basis: every few hours, every day, every few weeks.

All of this, combined, does not guarantee changes will not be required that can be costly. Nothing can do that unless change is prohibited from occurring completely. In some cases, that may be possible, but usually only if the time from beginning of work until the end is short anyway. What an Agile approach can ensure is that change impacts, possible requirements misinterpretations, and issues of dissatisfaction with functionality can be identified early and resolved as inexpensively as possible, all without significant cost having been incurred until such things are discovered.