Agile, visions and nightmares...

An Old English Proverb states that:

A vision without a plan is just a dream, a plan without a dream is an hallucination but a vision with a plan can change the world

Sounds good but it doesn't work for me - not in the Agile world at least. So looking at the situation in front of me I think I prefer the Japanese version of the same idea:

Vision without action is a daydream. Action without vision is a nightmare

We often think of a vision as being a lofty view of what we want to achieve in the far distance.  Something that's nice to have but in reality a soft, fluffy concept that doesn't really impact the actual plan and work that we're doing right now.

In my normal day to day activities I don't feel a great desire to plan everything I do.  It's not because I don't like planning, given my skills in DIY I'll do anything to put off the inevitable need to actually "do something".  It's just that I seem to do better if I work on a more general direction that I want to take and then get started by doing the obvious things first.

Yes it's true that sometimes I do work that I didn't need to do or I have to rework something that I got wrong.  However, after 30 years of experience I generally find that what I gain by getting on with things easily balances what I lose from thinking about something too much.  

Dwight D. Eisenhower is often quoted as observing:

Plans are nothing; planning is everything 

which seems to be in conflict with Tennessee Williams's quote that: 

Success is blocked by concentrating on it and planning for it... Success is shy - it won't come out while you're watching

But I don't think that it is.  Eisenhower was simply saying that the act of planning makes us more aware of what we want to do and brings together those people who are going to have to deliver it.  Williams was warning us not to take planning so far that the reason for the plan is lost.

Visions should be a simple set of guidelines that enable us to make simple decisions on what we should be doing today.  Simply put, we shouldn't be doing anything in our agile delivery unless it's taking us nearer to our vision.  More importantly, we shouldn't be doing anything that takes us in a different direction.

Too much planning constraints innovation and make it harder for us to adapt.  I coach a local Rugby Team as a SCRUM Coach.  I know - the irony doesn't escape me.  Every week we teach new skills and new ideas.  Successful rugby teams are not those that have hundreds of set pieces that they bring into play.  In training, my team scores a try everything they run the ball - in matches they don't.

Does that mean the set pieces are wrong?  No it's simply that a set of detailed strict plans leaves no space to change direction when the situation changes.  In order to win, the team must be able to adapt their plans as a single entity merging, simplifying or adding new rules as the situation demands.



So that's now not the way we train.  We have some simple visions, or guidelines, that govern each situation.  We teach the basic skills; passing, tackling, scrumming, throw ins and kicking. We teach base moves; loops, high kicks, missed passes and rushing.  We then look at various rugby scenarios as a team.  We ask the team to decide how they react in each situation and then to list what other options they could use given the limited set of skills that they have in their arsenal.  This is similar to the "futurespectives" I discussed in my last blog.

We also do this directly after the matches.  Reviewing actual videos of the play and deciding what actions we're going to take forward into the next training session and match.  These debriefing sessions (or retrospectives) are the most effective way we've found to improve performance.

So we are planning, we're just not actually drawing up actual plans.

That's the fundamental foundation of agile.  We don't know exactly what we're  going to deliver at the outset or even how we're going to deliver it.  We need guidelines & a vision to tell us if we're doing the right things.  There are some basic skills & base moves at our disposal but the team review & commit to a given course of action having reviewed all of the possible solutions and optimizing their approach based on the most immediate information to hand - i.e. they've learnt to adapt.

But my current client is still struggling with the concepts.  Apparently although we want to be Agile we want to lay down the plan in advance so that we know the answer before we start.  The problem is that this assumes that there is only one viable solution when we all know that there are many solutions to the same problem.  Admittedly, some of these plans are more viable than others but why start off assuming that there is only one road to success at the outset and limiting your possibilities.

This week may have been a turning point though.  Four months in the planning and their implementation plans A through D were all shot to nothing.  Deadlines can't change, costs can't change and we don't have time to sit and plan it all out again.

So we laid out our vision - this must be operational by 3rd September 2013

We've taken the bull by the horns and  we've been looking at our backlog of activities.  We simply prioritized them in terms of this vision and started on the ones that took us closer to the destination while eliminating those that didn't.  

Result?  We've reduced the scope of the project by 25%, brought the project delivery back on track and gained a very satisfied customer.  More importantly they've agreed that planning everything in advance gave us a false sense of security and nearly sunk our project.


So we solved the problem by being more Agile.  Having a clear vision that we all know & understand, evaluating value based on increasing probability of achieving what we've set out to achieve and not looking too far down the road (3 months in a 24 month project) we've regained control of the benefits & project delivery.  By starting activities and worrying about how we'll "join up the dots" at a later date we're already making great strides.  We know we will be able to "join up these dots" because there all founded on the same clear, unambiguous vision.  Anyway, half the fun is seeing how it all turns out and fixing problems as we reach them.

So the next time you feel tempted to start a protracted planning review remember that you'll gain more from setting a clear vision and getting on with it...  

Mike

Doctor, doctor, I keep seeing into the future. When did this first happen? Next Tuesday! - Futurespectives

After sitting waiting in the airport for my London to Atlanta flight we finally landed at 0705 this morning after another 9 hour flight from the US.  

It wasn't a good flight, it wasn't a bad flight - but it was a wonderful flight.  You see it was my last flight from the US for the foreseeable future and that can't be a bad thing.  It's not that I don't like Georgia, Americans or McDonalds.  It's just that I really wanted to come home to the UK for a while.

I'm now supporting a new client in Leeds.  Actually they're not a new client but a very old one who've hit new problems in the way they run projects. I've always admired the company.  It's incredibly successful with growth of over 25% year on year for the last four years.  Their success started around the last time I left them but I'm sure that's just a coincidence!  However, now this very success has become a clear and present danger to their future viability and they're panicking.

The problem is that they can't keep up with the pace of their own growth.  Their development & delivery process simply can't give them what they need to sustain growth quickly enough.  Some major projects were seriously behind schedule and the gap between delivery and future growth was widening month by month.

They'd decided to 'go down the Agile route' because they've read that it was quicker, more cost effective and overall much better than other ways of running projects.  Of course, Agile didn't solve their problems - in fact everything got even worse than it had before.  

It wasn't that they didn't understand the process, or had got the training or even that they couldn't adopt the mindset needed.  What ever the problem was it was more fundamental than that.  So in a chance meeting their CEO asked me what they were doing wrong and I gave him an honest answer (unique for consultants I think) - I don't know but I bet your team does.

I suggested a technique that's become quite popular in Agile and that's the concept of the Futurespective.  It's a powerful technique that takes the concepts of the Retrospective to mold the future.  The idea is simple. Think of your new project and mentally take the team to the final deadline.  Assume the project has been a miserable failure - not too difficult with my current company as they've had recent experience. Brainstorm about what happened on the project to make it fail thinking of People, Organization, Systems, Processes, Facilities and Logistics and put all ideas up on a flip chart.

Now look at all of the things that have been written down as a team.  Ask them to dot vote to determine which of these are starting to happen (e.g. poor communications with Product Owner) in the current project.  At the end of the session you'll have a list of priority actions that you should take now to resolve the problems that haven't happened yet.

We did this exercise taking a mythical Sprint Plan and the team then enjoyed thinking of ways to make it fail.  Of course they drew on their own experience and clearly themes began to emerge.  We identified five critical things we could do straight away to improve Agile implementations and created action plans, as part of the product backlog, to forge success from our future failure.  The benefits were immediate and the rate of Agile projects has significantly improved.

So successful was the one day session that I've been asked to support the team deliver their next bunch of projects and accelerate the adoption of Agile across their Europe offices as well.  Even more interesting is that the Futurespective has now become a part of the early sprint planning meetings across other projects.  They decided to hold a Futurespective before each Sprint. 

The team ask themselves two questions:

• Assume this Sprint is a complete failure, and based on what we've committed to deliver, what are we going to do on this Sprint to make that happen? 
• What actions can we take now to stop that happening and make our Sprint successful?

The difference between this and a Retrospective is that it's more postive and we're able to take

into account what we've committed to do in the current Sprint and adjust the way we work together in advance to avoid problems.  That's means we're looking forward not backwards. As a result the team feels more in control and is far more likely to put ideas into actions.

I can't accept the credit for coming up with the idea but I'm more than happy to accept the assignment and the fees of course.  It's got me back into the UK, back into Yorkshire and back to proper weather (it's raining cats and dogs outside as I write so I'm feeling much better).

Let me know if you've tried the Futurespective yet or if you're going to.

Mike