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

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

What comes around....

Now I realise that I've probably been in the delivery business too long or I'm getting old. 

I've got used to the fact that fashions keep changing but keep coming back to the same styles.  Rock music that I loved in the 70's and 80's is becoming popular again - well at least with my teenage daughters. 

So nothing really changes - everything just goes in cycles - around and around and nothing really new is invented.

Now Agile is maturing it's under threat from a new approach - Kanban.  If you're not sure what Kanban is then have a look at this great Kanban 101 guide.

I read this article and I thought - "Hang on a moment - I remember Kanban from 30 years ago when I first started out as a Manufacturing Consultant". I was implementing 'Just in Time' and the 'Theory of Constraints' in JCB, Texas Instruments, Caterpillar and other organiations.  It was the latest thing at the time and the subject of the famous book "The Goal" Now 30 years later I'm being told it's "new" and the "in thing"!

Looking on my bookshelf I've still got all of the white papers, articles and stuff that I created all that time ago.  Maybe I should dust it all off and get ready to write the "Forget Agile it's old hat - implement Kanban - you know it makes sense" novel.  Alternatively I could just call it - "Common sense - it just doesn't get old" Unlike me :-)

Mike

Long break - has it affected your sprints?

After the long break that we've all just enjoyed I'm reminded that I often get asked if teams should have a break between sprints to recover and prepare for the next sprint.  My answer is always the same.  One of the core principles of SCRUM is "sustainable development" and so no I don't think that there should be a break between sprints.

Breaks between sprints lead to a constant need to build momentum and that's just an ineffective way of operating.  The team velocity constantly keeps changing.  So the sprints should be run back to back and we need to make sure that the development effort is sustainable, workloads properly balanced and that SCRUM & innovative remains fun approach not a constant burden to carry.

Of course, a number of companies don't operate real SPRINTs at all.  They run small three/four week waterfall projects that deliver something at the end.  You know what I mean... One week for design, one week for development and one week for testing rather than integrated design, develop & test activities. 

The problems this causes is identical to their Waterfall big brother:

• Testing being squeezed at the end of the cycle and either not completed properly or causing "delays"
• Everyone rushing at the end to complete things that can't really be completed in the time available
• Everyone working extra hours & weekends to deliver what they promised
• Everyone getting increasingly stressed as the end of the SPRINT looms large.

Of course this isn't a problem if it's just a one-off at the end of a project - but if it's happening every three weeks then it's going to make development harder & harder to complete.

Add that to the "technical" debt that SCRUMs slowly develop over the first few sprints without automated testing or integrated development and you've a recipe for serious conflict!

So look honestly at your SCRUM process during your next retrospective.  Are you really running small waterfalls?  Is your team getting stressed?  Can your team get better at working together on parallel design, development & test?

I promise you it'll make everyone's life so much better and you'll deliver so much more.

Mike

Agile Qualifications...

I've always been a little worried about the current clamouring for Agile qualifications.  With the PMI, SCURM Alliance and APM all trying to get in on the act my concern was that we're going to end up with a whole pile of conflicting qualifications - just like Project Management before it.

Now it seems that I was right to worry.  I've never really been a fan of the Certified SCRUM Master which seemed to be given out on courses for just turning up in some cases.  The same has been true of some project management certificates.

Apparently that's all going to change.  However, what I wonder is why anyone thinks that a "paper based" examination really gives any idea of the skills of an individual - and yet that's what we seem to keep getting.  Moving towards a more Vocational Qualification approach would not only challenge people to get the right sort of training but also encourage the use of methods & ideas back in the workplace.

If you want to see the latest comparison on Agile Qualifications then give the following article a good read.  It seemed very interesting to me!  Check it out by clicking What's the latest in Agile Project Management Qualifications?

Happy Easter

Mike

Agile isn't just for software!

Just stumbled on this Declaration of Independance site by accident - but I'm really pleased that I did.  I really believe that Agile applies to all project environments - not just software.  In some ways it reminds me of project management that, for many years, was entrenched only in the construction industry and so called "hard" projects.  Now, 20 years later, project management is found in just about every industry and organisation.

Now I'm not a real fan of the concept of "Agile Project Management".  I think that the mindset of most projects is completely different to that of an Agile implementation.  Until we can change the mindset of Leaders & Managers we're always going to struggle to make Agile work effectively.

The Declaration of Independence is just one of those starting points.  It takes the Agile Manifesto and widens it's application to a range of other possibilities and demonstrates how Agile can be applied outside of software development.

Take a look - and become a signatory if you think it's worth pursuing.

Have a great Easter

Mike

Agile & Communication

After the success of the Agile & Stress and Agile & Empowerment handouts I've now uploaded the Agile & Communications presentation.

Communications is often an undervalued part of dealing with others - especially when leading teams to deliver change.  Most of us are taught some of the basic skills of reading & writing but schools tend to forget the importance of active listening, non-verbal communciations and how to deal with the barriers that stop it happening effectively.

Our ability to be able to communicate is key to other management skills.

Without effective body language reading skills or an appreciation of what people are really trying to tell our ability to negotiate, deal with conflict & motivate others is immediately impacted.

Looking at all of the projects that I've had to turnaround in the last few years I would say that 90% of my success has been due to getting people to communicate more effectively and, making sure that I'm communicating well at the same time.

In follow-up blogs I'll deal with Negotation, Conflict Management and Consultancy Skills.  If anyone would like copies of the exercises that I use on the courses feel free to drop me a line.

Thanks for taking the time to read :-)

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

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

Agile Project Management - does it really exist?

Probably the most common question I get is "Is Agile really that much different to traditional project management - surely they're the same thing really?"  In the past I agreed.  I couldn't see why a decent project manager wouldn't be just as much at home running Agile Development as Waterfall Development.  In fact, I believed that the Agile thing was a bit of hype & bluster and was really just another way for large consultancies to realise just a bit more fees from their creaking accounts.

Now I have to admit I was wrong.  Not just "a bit" wrong but "you've completely missed the point" wrong. 

It was a friend of mind who's also a great Agile Coach, Bob Lupton, who put me on the straight and narrow.  He was passionate that I'd really missed the point.  That Agile wasn't really what we were trying to achieve - the most important aspect was Agility.  To understand that I needed to rethink my whole philosophy on how projects should be delivered.

The most important of these was understanding the mindset I needed if I really wanted to be Agile.  I had to let go of my "Command & Control" management approach, something I've built up over the last 20 years, and embrace "Servant Leadership".

Not being sure what that meant he went on to explain that I'd always seen myself as responsible for delivering the project.  If problems happened I'd take charge and escalate issues to the relevant managers.  Indeed, I'd even set up Rapid Action Teams on some of my larger programmes to deal with major issues that kept happening.  What I needed to do, he explained, was to delegate issues, get the team to take responsiblity for finding the solution and mitigating the problem.  My team would do this in full consultantion with the Product Manager.  Mainly, I had to show trust in the team and, when needed, provide leadership that supported them rather than managing them.

Actually that was what made me think about the whole way that we train our project managers.  We educate them in the ways of PRINCE2 and MSP - both of which are prescriptive processes.  Every aspect of the project is the responsiblity of the Project Manager and we make sure that we control everything.  As a result, in our efforts to control everything we stiffle innovation, relevance and benefits to meet arbitary deadlines & budgets which, quite frankly, no one cares about once the project is complete.

Do I think Project Managers can be Agile?  Absolutely - as long as they have the right mindset to lead rather than manage.

Do I think Agile Project Management exists?  I really hope not.  It seems like too much of an oxymoron for me.  You can have Agile or Management but not both.

In fact, I'm becoming more and more convinced that the time of the "project" may be over.  A project is really just a container for activity that delivers a specific outcome or change - does it really need all of the baggage that goes with it?