Showing posts with label #people skills. Show all posts
Showing posts with label #people skills. Show all posts

Friday, 2 November 2012

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 

 

Monday, 23 May 2011

Agile - it ain't our culture revisited...

Thanks for all of the responses to my last blog "It ain't our culture..." - I obviously hit a bit of a nerve.  I'm not the only one who's getting fed up with the "Corporate Clone" culture where we think that everything will work out ok if we just keep trying the same thing again and again... 

Other examples that I've had sent to me include:

Confusing

"Your problem is that you're too focused on delivery and that's just not the way that we do things around here..."

"We don't manage stakeholders... we control them..."

Downright sexist

"Don't get me wrong... Proper project management needs a strong manager - I think that Agile is more fluffy and people focussed - a more female way of delivering projects..."

Misguided

"You've been lucky in the past because we know that you can't deliver anything if you're going to concentrate on business value.  I mean if the customer is part of the project team and they just deliver what they want you wouldn't need project managers would you?"

The problem as I see it is that people are struggling with the changes needed to get Agile working.  It is different, you do need a different attitude and the change to make it work at an Enterprise level is significant.  As luck would have it there are two people who can explain far better than me.

The first is by Gregory Smith - Creating an Agile Environment  and the second is Kane Mar - Impediments to Enterprise Agile.

Two very different articles but one clear message.  You need to look at your own attitudes, views and approaches and change them fast.  If Agile "ain't your culture" then you'd better make sure you make it your culture soon if you want to keep up with your competition. 

Thursday, 14 April 2011

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...

Wednesday, 13 April 2011

Agile and Stress

For the last two weeks I've begun to realise the degree of stress that the Agile transition builds in the Project Team.  Changing from Command & Control to Servant Leadership is a difficult thing to do especially for someone who's been trained in APM or PMI.

To try and address this balance I'm going to be sharing some of my resources that I use for training SCRUM Masters and Product Managers.  Specifically I'll be uploading presentations on Conflict Management, Negotiation, Consultancy, Communications and Stress Management over the next few days.

To start us off I thought that Stress would be a good topic given the week I've had :-)

I really believe that people underestimate the impacts that stress have on project failure but most of us have seen if first hand.  This first presentation highlights the psychology of stress and where it comes from.  As anticipation is a major contributer to stress I'll mention that I'm loading the next in the series tomorrow... Empowerment.

Look here for the Agile & Stress presentation

Mike

Process will be the death of Agile

"Agile is Simple" I keep getting told by the evangelists and of course, in concept, it really is.  The trouble is that it's human nature to want to "know things" with certainty.  None of us really like anticipation.  Oh I agree it's exciting but given a choice between "knowing now" and "knowing at sometime in the future" we'll always pick NOW.

There have been a lot of studies to do with Stress and, without fail, they all show that ambiguity and uncertainty are top of the list.  So it's little wonder that when "Product Owners" and "Developers" aren't properly collaberating the whole "Agile thing" becomes more complex and frustrating.

This short video makes the point much better than I can.  Enjoy!

Another SCRUM Perspective