Real World Agile Development:

The Promise, The Problems, and The Practice

An SW Complete Perspective, January 2008

The Promise of Agile Development

Agile Development has received considerable attention lately because of the promise to deliver greater responsiveness, reliability, and customer satisfaction. Unlike more traditional methodologies, the emphasis of Agile Development is on:

  • self-organized teams of trusted, motivated individuals,
  • frequent delivery of usable software,
  • continuous testing, and
  • direct interaction between developers, management, and customers.

These are accompanied by a corresponding deemphasis of:

  • rigid and unrealistic schedules,

  • cumbersome and inflexible processes, and
  • burdensome and unnecessary documentation.

SW Complete's experience with Agile Development has convinced us that this is not just hype. Agile Development techniques free talented developers to do what they do best, while providing management and customers the feedback to know the effort is succeeding. We have been able to use an Agile Development approach to jump start new development efforts, and rescue projects that were trapped by antiquated processes, aging code bases, and stifling bureaucracies.

The basic principles of Agile Development are readily comprehensible, easily adopted, and immediately justifiable via concrete results. There are several variations on the Agile Development theme to choose from, including: Scrum, Extreme Programming, and Feature Driven Development. Each shares common characteristics and has provided real world success stories, and yet Agile Development has not achieved wide-spread acceptance in the software industry. In fact, it receives criticism from many respected authorities.

So what's the problem?

The Problems with Agile Development

While we agree with the Agile Development philosophy in principle, the implementation typically encounters several problems. These include:

  • Acceptance. Experienced developers, managers, and customers aren't blank slates to simply be reprogrammed, and Agile Development is likely not the first new approach to be sold as a panacea. To be accepted by developers, it can't be imposed as a rigid methodology. Moreover, there are numerous other stakeholders (acquisition managers, program managers, testers, field support personnel, and end users), each with different goals and agendas. The case for Agile Development may be easily made to developers, but the benefits to other stakeholders are perhaps not so readily apparent.
  • Coordination. Agile Development's assumption of small development teams in close contact with management and customers is often wishful thinking. Management and customers often lack the required availability through no fault of their own. Development efforts rarely exist in isolation, but are part of larger programs with overarching schedules, budgets, milestones, and other constraints. This requires associated development efforts to be distributed across multiple teams, sites, and functional areas. The direct, informal communication defined by Agile Development does not automatically scale well across diverse environments. Additionally, access to subject matter experts or integration test environments may be severely limited, requiring more formalized coordination.
  • Commitment. Any paradigm shift is a long term commitment. Like trying to diet or to quit smoking, it is easy to fall off the wagon. Due to past frustrations, the trust and patience of management and customers may already be in short supply. The necessary developer training and code refactoring require time and funding that are either limited or are contractually inaccessible. And it is hard to overcome the sense that tomorrow's fix can't get in the way of today's fire drill.
  • Instability. Despite its stated tolerance of requirements changes, Agile Development requires a relatively stable external environment. Enterprise-wide direction changes can easily derail small projects. Deployment platform or integration framework changes can cause substantial rewrites that are disruptive to users who are preoccupied with evolving missions and site-specific needs. Within the project team, personnel turnover results in loss of project history and the need for developer retraining. A self-organized team is only productive when its membership is stable. Likewise, turnover in management or domain experts may result in completely redefined processes or requirements, respectively.
  • Inertia. Big organizations, legacy deployments, monolithic organizational infrastructure, and long funding cycles tend to produce a very persistent status quo. Fielded versions of applications must be maintained indefinitely. Familiar, ingrained formats for management data and communication cannot be abandoned overnight. Incentives created in conjunction with existing processes are often institutionalized. If the benefits of a new approach are not quantified, they will be overshadowed by the perceived costs, and no change will be accepted.

The Practice of Agile Development

In order to address the problems listed above, the successful practice of Agile Development begins with acknowledging these simple truths:

  • Every perceived problem cannot be fixed at the same time, and some will never be fixed.

  • You can't manage what you can't measure.
  • If it isn't accessible or understandable, it won't be used or maintained.
  • Relying on clairvoyance and telepathy is never a safe bet.

These truths are implied in the criteria we use to judge all project activities and decisions:

  • Impact. The backlog of features and tasks are prioritized based on the positive and negative impacts on users, code stability, funding, and milestones. The "bang for the buck" and "no free lunch" cliches live here.
  • Validation. In a test-driven approach, requirements are defined in terms of the tests required to validate the end products. Code that is designed to pass those tests will inevitably provide more traceability and reliability.
  • Clarity. Making requirements, design, and code simple, transparent, and self-explanatory is a primary goal, not an afterthought. Traditional methodologies rely on strictly formatted documentation that is superimposed on the development process. Agile Development, in contrast, relies on the natural artifacts of the process and tools. Thus, the focus is on clarity of the work products, not the volume of documents.
  • Flexibility. Tasking and decisions must serve a purpose; however, that purpose involves not only the immediate usefulness but also an ability to adapt to future needs. This implies a focus on the big picture and an effort to anticipate. Flexibility is often favored over short term, small-scope optimality. While it may be impossible to predict the future in detail, trends and probable scenarios should be taken into account when prioritizing tasks and defining features.

It should be obvious that these criteria are not in conflict with Agile Development. It is important to note Agile Development is not a methodology in the traditional sense. Its concepts can be implemented as heuristics and tactical process improvements rather than rigid prescriptions. Thus, Agile Development is adaptable to existing processes and other methodologies. This is good news in that we are often not in control of those choices.

The SW Complete version of Agile Development, known as HighTest, comprises the following practices:

  • Testing is the central, focal activity. Requirements are defined by tests. Designs are defined in terms of passing the tests. Coding is not considered complete without passing the associated tests. Testing, in this sense, refers not only to unit test code but also to other forms of validation, including user acceptance criteria and project performance metrics. Metrics collected over time provide a basis for more rational planning and estimation.
  • Composability of the software is a primary goal. The overall application model is not domain-specific but aimed at facilitating the composition of domain-specific components and platform-specific services. This allows the model to remain intact as the domain and mission evolve. Pluggable components can be retooled or replaced to keep pace with changing requirements and advancing services. When done right, composable code becomes a direct representation of the requirements, and reuse of generic services is promoted. Clarity and flexibility are simultaneously increased.
  • Configurability increases flexibility, responsiveness, and applicability. The more configurable the software, the better. Specific components assembled via generic models lend themselves to configurability. Configurable software can be tailored to individual site requirements without negatively impacting version control or deployment activities.
  • Automation is both a source and a measure of productivity. Tests, analysis, and documentation that are automated are repeatable, painless, and another source of self-documenting transparency and metrics. If you're going to do something a second time, try to automate it. Development and management tools, though never a substitute for good practices, enhance and simplify the software process. For almost every proven practice, recommended activity, or repeated task, there will be a tool to make it more reliable and repeatable. This is certainly true for testing, tracking, documentation, and configuration management.
  • Incremental development empowers both developers and customers by reducing the cost and risk of development of each iteration. In conjunction with continual testing, it leads to software that is always deliverable and demonstrable. The backlog of requirements becomes more manageable. Small increments provide the flexibility to adjust to an evolving mission. Project performance becomes readily evident in the improvements to the working code at frequent intervals.
  • Incremental process improvement allows Agile Development to be mixed into existing processes with minimal impact or resistance. Tools, automation, and better practices are added in small steps, and can be adapted for use with legacy projects. Task tracking and unit testing are particularly easy to add incrementally.

Benefits

  • Acceptance. Increased understanding and measurable success are the keys to acceptance. Automation and testing yield metrics to improve estimates, validate performance and insure requirements are met. Incremental process improvements reduce resistance from all stakeholders by reducing costs, risks, and schedule impacts. Tools for testing and task tracking produce natural, comprehensible artifacts instead of laborious documents.
  • Coordination. Composable software facilitates distributed development while minimizing the impact of infrastructure churn. Explicit validation criteria provided early and maintained continuously provide the focal point for coordinating stakeholders even as mission and priorities evolve. Metrics from testing and tracking tools provide the basis and justification for schedule and requirements changes. Incremental improvements to software within controlled test environments promote continuous feedback from users.
  • Commitment. Incremental improvements to application code and development processes require minimal commitment from management or customers while also promoting confidence. Automated tests help to insure that quick responses to requirements changes result in working code, thereby reducing the tendency to stray from best practices when quick turnaround is demanded. Generic composability models help to reduce the need for both user and developer training.
  • Stability. Composable models are naturally service-oriented. Configurable interfaces are manageable interfaces that reduce the cost and risk associated with even large modifications to enterprise infrastructures. When automated testing is included in configuration management, the result is a regression test capability. This, along with the project history provided by task and requirements tracking tools, reduces the impact of turnover.
  • Agility. In a discussion of something called "Agile Development", the word "agility" had better show up eventually. Agility is the ability to succeed in the face of evolving mission, advancing technology, and heterogeneous user requirements. Following the principles and practices described here can provide the necessary flexibility without sacrificing clarity of purpose or confidence in results. While we have succeeded in rescuing projects through the incremental adoption of these practices, Agile Development works best when it is promoted throughout the enterprise beginning with the planning and acquisition phases, and incentives for all stakeholders are aligned with these principles.