Can Processes Be Agile?

With great interest I read through Agile Culture, Adoption, & Transformation Reading Guide by Michael Sahota. It makes a lot of sense for me. Along with many other interesting statements, Michael states that Kanban is not Agile.

Reading Michael’s posts encouraged me to share my old heretic thought. The Agile manifesto states we have come to value … Individuals and interactions over processes and tools. And here we have processes explained in excruciating details (like how to stand and how to chart), which usually are referred to as Agile. Do we have here a contradiction or I am missing something? I am not discussing their value here at all – I just saying that if I read The Agile manifesto correctly, it looks like agile process is an oxymoron, isn’t it? Sure, it still says there is value in the items on the right, but nevertheless.

I guess that we have multiple dimensions here and looks like they all get messed up. One dimension would be Waterfall – Iterative (or maybe Large Batch – Small Batch following “The Lean Startup” would be even more exact – waterfall may be considered iterative, but with very large iterations).

Another dimension may be Process Oriented – Agile.

It is interesting what would be opposite to lean? Probably not fat (although it is what using the word “lean” hints) – you probably don’t want to have fat in whatever approach you use. Maybe “Build to Grow”? Lean means that you do absolute minimum (accumulating technical debt) – so the opposite would be if you build infrastructure / framework to grow from the beginning. So Build to Grow – Lean would be probably another dimension.

So, I guess, every software development methodology may be described by its position on these (and/or other) dimensions and a set of specific practices (which may be useful in some context). However, except Michael Sahota’s analysis, I haven’t seen much in this direction yet.

I have a small stake here: in 2008 I wrote a paper titled Agile Performance Testing. I shared a few ideas on how to do performance testing in a more agile way there (using the word agile according to my reading of Agile Manifesto). By the way, I never meant that it is a new way of performance testing – rather a collection of several practices that, I believe, good performance engineers use (consciously or unconsciously). The paper didn’t touched at all performance testing in agile software development, so some attendees were disappointed (well, in its latest reincarnation I presented at Agile Testing Days I added slide 47 about it). Should admit that the title was chosen to provoke interest to the topic and it fulfilled this purpose well. Still I was periodically wondered if the name was correct – and still think that it does.

Application of agile principles to testing is another interesting topic.