Today (Saturday) we had the go-live of a medium sized project that had been going on since September.  The project has been run as an Agile project using the SAFe methodology.

The whole process took about 5 hours from start to finish, my job (as a developer on the project) was to do the cutover for the integration piece. The integration side had been deployed to production weeks ago, and just been laying dormant waiting for the config change to switch on, which  I did today, but I also had to manage traffic to the end point systems which also had deployments. Then there was the verification and so forth.

Plan executed flawlessly, and we even went home an hour earlier than planned.

Success!

So, a few hours later, after I had time alone to think,  I did a personal retrospective. You would think that since the plan executed perfectly (well almost) that there wouldn’t be much to do for a retro. Even a personal one. This got me thinking about Lean, and where I learned that if you don’t see a problem, your not looking hard enough. So, how do you look for problems when there weren’t any?
I turned things around – instead of looking for problems, look at ways that I could have got my Saturday back! How can I eliminate the need for myself.
So what did I do? I started looking at the tasks that I had throughout the day. If I had the time before the go-live, what would need to happen so that I would not need to do those tasks? Could I give control to the end point systems to pause traffic? How would I go about doing that? First problem! What does it accomplish if it was done? It would mean that I would have been able to come in later in the morning instead of first thing as I would not be needed. Does that move me closer to accomplishing the goal of giving my Saturday back? Well, no as I’ve done the task – but if it had been there – then yes! also, would it have made our cutover process better overall? Yes! therefore it is something we should look at implementing.
Onto the next task. I went through this process again and again.
Then I noticed something – I had the wrong goal! The goal should not be “get my Saturday back”, the goal should be “get everyones Saturday back”
In my opinion, this is close to system thinking. Localised optimisation (in this case – me gaining my Saturday back by offloading some tasks to the end point systems implementers) helps me, but it doesn’t help my fellow team mates. We have to look at optimising things so everyone benefits for the whole system, In this case the go-live, benefits.

So the next time a plan executes flawlessly – or near to, during the Retro or even if you don’t do Agile or Retros, do a personal one. Turn things around. Look at ways to maybe reduce the time to implement by half, or eliminate the need to manual intervention (ie, so your not there). Look at what needs to be done to accomplish that. You won’t be able to execute everything, but pick just one thing. If it moves you closer to an honourable goal – then look at implementing it no matter how little it helps. Every bit counts.
Remember though, if you find something and it just sits in the backlog with no one touching it, implementing it – then it does absolutely nothing.