Friday, 4 April 2008

Agile and Orthodoxy

I work in a team led by someone who can safely be termed a veteran Agilist, with colleagues who have all swallowed the red pill.

I recently wrote a blog post about Kanban, which has left some of my colleagues somewhere between troubled and sceptical.

Before I go any further, please note I am not an expert in any topic, let alone Agile or Kanban. What follows reflects my limited understanding of the issues surrounding the two subjects. I should also add that Keith, as far as I can tell is not amongst the sceptics. He was also at the talk and was not troubled by the subject matter in fact I think it's fair to say he was enthused.

I don’t know what all of the reasons for disquiet are, but certainly amongst them is the feeling that as the Kanban approach does not at least presume (if not enforce) what are accepted as the pillars of the faith, then it is some sort of heresy.

Without two week iterations and test first development as pre requisites, how could Kanban be compatible with Agile?

Well I have re-read http://agilemanifesto.org/principles.html and I don’t see anything in the Kanban approach as illustrated by David Anderson at QCon that would be in conflict with any of the principles as enshrined in the manifesto.

At this point Keith will tell me that the manifesto is just a collection of meaningless platitudes. On some levels, that’s true enough. Who doesn’t want to be more of everything nice and sweet and smashing? But why expect more? It is after all a manifesto.

You can try to live up to some or all of the manifesto if you like. But claiming to adhere to the principles means nothing if you take no action is support of the aims. Actions taken in conflict with the principles must surely discredit your claimed adherence.

On the other hand if you claim to believe in some set of principles, take actions that support them, and do not take actions in conflict with them, then surely you have some right to say you are an adherent.

I should say at this point, that it’s probably of no interest to teams who are happy in their jobs and producing good work that delights their customers, what any manifesto . But let's pretend for a moment that it is important to them.

Despite it seeming too obvious to mention, I think its worth remembering that the things we might like to aspire to in Agile are not laws of nature. They are principles. The simple fact that we have XP, FDD, Crystal, DSDM, Scrum and others should be evidence enough for that.

Before you cry foul and say there is something in common with all of the approaches that form the core pillars of the faith, and amongst the common features are, for example, short iterations and test first development, let me respectfully direct you back to the manifesto.

So why don't I get back to my vague rambling point? Given that we are mostly normal human beings doing mostly abnormal stuff, then we still have the problem of working out what practical things can we do in our daily work to help us achieve our goals while not compromising our principles (too much)?

Clearly the best approach would be for us to be liberated from wage slavery but that’s another issue.

However, to be more realistic, putting the principles into actions is where the specific day to day activities of Agile come in. This is where a team might decide to do XP for example, with a Scrum wrapper perhaps?

Nothing in the manifesto requires such explicit practices as n-week iterations or test first development. XP or FDD have, on many occasions been found to greatly improve the chances of reaching the goals of a project while being true to the principles of Agile. Test first development is a pre-requisite in XP, but that is not to say that it is a pre-requisite for meeting the higher aims of Agile.

That’s all great but what if someone finds a practical approach that also helps in meeting customer needs and values, but at the same time does not care whether you do formal design or test last. You or I might think that sounds strange but surely regularly delivered, working software in the customer’s hands, meeting their needs and values trumps all.

For me the basic principle that I believe has most value is favouring individuals over processes. If we follow this principle then what I think should flow naturally from this are practices that people are happier with.

To insist on two week iterations and test first above all else then that would be favouring a process over individuals.

If being Agile was as simple as adopting a recipe of processes, it would not be so hard to adopt. But then it would be as meaningful as public only displays of piety as a means to get into heaven.

So getting back to a really good talk I listened to at QCon. The case study was an example where a demoralised, staggeringly under-performing team was turned around very quickly. There was no test first, no iterations … no kidding eh?

The team focussed on what was blocking progress and the elimination of wasteful practices in what they were trying to achieve. They tackled those problems in a way that empowered individuals in their daily work. They took an approach that imposed very little in the way of process. They freed people from a lot of the wasteful drudgery in their jobs but did not dictate how they should carry out their allotted tasks.

All of the above could have been achieved in many ways. What I think is exciting about Kanban is that it focusses very tightly on controlling a variable that is very easy to understand and can be controlled quite easily.

That variable is:

The amount of work in progress

I reckon it’s always best to try and effect changes on things you can control rather than things you can’t.

Dramatically changing how a team works is a great deal harder to do and I would argue ultimately a futile undertaking.


0 comments :