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

Agile - A Christmas Tale

 It's that time of year where everything starts to wind down as we all get ready for Christmas.  It seems to start earlier every year with most of the people on my project already off for Christmas and not thinking of returning until the New Year.

I was thinking of writing an "Agile Christmas Carol" or some blogs on learning lessons from reviewing how making toys in Santa's workshop is one of the best examples of Agile processes in the world and they still meet the deadline every year so Agile clearly does work.

But after much thought I realised that Christmas is such a magical time that it's real purpose is to spend more time thinking of important things - especially my family - and getting a break from trying to convince people that less control really does mean that you can get the best out of everyone.

So I'd like to thank everyone whose contributed to Keeping Agile Simple this year and look forward to working with you all in 2012.  There's so much more we can do to take Agile forward without defining processes, systems or generally making it more complicated that it needs to be.

And as it's Christmas I'd like to share Clement Clarke Moore's poem (sometimes attributed to Henry Livingstone)  for two reasons.  One because I was taught it by my Grandmother, another character I've mentioned in these blogs before, and second to prove that there were only EIGHT reindeer originally (in the 1823 poem) and Rudolf wasn't added to the myth until 1939 by Robert May for the Montgomery Ward Department Stores in a book that they gave away to children in a PR campaign.

Knowing this poem has helped me win a number of Christmas Quiz rounds at our local bar where "Name Santa's reindeer" is a common seasonal question.  Indeed my daughter, now studying at Birmingham City University, won their local bar contest my naming all of the reindeer successfully.  However, they incorrectly insisted all NINE original reindeer had to be named - clearly standards are dropping in our great educational establishments!

So a Merry Christmas to all of our readers and enjoy again the very best of Christmas stories.

Twas the night before Christmas, when all thro' the house  Not a creature was stirring, not even a mouse;The stockings were hung by the chimney with care,In hopes that St. Nicholas soon would be there;

The children were nestled all snug in their beds,While visions of sugar plums danc'd in their heads,And Mama in her 'kerchief, and I in my cap,Had just settled our brains for a long winter's nap —

When out on the lawn there arose such a clatter,I sprang from the bed to see what was the matter.Away to the window I flew like a flash,Tore open the shutters, and threw up the sash.

The moon on the breast of the new fallen snow,Gave the lustre of mid-day to objects below;When, what to my wondering eyes should appear,But a miniature sleigh, and eight tiny rein-deer,

With a little old driver, so lively and quick,I knew in a moment it must be St. Nick.More rapid than eagles his coursers they came,And he whistled, and shouted, and call'd them by name:

"Now! Dasher, now! Dancer, now! Prancer and Vixen,"On! Comet, on! Cupid, on! Donder and Blitzen;
"To the top of the porch! To the top of the wall!"Now dash away! Dash away! Dash away all!"

As dry leaves before the wild hurricane fly,When they meet with an obstacle, mount to the sky;So up to the house-top the coursers they flew,With the sleigh full of toys — and St. Nicholas too:

And then in a twinkling, I heard on the roof  The prancing and pawing of each little hoof.
As I drew in my head, and was turning around,Down the chimney St. Nicholas came with a bound:

He was dress'd all in fur, from his head to his foot,And his clothes were all tarnish'd with ashes and soot;
A bundle of toys was flung on his back,And he look'd like a peddler just opening his pack:

His eyes — how they twinkled! His dimples: how merry,His cheeks were like roses, his nose like a cherry;
His droll little mouth was drawn up like a bow,And the beard of his chin was as white as the snow;

The stump of a pipe he held tight in his teeth,And the smoke it encircled his head like a wreath.
He had a broad face, and a little round belly  That shook when he laugh'd, like a bowl full of jelly:

He was chubby and plump, a right jolly old elf,And I laugh'd when I saw him in spite of myself;
A wink of his eye and a twist of his head  Soon gave me to know I had nothing to dread.

He spoke not a word, but went straight to his work,And fill'd all the stockings; then turn'd with a jerk,
And laying his finger aside of his nose  And giving a nod, up the chimney he rose.

He sprung to his sleigh, to his team gave a whistle,And away they all flew, like the down of a thistle:
But I heard him exclaim, ere he drove out of sight —Happy Christmas to all, and to all a good night!

Merry Christmas and a Happy New year

Mike

Agile projects don't work - it's a puzzle!

While contemplating project management, Agile and different organisations I've come to the conclusion that there are certain companies who don't seem to be able to get to grips with any form of project management.

I've tried to understand what these companies have in common and I've suddenly had an epiphany.  They all have strong operational functions from which they grew into the larger organisations they are now.  For example, Airlines, Leisure and Logistics all developed from doing one thing very well time & time again.


They get everything about their operation.  


First of all they appreciate that you need capable people.  I've often thought that I could run a bar, manage an airport or run a courier firm better than the people who are serving me.  But I'm wrong.  These jobs take specialist skills that might not immediately be apparent but are vital all the same.  So these successful organisations attract & recruit the right people, give them the right training and provide on-going coaching & support.  


Second, they realise that a successful operation is only possible if you have the right systems and a clear and understandable process where everyone knows what's expected of them.  Only with these in place can you provide excellent customer services consistently time & time again.  


Finally they realise that you need to keep a track on things and define metrics that show you how you're meeting your organisational goals and if anything isn't working as it should.


Because they get it - they run successful companies that everyone admires.


But when it comes to projects - you know the activities that are going to maintain & improve their offerings, transform their company to realise unique selling points in the marketplace and grow revenues to maintain profits - they completely miss the point.


In every service industry that I've worked I've now realised that the attitude of senior managers to projects is exactly the same.  

• Anyone can run a project so long as they're a subject matter expert
• Planning, systems and processes just add to the time it takes to deliver
• Don't need reporting or metrics to ensure benefits are nailed from the outset
• Can't understand why their projects aren't as successful as their operations

Of course it seems obvious to us.  


The same disciplines that make the operational side of an organisation deliver are exactly the same as the ones needed to deliver projects successfully consistently, increase speed to market and maintain control of budgets and quality.  It doesn't matter which methodology you subscribe to the factors for a successful operation work just as well - be it Agile or Waterfall.


So if you're thinking - why don't my projects deliver as well as they should think to yourself - why are we so successful in delivering customer service? If you can understand that you know what you have to do to make your projects better.


So right now my challenge is to bring this insight to others - I suspect it's going to be a bigger task than I think.


Does anyone else have any other insights that might help me?





Mike

Improv Comedy & Agile - Yes and...

Keeping Agile Simple isn't easy and language, what we say and how we use it, is a bit part of getting people to accept new ways of working.  This week I was presented with a 9Mb spreadsheet containing a glossary of "standard speak" that I'd need to become familiar with. It's one of the most difficult bits of joining a new group.  Understanding their project portfolio - easy, getting to know new people &  their aspirations - easy and getting agreement to a new approach to delivering projects - easy (ish).  Understanding what the hell RevPAR or RGI could stand for - impossible.  And apparently I'm not alone.  

TheOfficeLife.com  have a full "business speak" directory - you can find it by clicking here.  It's full of interesting words and I did learn that Agile is an Adhocracy [n.] "A minimally structured business where teams are formed as they are needed to address specific problems" and that Management Porn [n.] "a long slide presentation of useless facts and figures, created to distract managers and give them something to salivate over"

Now I realise that there are some places where specific jargon & abbreviations actually add value.  In an Accident & Emergency hospital where time is of the essence, being able to communicate rapidly & precisely is very important - but is that really important in day to day business discussions (unless of course your business is managing A&E)?

So back to my new company.  Apart from them being one of the most genuinely friendly group I've ever met - I've already learnt some good lessons from them. As part of our team building event in my induction week we attended a Improv Comedy Workshop at the Comedy Store, Leicester Square.  It was full of the usual "making a fool of yourself" activities but there was one thing that's really made me think.  To see what I mean try the following exercise.

Find a friend and sit opposite each other - it might be easier if you've had a beer or two.  One of you should start a random story (Hopefully one more fun than this one) such as "Billy was a bright project manager who loved Agile."  Your partner then carries on the story starting each sentence with the phrase "Yes and...". 

For example 

Partner - "Yes and although he found it difficult to accept he wanted to apply it in his projects but it didn't work on the marketing project"

You - "Yes and so he thought about how he could make it work and he realised he need to communicate more which made it more successful" 

Partner - "Yes and he started to use a lot of other techniques from Agile which made things a lot easier"

and so on...

Now try the same activity but now use the phrase "Yes but..."  It might sound something like this:

You - "Billy was a bright project manager who loved Agile."

Partner - "Yes but it didn't work on the marketing project"

You - "Yes but he thought about how he could make it work and he realised he need to communicate more"

Partner - "Yes but people didn't want to listen to him"

You - "Yes but he worked out why they were resisting Agile and helped them understand it"

Partner - "Yes but people wouldn't do what they said they would"

In the first example we've got a positive discussion on Billy & Agile in the second we have an argument.  Just by simply starting each sentence with "Yes and.." we maintain engagement, interest, motivation and get real value from the discussion.  In the latter we block and build up more and more resistance and conflict.

To see professionals look for "Improv Yes and" on YouTube.  For an example see this video here.

Essentially you're accepting an offer from your partner with "Yes and..." to build and extend the story positively.  "Yes but..." simply blocks the conversation making it difficult to continue and gain acceptance or maintain creativity.

So next time you're talking with you team try and think "Yes and..." before each sentence - you'll get them onside much faster and they will think more positively & creatively. Start with "Yes but..." and their motivation will soon die as quickly as a bad stand up comedian.  You don't actually have to say "Yes and..." in your meetings but you at least must think it before each conversation.

Thanks to Luke at the Comedy Store - Leicester Square for that life skill.  Really you should consider going and learning Improv - it was a great experience especially when you get to see real experts doing it later.

See you soon

Mike

Agile - Grandmother was right - you can't fit a quart into a pint pot

My Grandmother used have lots of sayings.  I remember - "We had one of those and the wheels fell off", "As much use as a chocolate fireguard" and "Look after the pennies and the pounds look after themseleves".  My favourites as a project manager were "If you're in a hole don't dig" and "you can't fit a quart into a pint pot".  It's the last one that came to mind today!

Lean project management has lots of great attributes – more effective use of people & resources, better quality development, increased communications and faster time to market.  Yet however hard I look through research & documentation I can’t find the evidence that it’s also some form of “miracle worker”.

I’ve been involved in a lot of discussions on failing projects and the reasons for failure always seem to be the same – no one really thought about how they were going to do it.  Of course people understood why and, to a certain extent, what they want to do.  But when it comes to – so how are we going to do it – managers wanted to avoid the self-evident truth.

But back to basics - it doesn’t matter what methodology you use you’re still going to be faced with a fundamental aspect of physics.  If a project has a certain amount of work involved to complete it then it really doesn’t matter which approach you adopt – Waterfall, Agile, RUP or Lean – it will still take the same amount of time & effort to finish. A quart doesn’t fit in a pint pot…

Of course, lean approaches are better at focussing on real requirements and what will add value.  They deliver functionality up front avoiding big bang delivery.  However, there are implementations that need a base amount of functionality to be useful & chores to be completed to generate any significant value before they can be rolled out.  It doesn’t matter if we work as a small team, communicate better, concentrate on high value items or adopt Scrum methods to concentrate on great delivery processes ultimately the development work that needs to be done remains essentially the same.

Today I’ve had the ultimate Agile discussion.  Essentially it consisted of:

Looking at the user stories we’re looking at 4 sprints to complete the base functionality and probably another 3 to add the high priority business requirements.  That’s about 21 weeks.

But we need it by Christmas

I appreciate that but that doesn’t change the amount of work that we need to do it will still take 21 weeks

But we need it by Christmas

What requirements do you want us to drop?

None – but we need it by Christmas – maybe if you don’t test it so much?

The work hasn’t changed – it will take 21 weeks

I thought Agile was meant to be quicker?

It is more focussed and relevant but it can’t make 21 weeks of work take 10 weeks

I think you get the idea…..

That’s the problem with something being sold as the new solution.  Everyone says Agile is quicker, faster & more improved.  Of course we all know it isn’t but that’s the press it’s got.

So I’m left with the age old problem.  Lean project management is a much better solution to delivering great software.  However, it’s reputation is going to be tarnished by a few individuals who’ve sold the “faster” tag and Agile can’t always deliver.  I’m sure that someone soon is going to suggest that planning things upfront, signing up to detailed designs & requirements and agreeing a detailed plan that managed centrally is the best way to get things delivered quickly.  I wonder what they’ll call that approach – I suspect it will be popular if they promise to deliver 21 weeks work in 10 weeks by simply adding more people.

I’ll let you know how the argument is resolved.

Mike

Agile, Hitchhikers Guide to the Galaxy and Fire Control

"Perhaps they are singing songs to you, and I just think they're asking me questions" explains the Ruler of the Universe when talking to his cat.

I've been reading the Hitchhikers Guide to the Galaxy - Resturant at the End of the Universe for the nth time this week.  I've always loved Douglas Adam's sense of humour and there is a particular section that really sums up the problems I've had this week with a new "Agile Team" that have asked me to coach them and help them understand why people aren't accepting their new approach.

In one part of the story Zaphod, Trillian and Zarniwoop visit the man who runs the Universe. He clearly isn't what they expect and he tends to avoid answering a question directly.  It's worth a read and you can find the book online here.

Apart from being an amusing distraction I think it highlights some of the problems that Agile Projects have to deal with all of the time.  This week in my new team we've discussed our Agile approach, the impacts it has on our customers & our teams and what we should do to improve things.

Without exception it's been one excuse after another.  Sitting in the meeting room (just like the Ruler of the Universe's shack in the middle of nowwhere) you'd think the the rest of the organisation doesn't exist once the meeting room door is closed.  The team deny that they simply aren't delivering what's needed.  They can't remember the questions that were raised at the last retrospective and anyway they are in denial that their unstructured approach is leading to all sorts of problems and issues.

Douglas Adams writes "How can I tell, that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?"

The equvalent I heard in this group today was "I think that customers have decided they don't like the Agile approach so they're making up issues just to get us to go back to the old ways of working"

The lack of ability for an Agile team to accept personal accountability & responsibility for delivery is a hangover from the Waterfall Approach.  It can be argued, and indeed I have many times, that the PRINCE2 methodology provides the Project Organisation with lots of hiding places.  In the news today you will have read about the £469m Project Failure of the FiRe Control Programme (BBC article).  What wasn't recorded was how all of this money was wasted.  £40-50m on "Management Fees", £20m on "Consultancy" fees.  The actual buildings only cost £36m (nine buildings at around £4m each) or £14m less than the Project Management fees!

Funnily enough though there's no one to blame.  No one is accountable and everyone did a good job apart from the fact that nothing actually got delivered and none of the project objectives were met at all.

That's how this team and the project have felt this week.  Close the door and hide from the real world.  Nothing's our fault, we've nothing to learn so I think that I've nothing I can teach them either.

Pity - because they're a great bunch of people and I hate to admit failure.

Tomorrow's another day - and at least we haven't wasted £469m!

Mike