Agile and ITIL – Handing over knowledge

At first pass, agile and ITIL approaches may seem like natural enemies.  This is certainly true if :

• Agile is for cowboys who evade testing, write code without knowing why and think that documentation is close to pure evil; and
• ITIL is a pack of non-thinking drones who create multiple unnecessary roles, random gateways with no purpose and document everything in sight without knowing why … including the average length of the carpet in high traffic corridors.

Where the zealots rule, the only thing that agilistas and Itilists will agree on is that one of them is fundamentally wrong and must be stopped.

But when they actually listen to each other they will discover something interesting:

• ITIL has a very good knowledge management process hidden in its mist (Knowledge Centred Support) that says that we should record and solve problems by referring to a known list of symptoms and predicted root causes. Then if we don’t know the answer we should iteratively solve the problem and evolve our knowledge base for next time.
• Good agilitstas  says that we should iteratively evolve our knowledge as we solve problems and start to better understand root causes rather than work on symptoms.
• Both say mailing an out of date requirements document to a support team is pointless and both say that we need to collaborate on building our knowledge.

So here is a predictable outcome when good agilistas meet good itilists.  We all agree that we need to collaborate to evolve the knowledge needed by a support team.

• The agilistas have this knowledge and believe that it should only be documented if it is fit for purpose; while
• The itilists have the process and the “fit for purpose” documents that can replace large and wasteful requirements documents for support teams .. but  want someone to collaboratively build their knowledge based on the things the agile team already know.

So – when they actually talk to each other about effective support and about looking after the interests of their clients and their teams (rather than zealotry and what someone told them to think) then they find that they are actually a really good team.