A Shot in the Arm - Jason Burke on Health and Life Sciences

Let me first clarify terms.  In describing waterfall, I'm referring to a development process where the process flow -- from requirements gathering through design, coding, testing, and release -- moves sequentially through deeper levels of detail.  A project team might collect all of the requirements in a large requirements document, then design the architecture and functionality of the system, then build and test it, and then release it. As you can see from the picture, though the steps can overlap somewhat, it is predominantly a linear process.

In contrast, agile development refers to a family of methods and processes that execute more dynamically through iterative development activities and extensive collaboration.  If waterfall can be described as predictive (i.e., I predict at the beginning the solution requirements, write them all down, then build it), agile can be described as reactive (i.e., I don't necessarily know all of the requirements at the beginning, but I will learn them as a go along).  It is important to note that both approaches are formal and controlled -- we are not talking about letting people build whatever they want whenever they want -- the control mechanisms just work differently.  As I mentioned above, waterfall has been around for 35 years, but agile has been around in various flavors for around 15 years, so it's not exactly a new kid on the block either.

There are many (including me) who argue that waterfall development does not really work.  For starters, waterfall assumes you understand all of the requirements up front.  I've literally never seen that happen; in most cases, the end customers themselves don't actually understand their requirements at the start of the project, let alone the development team.  Waterfall also assumes you have ample time to do all of the steps sequentially.  Whereas historically that may have been true, the modern commercial imperative to be more responsive to evolving user demands pretty much dictates that you move more quickly than waterfall is designed to facilitate.  I have found that waterfall development also tends to produce systems that are more tightly coupled and therefore less extensible because future variabilities did not factor into earlier design and development decisions.  So when people ask me "why agile," these are my reasons.

I'm fortunate that mine is not the first organization within SAS to adopt agile approaches, and I've been able to capture the successes and learnings of my peers before we entered into the foray.  Around two-thirds of my team has already completed training, and the remaining third will complete it before the end of the year, but completing training does not give you the ability to just start "doing agile" tomorrow.  The field of agile methods, processes, and lifecycles is extensive, and any organization needs to reach its own consensus on what "agile" means to them: which concepts/methods to keep, and which to discard.  Those decisions then have to be institutionalized (i.e., SOPs, daily business practices, systems).  I've compiled a list of agile concepts that I'm asking my team to consider, including the items in the table below. 

It is worth pointing out that many of these concepts are already in practice even within our existing waterfall framework; it is more the relative weight of the activity that changes.  For example, the SAS Drug Development team has been using iterations to structure their development activities for a while now, and all of our products rely on user roles and personas as primary drivers of functionality.  In future posts, I'll talk about how I believe architecture as a discipline should evolve to account for agile, as well as how we can satisfy regulatory compliance requirements through agile development methods.