Back to Basics

So I've been away for a while.

Having persued the Agile path from its early beginings working with XP, FDD and RAD methods in the late nineties and then been on a journey all the way to the Scaled Agile Framework in 2013/14, I stepped off.

One of the interesting things in doing what I do is that once in a while it helps to go back to the other side of the fence and see what it looks like.  I'm now deeply involved in a global datawarehouse delivery for a large Financial Corporation and its all fixed price 3rd party work and waterfall documentation.  I've been here for a while, and have witnessed all the things that we tried to fix with Agile all over again.

Whats fascinating is what happened when things started to slip on the waterfall plan. The build phase in my project was being held up as design was late and still emerging. It somehow seemed really natural to fall back to Agile first principals and start short iterations of design, build, design review and test, within the waterfall process.  Also what was equally fascinating is how this "iterative" approach has been hailed as significant progress within the Department.

In this heavily silo'd and waterfall organisation there are so many ways that grass roots Agile can help sort out and fix problems and also give a framework to prioritisation.  Not by suddenly implementing scrum and making the business engage as product owners (they really aren't ready for that) but just by going back to some of the original Agile principals, like Keep it Simple, Evolve Designs and Reflect Regularly.

I have now been invited to run presentations and workshops to demonstrate what Agile can do for the Organisation and how the Agile principals can pave the way to more successful outcomes.

Here we go again :-)