After day 1 at Yow West 2015, my passion for Agile has been re-ignited, I’m reminded of all the cool things Agile is about – Delivering business value fast, working collaboratively with the business to give them what they need, not what ‘we’ think they ‘want’.
There was lots of cool stuff to hear about like Microservices, Dev Ops, BDD, MVP. We also heard about real world environments that now continuously deliver to production every 3.5 minutes with Programmer Anarchy, and we saw a video of an Agile Flash Mob going from business idea to a live iPad app in 2 days direct to the shop floor (wow I thought 2 week sprints were fast!). So let’s face it, delivering business value fast was their goal and they smashed it, but how can we achieve this in a corporate environment where we need approved Business Cases, lots of sign offs, and vigorous testing to give the business confidence before we Go Live?
The day finishes with Nigel Dalton “The Godfather of Agile” who talks about “……what prevents us from “Getting Crap Done” is the last time we got crap done” a blog by Ken Scambler. This was a great reality check on things, and looked at the longer term trade-offs for trailblazing software delivery in this way. Ken mainly refers to the technical debt they incurred, but I can see how this would also become a vicious circle when it comes to ‘process’ and the ‘ability’ to deliver fast in most corporate environments. After all, what is the first thing we do after every successful delivery?…… we do a retrospective!……..and so we start putting steps in place to avoid all the pitfalls and issues that we encountered in the last sprint. Yes you can push hard and deliver something very quickly, but you may need to cut some corners to do so, and that incurs a cost whether that’s technically refactoring a solution for the longer term, or the indirect cost of taking resources away from other work, or the regression that we just introduced to production. We probably want to avoid these next time round, and so bit by bit we start to create safeguards, which in turn have the potential of becoming the bottlenecks we want to smash through again in order to deliver fast!
So why is being an Agile Project Manager like being a two headed monster? Because the two terms in that job title are conflicting. Imagine if you were called the “Agility and Command and Control” person. On one hand we want the freedom to break down barriers and just “Get Crap Done”, forget process and governance, let’s just deliver! Sounds exciting……., but on the other hand we are taught to closely manage risks and issues to prevent projects from going off the rails. We put process and governance in place to protect projects from risk, and these mitigations take time to navigate and don’t always allow us to be completely Agile.
So where does this leave us?
Well I see it like this………..I constantly hear things like “That’s not Agile” or “We don’t do real Agile here”. The truth is, there are so many variations of Agile that there is no ‘one’ Book of Knowledge on how to do Agile, it just does not exist. Agile is about adapting and continuously improving, and not getting too caught up in the process or lack of, it’s about identifying a goal and finding the ‘most value’ pathway to deliver to that goal. I’m excited about the leaps Agile is making, and as an Agile Project Manager I see this as a recipe book of practices and options that I can use (or not use) to best fit the project and the environment I am working in, to help deliver projects with ‘most value’.
– From one of our Agile Project Managers