Disclaimer – While this may appear to be an article about a software development methodology, I’ve been using many components that are considered “agile” in non-software projects for over a decade. For the software folks out there, this is an article on the pieces of “Agile” that I find value in – your mileage may vary. After exceeding 2,000 words, I decided that I would need to kick out posts outlining details of the Agile components as separate components.

At a  recent meeting of the folks involved in the  PMI Southern Alberta Chapter (PMI-SAC) mentorship program, a discussion started around “Agile” since one of the people involved had been informed that their team would be using agile. A number of side discussions arose around this, including questions like:

• What kind of Agile will you be using?
• That seems like a project better suited to a traditional methodology – why are you using Agile?
• What sort of projects are suited for Agile methodologies?
• Why do IT projects continually fail / over-scope / finish late / …

I ended up having an interesting conversation around what I consider to be the “core” of agile, since I was involved in bleeding edge software development in the early 2000’s, which is when  lot of what is now considered “Agile” was just starting out. This was a time when programmers were talking about “patterns” and “anti-patterns” and really trying to get a handle on why software projects were invariably different than other types of projects.  Some of the “manifesto” materials included “The Mythical Man Month” and “The Pragmatic Programmer” and one of the first “methodologies” that I was aware of which had developed enough that it had a name was “Extreme Programming” (or XP¹). I found it interesting (and a bit worrying) that a lot of the discussion (and confusion) around “Agile” seems to be very similar to the discussions we had almost 20 years ago.

Agile before “Agile” was a word

As far as I know, our team (at Facet Decision Systems) was one of the first in Canada to try and formally codify some of the things that are now considered “agile”  and didn’t (then) have a name. We spent a lot of time trying to figure out what was actually effective, and what just seemed to be “faddish” trying things like pair programming, rapid iterative development and unstructured “code and fix” sessions. I think that one of the big takeaways from our experience is that some things will work really well, and some will be horrible – and it will all depend on how your team works together. The Iterative development components of it got wrapped up into a system called “FastTracks” – but this was largely used to explain to traditional companies that we were really using a traditional “waterfall” development approach, but were breaking things up into little tiny projects.  Instead of trying to explain the entirety of Agile (again) I’ll suggest that folks who are interested take a look at Martin Fowler’s insightful summary (which also includes a lot of the history I wasn’t aware of at the time) HERE. I’ll now provide the 10-minute overview of the pieces of Agile that we found useful (and why I think that they got introduced in the order that they did).

Useful pieces of Agile – Scott’s Opinion

This is my distillation of the pieces of what has become known as “Agile” that I have found work well for me in almost any circumstance. Since I’ve spent most of the last decade working on “traditional” projects like permitting and building power plants and chemical facilities rather than software development, these are the pieces that I think have fairly universal application.

Iterative Development

For all of the folks in software who are painfully familiar with the phrase “the spec is always wrong” you can take consolation in the fact that in the rest of the world it’s almost always incomplete or out of date.

There are two primary reasons to do iterative development:

• Breaking your project into easier to manage pieces
• Figuring out what you don’t know early in the process, while you still have time (and budget) to deal with uncertainties

The first reason is almost always an acceptable reason to do iterative development. Many managers (and executive sponsors) don’t want to consider the second, but in my opinion this is the best reason to use iterative development because it very quickly exposes assumptions that may not be on completely solid ground. I’ll start this with an apparent digression and outline how we built the “FastTracks” system, and the explicit reasons that we configured it the way we did, as well as the “official” and “unofficial” reasons for each step. Note that this is definitely “stone soup” territory because our experience demonstrated that if we told our clients the real reasons for the system our projects would get rejected. Discussions with several of our repeat clients demonstrated that our “duplicity” was appreciated because the reason that previous projects had failed was because the initial success criteria were the wrong criteria, and (people being people) many project sponsors are unwilling to admit that they don’t really know what their project will look like if it is “successful”.

Test Driven Development:

You won’t find this phrase (or the acronym TDD) before the mid-2000’s. I was introduced to this concept through the groundbreaking book “The Pragmatic Programmer” and it has proven to be a pretty useful trick: build your test before you build your code. This is particularly useful if you are trying to replicate the activity of “”legacy” code (AKA “it works, but this programming language hasn’t been used for a couple of decades and we can’t port or maintain it anymore). Instead of writing a detailed specification, build yourself a sample input file (or files), and sample output. Your code is successful when you feed the input file(s) into your new code and the output matches your output test. This seems easy, but can be surprisingly difficult.

The core of this little technique is that if your test passes, your code is compliant (by definition). A subtle “gotcha” is that sometimes your test is compliant because it’s incomplete, so you may need to add pieces to your test so that it reflects what you actually meant it to do.  Typical test pieces will include known boundary conditions , for example sometimes the software behaves differently if you feed it one thing, instead of a list of things. To steal a line from Ralph Vaughn Williams “I don’t know whether I like it, but it is what I meant.”

While everyone thinks that test driven development is a software thing, I have found that it is also very useful for doing process improvement. In most cases your final product should be the same after a process improvement project as before so you can use the same sort of methodology, and if your process improvement also provides a product improvement, you can then change your test to include that enhancement.

Sprints (Scrum and a few others)

There are a lot of methodologies that use “sprints” – short time periods (usually a week to a month) to build the next set of features. Project managers are tempted to think that this is just so that you can have consistent sized chunks in your work breakdown structure, and some Agile practitioners think that this is to keep the size of each development step small enough that you can dispense with those pesky project managers completely.

I’ll propose another reason: momentum. If you are doing iterative development and building your testing before you write code and a hundred other possible things – all of which occur before you start – having the entire team bog down and spending forever on things that aren’t part of your project becomes a real concern.

The sprint forces you to do something and actually deliver, then look at what you built and then deliver again. Because the “sprints” are short, there is less pressure around delivering perfection and more of a focus on delivering something incrementally better. Without this step, projects can get trapped in the vicious cycle where your planning is making something even better than the original, so it’s worth waiting for. But because it’s late, you need to over-deliver. And that improvement you need to add to over-deliver will make it later…

There are three big risks that I see with the “sprint” methodology instead of a more conventional “waterfall” approach:

• Sprints can deliver something other than what is expected, which can be less than ideal you are sprinting to a defined deliverable. Divergence from expectations is generally seen as a bad thing, so formal change management needs to be solid and outline the approved (and thus “expected”) changes.
• Because the focus of sprint development is on the next iteration, there is a tendency to cut corners on each sprint. If this isn’t accounted for (and fixed) in the next iteration, then these shortcuts can build up, with the potential to cause cascading failures. ²
• Larger projects are more like a marathon than a sprint. While some teams have figured out how to pace themselves, I know a lot of teams that started fast and then burned out. Some of the best “sprinters” I know are actually marathon runners who are neurotic about having a milestone every hundred meters. They suck at races under 800 meters, but for longer distances they leave their competition in the dust.

Other Pieces

There are a number of other pieces that are considered “Agile” that I tend to use, but these three pieces are things that I tend to use in most of my projects – whether or not they are software based. Other components are much more context sensitive. Standing meetings may not be a good idea when you are reporting to VP’s, and I note that the fable of the Chicken and The Pig (conspicuously absent from SCRUM since 2011 or so) is no longer part of the core precepts. While I understand the change, the whimsy of this fable was (in my opinion) helpful in building a team dynamic that let people laugh at themselves and then move on.

What’s with the Agile Elephant?

If you are wondering why this article started with the picture of an elephant, I chose it for the parable of the elephant and the blind men. What is Agile really, and does Agile mean different things to different people?

If you aren’t familiar with the parable look HERE. For a criticism of the parable (as it applies to the search for philosophic understanding) you can find an interesting counterpoint HERE.

---

Note 1: This was always a bit confusing since this is the time period when Windows XP was launched, so you needed to figure out if programmers were talking about the operating system of the philosophy, and it got exciting when you were talking to Extreme Programmers who were coding for Windows XP…

Note 2: Iteration failure is much less of an issue if you are using test driven development because it’s not “done” until it passes the test, so shortcuts that fail testing don’t count as progress.

Elephant Photo Credit: Coco Parisienne (Pixabay)