Don’t Go Chasing Waterfalls: Get Your Agile Project on Track

Professional drinks coffee while glancing at alarm clock

With increased attention and investment in financial technology has come a wave of support for the Agile approach to project delivery. If you’re reading this blog, I’m assuming you’re familiar with Agile so I won’t belabor the potential business benefits—that said, I’ve noticed a tendency to implement Agile in order to be perceived as forward-thinking or because of Agile FOMO (Fear of Missing Out) without care given to the underlying philosophy. Though we may know Agile as a methodology, in practice, it is a set of non-prescriptive values and principles that leaves its application fairly open to interpretation. Having worked on numerous Agile projects, I’ve noticed a few recurrent sources of confusion that firms should look out for at the outset of a project.

According to the Agile philosophy, one should value:

  • Individuals and interactions more than processes and tools
  • Working software more than comprehensive documentation

Unfortunately, since it is up to individuals to decide how much more to value one side of the equation over the other, teams can sometimes become stalled in confusion over how much to prioritize a value, or worse—they may over-prioritize a value to the detriment of progress. Here’s my quick take on what works and what doesn’t when it comes to interpreting these tenets:

Individuals and interactions more than processes and tools

One Agile principle states that the most efficient method of communication is a face-to-face conversation.  Some people may, therefore, interpret the idea of valuing individuals and interactions more than processes and tools as an imperative to use only local resources.  In practice, however, this is often impractical and cost-prohibitive, particularly when it comes to certain types of project work, which have become commoditized.  Affordable expertise and skills are often located across the globe, and more and more resources work remotely.  In real life, processes and tools often win out.  It is important to note, however, that even here the lines often blur, as tools become more sophisticated in their ability to facilitate effective communication.

Working software more than comprehensive documentation

The idea of valuing working software more than comprehensive documentation, when taken to the extreme, can lead individuals to feel they have been given a license to stop writing things down and ignore documentation entirely.  Whether out of complacency or lack of understanding, this practice can lead to serious problems.  It may be trendy to think that things are black and white and that Agile=faster raising of issues.  However, when communicating within a large team, where face-to-face interaction is necessarily limited, documentation keeps everyone on the same page, literally.  It also provides opportunities for questioning assumptions and rewriting requirements in a way that is often more efficient when team members are dealing with time and language barriers.  In this way, documentation can be seen as a communication tool that helps move projects along more quickly and keeps departments and resources aligned and moving in the same direction.

It can be more helpful to think of the Agile values as representing a continuum, where the practical application of these values is relative to the constraints of the project. How a project team should integrate and calibrate Agile values should be a topic for discussion early on in any project.  Project teams can use the following reflective questions to help understand if a recalibration of their values might be worthwhile:

  • Is diagnosing test results starting to dominate the team’s time and energy?
  • Has in-person meeting attendance become over recognized by project management when compared to evident expertise demonstrated with throughput?
  • Is the lack of any documentation a badge-of-honor in the project’s culture?

What is pragmatic for a Californian garage band creating their first app may not be pragmatic for a global asset manager with disparate teams and an international client base. Like many of us, I’m a believer in the Agile methodology, but only insofar as your specific needs inform its application.