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 

 

Agile - why doesn't it work except in the "trial" period?

I've spent a lot of time over the last few weeks talking about the problems of change.  Now I'm thinking that Agile is always going to struggle because of the "siloed approach" that organisations innately adopt.  It's covered really will in this article "Challenges of managing change in a siloed organisation"

The biggest challenge that Agile has is the capability of an organisation to deal with it the decentralised approach.  When Agile is trialled at a local level it seems like the answer to all of those inertia problems that projects seem to produce.  Of course we tend to forget that the trial project has a lot of support, gains the best possible resources and is given the highest priority so it's pretty likely to success regardless of the methods that are employed.  However, at a local level - it all goes well - a fact that many Agile Consultants rely on when they promise to help you "mobilise Agile".

But as we start to ramp up the process across the organisation the cracks beging to appear.  They're not inherent problems with Agility but rather that the approach & mindset in Agile brings the flaws that already exist in the operating model into focus.  There are two ways for the cynic to look at this:  "Agile doesn't work for us" or "Agile doesn't work in the real world".  However, the real problem is that many projects & programmes would have suffered regardless of the method being used - it's the corporate culture that's wrong.

People talk about being "Open and Honest" but aren't really that keen when everyone actually is... we like a bit of wriggle room where things can be glossed over.  Perhaps Agile should stop "making everything sooooo transparent" and concentrate on dealing with the Siloed organisation issue and it's politics.  If we can make Agile work in a siloed environment we may really be onto something exciting...

Mike

Agile and Empowerment

Carrying on the presentation series from yesterday's Agile & Stress I've uploaded another session on Empowerment.

Now for me I don't really like the word "empowerment" - I prefer the word "trust".  I don't "empower" my teams I "trust" them to get on with the job they've trained for.  It reminded me of a presentation I onced attended by the then CEO of Unilever.  He had already listened to the HR Director explaining how they recruited, trained and then empowered people in Unilever.  He explained that "That's what I dislike about HR.  We don't recruit we attract.  We don't train - we develop and we don't empower we trust our people to get on with the job that we pay them for".  I'm not sure what happened to the HR Director afterwards but it seemed like a pretty strong dressing down to me in front of the Top Unilever Management.

Empowerment is covered really well in Zapp!: The Lightening of Empowerment by William C Byham. The book is written as a readable story in the same way as Goal! a process of on-going improvement and The Noah Project.  This approach makes it easy to read and appreciate the ideas without a lot of "consultancy speak".

Today's link is part of my Agile People Skills presentation and covers Empowerment in an Agile environment.  Tomorrow I'm thinking of uploading Agile & Communications (verbal & non-verbal) which most people say is the most useful part of the entire training session!

Leave me some comments if you'd like me to cover some other Agile topics as well

Mike

Let me know your comments...