Standing Up For Agile – People, Process, Technology

In my previous post, I suggested that Agile’s success is rooted in the creative responses that result from embracing continuous feedback and satisfying the right customer needs.

In this third and final part to the Standing Up For Agile series, I’ll address Agile’s current criticisms and also take a look at the emerging challenges in software development.

The NaySayers

Since its inception, agile methodologies have been heavily criticized by industry practitioners.  Common complaints include the following:

  • lack of discipline
  • lack of focus towards non-functional requirements
  • doesn’t work for with teams composed of junior-level people
  • doesn’t support thorough architectural design and planning
  • makes scheduling impossible

As a practitioner of agile methodologies, I can relate with these concerns.   The non-functional high-performance requirements on Wall Street represent the types of complex requirements that naysayers claim are not adequately addressed with agile software development efforts.  In addition, it is true that junior-level people lacking the experience and knowledge to make quick decisions in a constantly evolving process add significant risk to the overall result.

Perhaps the real challenge in succeeding with Agile, or any software development process, is understanding the true characteristics of the people, process and technology in the problem and solution domains to be able to tailor an approach that inherits the appropriate elements from the many software development methodologies.

Moving forward, Agile’s popularity over existing methodologies will continue to grow because agile practices are purposely designed to address the key differences between software development versus other engineering disciplines.  The same cannot be said for predictive methodologies like the Waterfall approach.

Standing Up For Agile

Agile acknowledges that many stakeholders don’t know what they want until they see what they don’t want, or see what they would like more of.

Frequent deliverables gives stakeholders something to build on.

Agile acknowledges that requirements change.

Test-driven development focuses junior-team members and provides regression testing capabilities for everyone.

Continuous integration synchronizes parallel efforts, minimizes the time-between-failures, and builds team moral and momentum by promoting an always buildable system.

A system metaphor serves as a figurative construct that unites stakeholders’ understanding of the problem and the solution behind it.

No overtime keeps team members productive, lucid and motivated.

Continuous customer interaction ensures the right customer needs are solved.

Agile, like Computer Science, acknowledges that complexity can be addressed with divide-and-conquer approaches by approaching development as a series of releases each consisting of multiple iterations.

Self-organization attracts the best programmers and project managers who tend to avoid command-and-control organizations.

Daily meetings promote accountability throughout the project’s life ensuring all team members carry their weight.

Refactoring addresses quality issues resulting from minimal planning and promotes frequent deliverables.

Pair programming drives up productivity and quality of code.

Collective code ownership promotes coding standards, improving code maintainability, facilitating moving people around and pair programming.

Looking Ahead

For better or worse, the reality is that more and more software development is occurring in virtual teams.  For Agile to continue to grow and mature it must successfully address the challenges of software development in these distributed settings.

This concludes our series Standing Up For Agile.  For more information please contact me at

Tagged , , , ,
%d bloggers like this: