Yes, but what is methodology for?

Just this morning I was talking to a colleague about scaling methodology…

…and how often organisations seem to lump quite diverse projects and tasks together according to some extremely loose categorisation such as ‘small/medium/large’ (or something like that), and force everything into what is often a quite inappropriate (not to say brainless) approach. So we end up insisting that some major output is produced, a mass of extra items should be added in our Definition of Done (DoD), or some sign-off given that is wholly out of proportion to the problem the work is designed to solve or the real problems it might face. But we do it anyway, apparently for want of any clearer idea of what we should be doing.

My suggestion was simple in concept, although I suspect that most organisations would have difficulty making it work. However, that is probably more of a comment on how they structure and manage themselves rather than on my suggestion! My idea is based on the principle that lifecycles, methods, DoDs, standards and procedures exist for just one reason – to control risk. We don’t have standards and procedures for things that can be expected to happen anyway.

For example, shortly after the fall of the Soviet Union (yes, I know…), I was working on EU projects in Poland. While I was there I discovered two quite fundamental problems for any travelling consultant:

  • The electricity was so erratic that I would have been ill-advised to plug in my laptop.
  • In most factories there was no loo paper because it was a precious commodity that was usually nicked as soon as it was put in.

So my personal methodology  for ‘being a consultant in Poland’ quickly acquired two new tasks:

  1. ‘Leave your laptop in the hotel’ (where the current was more stable).
  2. ‘Put some toilet paper in your briefcase’.

But of course these weren’t risks here in the UK. So they weren’t in my ‘being a consultant in the UK’ process.

And so it should be for any methodology: if you can’t say what risk a given action or standard or item in your DoD is controlling, take it out. You will only be able to make your methods truly adaptable if you can map the actions it contains to specific risks.

Here’s another example, probably more relevant to the reader who isn’t currently travelling in the old Warsaw Pact countries in the early ’90s. I was recently involved in a simple project that required a standard rate table to be updated from time to time. The table fed the public website, so its potential impact was enormous, and in many organisations this alone would be enough to trigger a much more complex Definition of Done, testing and authorisations, if not a formal, quasi-waterfall lifecycle. Yet the risk was extremely tightly focused, and there as a single simple and quite foolproof way to mitigate it – make sure that the user story includes all applicable policy, business or regulatory specifications, get in the relevant subject-matter expert from your Extended Team to guide and verify your work, and Showcase the result before any change is allowed to go live. That way:

  • The job is properly defined.
  • It is extremely likely to be done right.
  • It’s checked by a real expert.
  • The Product Owner and stakeholders at are reassured before anything hits the public.
  • It all stills fits into the standard Agile framework.

So triggering the full technical governance lifecycle would be stupid. Yet for many organisations it is the only option. No wonder so many developers and managers are so irritated by governance and methodologies!

Many organisations have some kind of work classification tool or procedure for deciding how standard lifecycles should be applied. Most are based on pointlessly trivial issues, like the sheer size of the work involved, but even where there is a proper evaluation of the risks involved (e.g., novelty, organisational complexity, regulatory impact, and so on), there is no direct link to the specific products, procedures, verification methods, approvals and other things the work will have to include.

I have already given one simple example of what this might mean that most organisations could implement today. But methodologies (including Agile) are seldom so little defined by the risks they control that it would take a lot of effort to unbundle all the different components needed to control specific threats. That’s why Agile is so strong, of course: the experts you need to make that call are almost entirely embedded in the team anyway.

By |2018-04-05T14:23:28+00:00Friday, June 20 2008|Categories: All, Bureaucracy, Management systems, Principles, Process and method, Risk|0 Comments

About the Author:

Chief Architect,

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?             
error: Agile201 is wholly copyright and copy-protected.