Command, Control... and you ultimately fail!

For those of you who have read through my ramblings over the last couple of years you'll know that I've never been a fan of Command & Control.  Not the

video game of the same name - I think that's a great way to relieve frustration after a long day.  However, it seems that I'm not alone as Simon Caulkin makes clear in the Observer in his article Command, conquer and you'll ultimately fail.

He points out that "...Optimists assume that management is a linear story of progress - slow perhaps, but we're getting better at it all the time".  As times get harder he notes that "... management is becoming more overbearing and controlling... leading to a lack of morale, difficulties in retaining staff and general unrest".

Now I understand that such a regime is important if you're about to take soldiers into battle, if you're a surgeon about to undertake a radical and dangerous operation or if you're a despot trying to maintain an iron grip over a country.  You're not looking for creativity, innovation or even progress - just making sure that everything is done the way you know it needs to be done regardless of the cost.

So why is this at the forefront of my mind at the moment?  I guess it's because of the ill-fated decision I shared a few months ago that it would be good to leave Agile projects for a while and get back to something that a) people understood and b) meant that I wasn't living with ambiguity every day.  So here I am, sitting at the brink of a multi-million pound programme wondering "when the hell are we going to deliver something... anything!"  Under the ever watchful eye of our leader, affectionately known as Pooh bear, every meeting, email, conversation and plan is interrogated with the vigour of KGB at it's peak. 

As an aside, I often classify my stakeholders as characters from Winne the Pooh - A A Milne was seemingly an expert in developing real life characters that could be applied in real life.  Currently on my programme I have Tigger, Piglet, Owl, Rabbit, Kanga (and Roo) and Christopher Robin each displaying their own characteristics along with Pooh (a bear of little brain).  If you're wondering where Eeyore is then that's me - I've always agreed with his outlook on life.

So has the ever increasing number of plans, templates, two hour meetings and complicated processes generated more control?  Does the fact that we have an increasing number of project managers & business analysts on the programme team deliver results better and more quickly?  Does the fact that we have 50% more managers talking about delivery than actual people delivering something on the programme team mean that we're leaner and more effective and more in control?

The short answer is simply no (as is the long answer to be frank) and it's not

just in project management.  In law enforcement there is an increasing awareness that command and control doesn't deliver results.  A recent Police Leaders article "The myth of command and control" the writer states:

"The power of command and control, ultimately, is a mirage and is becoming less and less effective in contemporary law enforcement. Like a mirage, it is not power at all, it is only the appearance of power and it eventually evaporates along with its impact. The real power of leadership comes from the influence that a leader develops through quality leadership practices and from the amount of control that is given, not kept"

That is reinforced by the two hour project meetings that seem to be more about rehashing the results of every other meeting and listening to people who love the sound of their voice rather than actually deciding or doing anything.  I've lost count of the number of templates, slides and documents I've had to produce which no one reads or even cares about.  When I consider that my Agile sessions take no longer than 15 mins I can appreciate where Agile gains in productivity and team morale.

So what have I learnt in the past few weeks.  

Command & Control

1. Work on the misapprehension that after a large amount of discussion and planning that they, not the business, knows what needs to be done - plain arrogance
2. Assumes that the more controls and managers you have on a project will increase adherence to time, cost and scope of works
3. Provides places for people to hide, lie & blame others for lack of progress because everyone is anonymous
4. Is poor at delivering relevant solutions - indeed they focus on delivering what was thought to be important 6 months ago
5. Resists any form of change or innovation
6. Demotivates teams and breeds learned helplessness

Latané and Darley noted that there were five characteristics of emergencies that affect people

1. Emergencies involve threat of harm or actual harm
2. Emergencies are unusual and rare
3. The type of action required in an emergency differs from situation to situation
4. Emergencies cannot be predicted or expected
5. Emergencies require immediate action

Due to these five characteristics, teams go through cognitive and behavioural processes:

1. Notice that something is going on
2. Interpret the situation as being an emergency
3. Degree of Responsibility felt
4. Form of Assistance
5. Implement the action choice

The larger the group the less likely that anyone will take responsibility for dealing with an issue.  They called this 'diffusion of responsibility'.  Furthermore, where a command & control environment exists they demonstrated that this diffusion of responsibility happened with significantly smaller groups.  In other words no one does anything or takes action because they assume that someone else will.

But didn't I already know all of that?  Yes - but I think sometimes it's good for Agile managers to work on projects managed by unconscious incompetence so they can appreciate, and reinforce, sound Agile concepts.  As a reminder these are the differences:

Agile

1. Assumes the business knows what it needs to do and
   
   how it can be done - they just desire synchronisation & coordination
2. The fewer managers and controls you have the more accountability & responsibility business owners will take
3. Is transparent - no where to hide, lie or blame others
4. Welcomes change and delivers relevant solutions.  They still plan, but for what's important now not past imperatives
5. Builds strong motivated teams
6. Focuses on delivery not definition

So what am I to do?  Well I've already made a make or break decision.  Either we adopt a delivery focused approach (e.g. Agile) or I need to find an organisation that will.  My command and conquer stakeholders tell me that they support the idea - I guess time will tell.

Eeyore 

Agile - Sociology, Protesters and Projects

It's been a while since I last blogged but it's been a busy year so far - is it really nearly April? I've left the hospitality & logistics industries behind for a while and decided that I needed a break from the cut & thrust of sensitive projects. Oil & Gas - that can't be too controversial can it? I know it's not a traditional industry for Agile ideas but they really wanted help in getting things delivered and who can resist a challenge? Drilling for Oil & Gas has been around a long long time so there can't be too many skeletons hiding in the industy's closet that I'll have deal with surely? - Yep I can get some rest this time! 

(Warning: the introduction to this blog is a little long but trust me by the fifth paragraph we start to talk about some new ideas for Agile projects do be persistent!)

Regular readers of this blog know that sociology & psychology are two of my favourite topics.  If you want to keep Agile simple & effective then you've got to have a good grounding in both.  Agile is about connecting with people, understanding what's important to them and adjusting your approach as we go along - just like we do in real life.  Unlike more traditional approaches which concentrate on having a guess up front about what we'll probably need in 12 months time and then doing everything we can to make sure that nothing changes too much while we're doing it. 

Of course one of the problems with this approach is that we finally deliver something that no one wants or needs anymore.

Of course I was wrong about getting a break as Gas Exploration is a hot topic in the UK & Europe.  Now that we're looking for less traditional ways of extracting energy from the earth's resources it's clear that a lot of people aren't that happy with some of the new ideas of getting it.  What do you do when there's loads of people knocking on your door saying they don't want your project and that you're killing the planet?  I'm talking about onshore rather than offshore and the search for "Shale Gas" - you may have heard the word for the method for extracting is called "Fracking". 

If you're not sure what "Fracking" is you might want to have a look at Frack USA who provide a great 101 course with videos.  I've no idea who coined the term "Fracking" in the US but they clearly didn't know what the UK Tabloid media could do with such a term... Frack Off, What the Frack? Fracking Stupid are clearly natural tabloid headlines and they're already being used a lot by the anti-fracking groups. 

Although I don't want this to turn into a discussion about how good or bad fracking is I think I should also provide you with the URLs of some of the opposing groups to provide balance and so you can make up your own mind.  Frack Off is one of the larger websites dedicated to protest groups against fracking in the UK and you can also look at Friends of the Earth and Greenpeace for different perspectives.  You'll see that there's a chance that any project will get crushed by "public opinion" if we can't manage communities well.  Lucky there is government support and an excellent standards body in UKOOG who are making sure that the industry works together and develops proper checks & balances to keep Unconventional Gas Exploration & Production safe.

Actually this is one of the first times that I've had to manage a sizable project in the face of such controversy. Mis-information, protest camps,  intimidation & media manipulation are just some of the things we're having to deal with.  One thing I have learnt is that there's relatively little local protest over fracking.  I think that's a little strange because I'm sure if an Oil & Gas company was going to put a drilling rig in the field next to my house I'd want to protest a bit.  In reality though it's clear that although local resistance is one of the most powerful tools for stopping such projects people are fundamentally apathetic and would rather leave the protesting to someone else.  Well, that's until something bad happens or they're convinced that something bad is going to happen and then it's protest camps, swampy tunnels, chaining themselves to gates & railings and overall making life difficult for the company that's just trying to make a profit.  I'm a great supporter of the right to protest and of free speech but some of the protesters methods are downright dangerous and in a lot of cases make the life of the real locals unbearable.

So when will local people get together, overcome their apathy and protest?  We can get some ideas from Boutilier & Thomson "Modelling & Measuring The Social Licence to Operate, 2011. They suggested that there are four levels of social acceptance including: Rejection/Withdrawal, Acceptance-Tolerance, Acceptance-Support and Co-Ownership

In any project, including my own, there will be three primary views: For it, Against it and Haven't Decided.  The "Haven't Decided" typically won't be that passionate either way and don't get involved in lobbying.  However, the views of the opposing factions "For" and "Against" will have vastly polarised views and regardless of the actual facts of the case are unlikely to change their mind.  The number of people in these two groups are vastly outnumbered by the "Haven't Decided" majority but typically have voices that are disproportionate to their size.

Boutilier & Thomson came up with the view that if a project is going to succeed and gain the support of the local community then it must gain a "social licence to operate" from the residents.  If the project can engender a feeling of "trust" then protests are likely to be limited and delivery will be so much easier to achieve.  I would suggest that groups like Frack Off, Greenpeace and Friends of the Earth can only succeed if they can build a "social license to protest" as without the support of the silent majority they simply don't have the ability to get the local community to stop the project and they don't have the power or the numbers to do it themselves.  The role of the "Against" lobby is probably slightly easier as it's much easier to be negative about a project than it is to be positive and they can always play the "David v Goliath card" (e.g. the small man against the giant corporate).  For those of you who are interested I don't believe that either the "For" or "Against" groups have found a way to swing the views of the "Haven't Decided" group yet.  That's why the Green Party, Friends of the Earth and Greenpeace are fairly silent on the matter at the moment and overall local resistance is very low... but it's increasing slowly.

So what's this got to do with Agile methods and techniques? 

In traditional project management methods we work on our stakeholder mapping & management matrices to try and get buy in from the key people who could make our lives very difficult - those with real influence.  Some of our "stakeholders" are hostile and oppose what we're trying to do but the vast majority are "Haven't Decided".  However, things change rapidly and people can quickly change their minds.  Traditional projects aren't geared up for this.  Project planning & management methods are build around the premise that with enough definition & planning at the start of the project we can de-risk & mobilise our stakeholders to deliver the project.  Intuitively we know that this isn't the case.  Things change, incidents happen and political environments shift too rapidly for traditional project management to keep up.  All we can hope is that the buy-in that we developed in the early days of the project can be sustained just long enough to deliver something useful.

Of course Agile is much better at managing change and resistance.  Assuming that we ensure that the ways that we measure "value" include what's important to the "Haven't Decided" community we can continuously develop & demonstrate our positive approach through the Sprint Stand up, Sprint Review and Sprint Retrospective to fine tune our Social Licence to Operate.  Agile is designed to bring the stakeholders (product owners) into the project develop & deliver process and bring the builders closer to the users.

So that's what I've learnt in the past few weeks.  If I want to reduce the number of protests & keep my project on track I have to change the "Haven't Decided" into "For it" stakeholders and reduce the influence of the "Against it" groups - in short I've got to use Agile rather than Waterfall techniques.

Recent Agile surveys constantly indicate that one of the benefits of Agile is an increase in Stakeholder Acceptance of 80-85%.  In my industry that can equate to 10-15 days saved per Exploration Drilling Expedition due to a reduction in protester generated delays.  When you're paying £50,000/day just to keep the rig going that's worth £750,000 per site and we're probably going to drill at least five wells this year alone. £3.25 million savings seems like a worthwhile reason to concentrate on getting the Social Licence - what do you think?

For an industrial company it's been quite a learning curve worrying about the community & social side of projects.  In the past, most operations have been offshore and protest opportunities are pretty limited in the wild North Sea.  But now we're exploring literally next door to communities and the chances of mass protests are much larger and the risks to our reputation that much greater.  The industry has made a few mistakes but we've also seen the "trust" rating improving in our local project communities as we've started to adopt Agile principles and using community acceptance as part of any story value.  As a result we're moving from Rejection towards Acceptance-Tolerance.  We're not naive enough to think that we'll ever achieve Co-ownership but we do believe that Acceptance-Support is possible. 

In the next blog I'll demonstrate some of the methods and techniques that we're using to gain our Social License to Operate.  If the cynical large multi-national Oil & Gas sector can now see how Agile can deliver on the bottom line and these principles apply to all project environments - perhaps other resistance sectors will be able to see that Agile ain't just for IS projects - it applies to all.

See you all soon

Mike









 

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

Failure is an option...

One of the worst sayings I've heard recently is "...are we an 'Ameri-can' or an 'Ameri-can't'?" But reflecting on the spirit, and having reflected in my previous blog on "Being a Brit in the US" I've come to accept these truisms as part of the culture I'm now part of - however macho I find them.

The point that the author is trying to make here is a philosophical view that my current client company innately accepts that that progress is measured only by successful conclusions. "You're only as successful as your last project" is a common comment I hear in my adopted home.  KPIs, Performance Measurement and Capability are
measured, not by what I have learnt but by what I have delivered.  "Failure isn't an option" has now reached the point of a religion in American project management and I suspect in the UK as well.

But is it true?  Looking back over the last 20 years I can honestly say that I've learnt more from my failures than from my successes.  Every mistake I've added to my virtual "book of experience" in my head to make sure I don't make the same error a second time.  

It reminds me of a story about Thomas Edison...

Edison tried two thousand different materials in search of a filament for the light bulb.

When none worked satisfactorily, his assistant complained, “All our work is in vain. We have learned nothing.” 

Edison replied very confidently, “Oh, we have come a long way and we have learned a lot. We know that there are two thousand elements which we cannot use to make a good light bulb”

One of the most forgotten parts of Agile, and something that was oddly omitted from the manifesto, is the primary ability to "fail fast".  By failing quickly, and recognizing that failure and developing solutions that overcome it, we are able to avoid costly implementations of ideas that simply won't work.  

Agile is about failing to deliver what we expected but learning and developing better ideas quickly.  Constant learning, especially though the retrospective, is critical to effective Agile implementations.  Al Franken's quotation makes my point:

Mistakes are a part of being human. Appreciate your mistakes for what they are: precious life lessons that can only be learned the hard way. Unless it's a fatal mistake, which, at least, others can learn from  - Al Franken 2002

So this week we've started the new Agile approach to software delivery.  To illustrate the point, and to improve the way that we work, I've started with the Executive Committee (for EC read really important people who run the company) and performed our first retrospective on the way they initiate and support projects.

Interestingly they immediately came to the conclusion that we needed better processes, people, capabilities, systems and attitudes to delivery.  From the review of how projects were going in the organization it was clear who was to blame for project failures... anyone but the Executive Committee.  Indeed, apparently the only way that we could be better than our competition was to ruthlessly eliminate failure and hold accountable those who made it happen - or at least got caught making it happen!

On that we disagreed.  Aristotle noted that:

It is possible to fail in many ways...while to succeed is possible only in one way.

Successful organizations are those that can recognize that failure is a critical part of innovation and ultimately of success.  You must fail many times to find the one way to deliver success effectively. While going through this process you will fail many times but the true measure of a company's ability to respond to the market place and survive is their ability to quickly change direction and investigate many options on find the best possible solution.  Truly successful organizations have recognized that the ability to fail fast, change direction and respond to market demands is the only way to true commercial success. Examples include Yahoo, Google, Microsoft and Facebook.

Fortunately my clients are now mature enough to agree to take the time to discuss my point, review case studies of their behavior and then work to create an action plan that I really think will move us forward on our Agile journey.  More importantly the communications that followed the meeting stated that they accepted that "failure was a necessity that was the true mother of invention"

Will they stick to that philosophy?  Only the next few months will tell - but I know that my retrospectives, agile start-ups and discussions with the business will be a little bit easier over the coming days.  I just hope that we can demonstrate the point before our leadership team loses faith in the epiphany they've just had.


Mike

Reflections from a Brit living in the US - The battle of language

I think it was George Bernard Shaw who noted that "England and America are two countries separated by a common language".  Having spend time in the US for the last 8 months working with a team in the US to make them more agile & effective I can sympathize with that.  I ask for a check not a bill, I'm good not I'm fine, I eat food to go not takeaways and I ride in elevators not lifts.  I talk about organizations not organisations and analyze problems soup to nuts not root & branch.  What I have noticed is how quickly I've adopted these changes into my everyday life to the extent that my family at home often look at me and say "What?".

Reflecting on this at our local tavern (not bar) watching soccer (not football) I've started to make connections between the importance of language in managing change and gaining traction in moving organizations to a new way of thinking.

It seems that every time we want to make a change we insist on shrouding it with special terms and jargon.  So in moving an organization from Waterfall to Agile methods we find that they are two methodologies separated by a common language as well.  So we talk of stories not requirements, products not deliverables, storypoints not effort, sprints not tranches, backlogs not plans, blockers not issues and themes not goals.

During a recent summit of waterfall and agile advocates this week I found myself listening to strongly argued points of view and intense conflict between two project management factions.  We talked about command & control, structure, need for predictability and timely tracking of progress.  What became evident to me, very quickly, is that both sides were in violent agreement about they were trying to do - they just didn't understand each other because they spoke different languages.

To break this down I brought the conversation back to the five standard questions... Why are we doing this?, What do we need to deliver?, How can we deliver it?, Who's going to deliver it? and When can it be done?  I sent the groups away to list the methods they'd use to answer each of these questions without using any of the words that I provided in a taboo list.  They found it difficult to drop the jargon but 30 minutes later they came back and presented their answers to the other group with case studies to illustrate what they meant.

The result? Two almost identical presentations written in English that everyone could understand.  I've often seen cartoons where you can see a light bulb suddenly appearing above someone's head - and it was just like that.

Yes there are differences in philosophy between command & control and servant leadership but the basic project management concepts are exactly the same.  When you strip out all of the methods & terminology your simply left with a group of people who want to know why we're doing something, what's got to be done, when it's got to be done by and how we'll know it's been done correctly.

By removing the language barrier, and the emotions attached to it, working out a transition plan became a lot simpler.  Yes there are culture changes needs, new ways of working and training for those involved.  But the highest barrier to overcome is  the language we use.  It seems such a small change but it really has made a difference - I just wish I'd thought of it earlier!

I started this blog with a quotation so it seems fitting I should close it with one: 

Language is the biggest barrier to human progress because language is an encyclopedia of ignorance. Old perceptions are frozen into language and force us to look at the world in an old fashioned way. Edward de Bono

So a new way of working to add my experience in introducing change... build a common language that everyone understands.

Although, I don't think I can convince the whole of the US to adopt my way of everyday English so I'll pack that in the trunk, fill the car with gas and ride out into the sunset when I return home this weekend :-)

Mike 

 

Reality is your friend

I love the title of this piece. I can't claim credit for it though. It's part of an excellent article by Charlie Martin called Cargo Cult Methodology: How Agile Can Go Terribly, Terribly Wrong. In his interesting and amusing article Charlie gives a candid account of how a poor implementation of Agile concepts leads to project hell. 

He gives us three key lessons that he's painfully learnt in the past:

• People are willing to try almost anything to make things better—except of course to actually change (obviously others should change though)
• Watch out for "cargo cults"
• Reality is your friend

Having coached organisations through transitions to Agile I can relate to the attitudes and behaviors that he highlights.

I actually promised myself 12 months ago that I'd had enough of the pain & suffering that goes with selling Agile concepts to organizations and if I didn't see another "Agile Start-up" ever again that would be one day too soon.  I decided to find new industries and concentrate on delivering different types of projects rather than transformation change.

So what happened?  Less than 6 weeks after making that commitment I broke it and here I am again looking at another failing Waterfall project organization who recently decided that "we need to get better so let's go Agile" and have asked for help to transform the way they deliver projects.  

Why oh why didn't I learnt that this is going to lead to lots of discussions on command & control, flexibility, changing attitudes throughout the business not just IT and the day to day frustration of simply asking the question "really if you look at what you're doing do you really think that's Agile?"?

Clearly the answer to that question is no.  Here I am again giving the sales pitch, showing the scale of what they've actually decided to do and trying to work through a transition plan with the business and IT groups.  Reading Charlie's article really gave me a boost because he's hit the nail on the head and I've started to list his lessons at every executive presentation I've given in the last couple of weeks.  If you're not sure what a cargo cult is I suggest that you click on the link and read his article - you'll like the story.

So do I have any insights from the last few months outside of Charlie's lessons? Yep.

The first phase (doesn't sound very Agile does it - ironically I came to the conclusion over the years that that you have to use the current waterfall methods to transform the organisation to agile concepts) involved going out to all of those people, both internal & external to the IT group who delat with them on a regular basis and interview them from the main board to users.  80 interviews and 450 survey responses later common themes about the way IT delivers came through.  

Top three? 

1. Need to become a trusted partner not a software shop

2. Need to be more transparent

3. Need to fix the basics and put reliability and robustness, not exciting new technologies, at the top of their priorities.  

Actually there were a lot more than that in the 250 page presentation but these were the main highlights.  The IT Group had to stop fighting the business and start to become a true business partner.  Furthermore, the lost opportunity costs and the more real overspends on projects were added up and made scary reading - just in time for Halloween!

Hmmmm - there was a lot to fix but actually showing that the business didn't comment on the capability of IT group.  Actually they recognized that they delivered excellent solutions and that they would not want to deal with anyone else simply because "these guys are passionate about our business" .  But waterfall methods had lead them into silos that had lost the ability to "talk" to customers and gaining a reputation for building software rather than enabling business solutions.

Interestingly on one of the many questions people were asked - How well do you think IT engage with the business?  80% of the IT people questioned said "really well - great relationships" but only 20% of the business responded in the same way.   Shocked?  Well not as shocked as the development teams were when the results were published.  

As Charlie notes - "Reality is your friend" and learning how others view can be a very difficult lesson.  However, what it did was show how much we had to change to become that "trusted partner" and that it would be a journey, not a step change, that we'd have to make.

So what's happened?  We have a very committed CIO and Leadership team who truly know where they are and what needs to change.  Couple that with sessions on the transformation needed to become "Agile" and the reasons "why" and the scale of the change is obviously even to the most dyed in the wool command and control advocate.  So I'd really recommend that you find out what your customers think and use their feedback to get commitment - Reality wins every time - especially when we're talking impacts on bonuses :-)

I'll keep you in the loop as we learn more lessons but take time to read the rest of Charlie's article - it's great.

Mike