Methodology Smells

In this post I’d like to provide some guidance when selecting consultants to do your project work, specifically I’d like to discuss the various methodologies that consultants say they adopt when delivering projects. First off I’ve got to admit (..before I start ranting) that I’ve spent a number of years with my head lodged firmly up my own fundement with regards to software delivery process and methodology, and it’s only now that I may write with some perspective, my true thoughts on process.

Generally when engaging with consultants the matter of how the work will be delivered will be discussed. This, after all is an important criteria in your assessment of suitability, however the following points are aimed at shining a light on some of the things you may wish to look for, and avoid when making an assessment:

…things to avoid….

Tripe

I recently read the following from a ‘leading’ consultancy (…isn’t it funny how many consultancies are ‘leading’ – perhaps this will be the focus of another post – what does it really mean to be ‘leading’?)

Included in <<X methodology>> is the detailed <<X>> Information Management and Performance Management Framework specific to the delivery of Performance Management strategy and solutions and the underlying Information Management structure a pre-requisite for effective Performance Management.

God knows what this means! Frustratingly,  bloated consultancies and their tripe marketing departments churn this nonsense out by the bucket load.  Alas some poor soul will find themselves sucked in by this, perhaps because they’ve been reading  about other ‘pre-requisites’ which are apparently required? In fact much of this methodology bullshit is built upon a basic fear factor. You must do ‘this and that’ or several horrific things will happen to your project. If you don’t pay the exorbitant daily rate for an individual who happens to know how to open Microsoft Project (..and who will help you conquer these many pre-requisites) hell will open its gates and swallow your project up whole! In many cases you’ll find that your $$ will translate to more documents littered with nonsensical language which will sit on your shelves for ever more and will have no bearing on the success of your project. This is classic methodology tripe, if you happen to like your tripe then suck it up.

Diagrams

Its almost unheard of that a methodology doesn’t include a complex diagram of some sort – the trend seems to be the more exotic and incomprehensible the diagram the more valuable the methodology, or so we would be lead to believe. These diagrams are aimed at trying to take the complex and distill it down into a single sheet of A4, a quick view on how it will all work, but software projects in particular are simply not like that. I can’t remember a single project I’ve ever worked on which fit neatly into one of these diagrams. Don’t be fooled by them, whilst diagrams are a useful way to illustrate a process – they should be taken as such and certainly not viewed as a sign of process maturity.

My *favourite* diagrams are those that involve wheels….you know you’ve got a winner when they design a process around a wheel.

Zeitgeist

Many software delivery methodologies are reactions against the status quo. Many are justified reactions based upon existing processes not working, however with each new methodology comes a flurry of consultants jumping on the band wagon, promising a ‘new and improved’ way of doing things – don’t ignore this, just apply caution, and like any good analysis, scratch the surface a little and find out just how much reality is behind the claim. For example I’ve been amazed by how many interviews I’ve conducted in the past couple of years where the interviewee has claimed experience of agile methodologies yet when probed have demonstrated very little understanding – like any skill, claiming experience and expertise in the use of a process or methodology should be carefully assessed.

Hybrids

“We took the best of breed…”

This sort of statement can often be attributed to methodology fashionistas (see zeitgeist above). I’m not a big fan of hybrid methodologies. A consultancy putting forward a hybrid methodology is, I suspect a consultancy trying to placate conflicting camps and too inexperienced or unsuccessful to base their approach on a single proven method. I’m sorry, but I find it tough to understand how waterfall and an agile approach can be used on the same project. I’m sorry I don’t think that story boards and burn downs sit neatly alongside GANTT charts. To me hybrids smell of confusion and I would steer well clear.

…….look for and remember……

A means to an end

As I mentioned I have spent some time being a little process obsessed and at times I’ve lost perspective on what it is I was actually aiming to do – choosing the right process is important but ensuring that it doesn’t own you is as important. There are two parts of the agile manifesto which I really relate to:

• Individuals and interactions over processes and tools
• Responding to change over following a plan

To some extent I think some agile practitioners have forgotten the first statement above – that the doctrine of Scrum or Kanban (..or whatever) has become more important than people or communication. Or the use of a particular piece of tooling has strongly dictated how a piece of software is delivered. The second statement means so much to me because its simply reflects delivery reality – things change. Look for a methodology which can react well to change and avoid those which take no account of change or perhaps view change as something which should be penalised.

Demand failure

Critical to any good methodology is an understanding of failure – I think its invaluable for any consultant to have an appreciation of their methodology based upon hard experiences. Ask the question ‘Have you ever found yourself in the trouble on a project?’ Ignore people who lie and say no, but listen carefully to when people are truthful and follow up by asking whether a process or methodology helped them and why.

Don’t Scrimp

I may sound like I’m bagging process, but that’s not the case, I’m bagging waste! You want your project to be successful. Without a path to follow it will be a very strange experience. Honestly ask yourself about where a process will and won’t add value, think of your past project experiences. Think about the many projects that were started and never finished and ask what could been done differently and what could help this time around. The software landscape changes so frequently that it’s almost impossible to consider a static approach which fits this ever changing picture. One size does not fit all and the nature of your project will dictate the nature of the process needed to see it delivered. Its fascinating to see the changing way in which new technology is being rapidly delivered to clients, using a much greater degree of client engagement, multi-disciplinary teams and a general adoption of leaner and meaner approaches – understand how it can help you and take advantage of it.