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

Tyranny of teams & collaboration

Ok I admit it - I'm a closet introvert.  I live in a world where working collaboratively in teams, and all that it means, really turns me off.  It's not that I don't like people - it's just that I'd rather have a bit of piece and quiet rather than chats around a table (or so called "meetings"), desk to desk flirting or attending suspect "fun team building" events.

As an introvert of course I blamed myself.  I'd thought that this was just me - a sort of social psychopath - who was simply destined to be left out of the fun & comfort of group thinking. Now I'm pleased to see that I've a group of my own who believe that solitude produces the best results.


Susan Cain is the author of Quiet: The Power of Introverts in a World That Can't Stop Talking.  She is passionate about the role of the introvert in creativity, innovation and original thinking.  Through impressive research she demonstrates how much we undervalue the role of the introvert and how much we lose out in doing so.  In doing so she notes Babbage, Dawin, Piccasso and others as prime examples of great thinkers who'd rather think alone.


So apart from making me feel less of a social misfit what does Cain's philosophy   teach us?  It's best to take Cain's own words from a recent interview in Scientific American...

When you’re working in a group, it’s hard to know what you truly think. We’re such social animals  that we instinctively mimic others’ opinions, often without realising we’re doing it. And when we do disagree consciously, we pay a psychic price.

The Emory University neuroscientist Gregory Berns found that people who dissent from group wisdom show heightened activation in the amygdala, a small organ in the brain associated with the sting of social rejection. Berns calls this the "pain of independence.

Take the example of brainstorming sessions, which have been wildly popular in corporate America since the 1950s, when they were pioneered by a charismatic ad executive named Alex Osborn. Forty years of research shows that brainstorming in groups is a terrible way to produce creative ideas. The organisational psychologist Adrian Furnham puts it pretty bluntly: The "evidence from science suggests that business people must be insane to use brainstorming groups. If you have talented and motivated people, they should be encouraged to work alone when creativity or efficiency is the highest priority."

This is not to say that we should abolish group work. But we should use it a lot more judiciously than we do today

From an Agile perspective she makes an important point.  Much of the wisdom of Agile is the importance of teams, getting teams working together, establishing collaboration, team bonding and collective responsibility.  However, in doing that we're also in danger of suppressing innovation & creativity through group think or hive mentalities.

We often think of anything that doesn't foster "team work" as anti-agile but Cain's book reminds us that individuals are just as important as the team.  Of course, introverts have annoying qualities.  They don't speak up when they see problems, they're terrified of speaking in a public forum, they let sleeping dogs lie rather than challenge and they're often seen as unambitious.  It takes a different sort of leadership to get the best out of these people.  


So ask yourself a few questions:

1. Do you value group think over individual contribution?
2. Do you believe that Agile and Projects are "all about team work"?
3. Have you determined who in your team is an introvert, extrovert or in-between?
4. Have you considered the best way to manage each team member to get the best out of them? - enforced "collaboration & fun" is often counter productive
5. Are you providing the one to one environments where these people can express their views?
6. Do you provide quiet areas where introverts can get on with their work in relative peace?

Terence Blacker in The Independent recently highlighted a survey of companies citing:

In a survey of 600 computer programmers at 92 companies, it was found that, while people within the same firm performed to similar levels, there was a huge gap in effectiveness between one company and another. It was those which offered staff a degree of privacy which produced the best results.

He also went on to note that:

A more convincing explanation is the unquestioned and wrong-headed assumption that, if one person can produce a good idea, several together can only achieve more. Our culture may be self-obsessed but, weirdly, it is also one in which the noise of crowds and groups drowns out the unconventional and individual.

I strongly recommend that you look through the links I've provided in this blog.  It's a new way of thinking that can enable you to get even more out of your Agile teams and the individuals within them.  As a member of the undervalued society of introverts I hope that you'll take my advice - if you don't mind of course and if you can hear me above all of this team building NOISE!


Mike