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



 

Can Agile Horses Sing?

While lazying in the back garden I've had lots of time to reflect on the last 12 months.  I've always thought that the retrospective was one of the best parts of Agile (or indeed of any decent methodology) because it's the one opportunity to concentrate on simply doing things better.

So have I learnt anything that will help me help others better in the next 12 months?  I guess that one of the advantages of being a turnaround project manager is that you get to see a lot of project train wrecks and get the opportunity to see them become successful ventures.  Ok, they don't always deliver exactly what you'd hoped when you put together than business plan but in most cases they deliver greater value simply because you had to concentrate on what you needed rather than what you wanted.

I've a few pet hates.  One of those are people who seem to think that they can diss the case for Agile by saying "...oh yeah BUT in the REAL WORLD..." I've spend the last 6 months helping my eldest daughter with her philisophy A2 Level and 50% of that seemed to be about deciding if the world we live in really exists or not. There are arguments that it's completely in our heads, that we rely on sensory data and make up a world to intepret it and that none of us really see the real world - it's a bit like watching a film.

That's exactly how a recent experience has been for me.  I feel I've been living in a surreal environment which is so far from the real world that I'm beginning to believe what all those philosophers were on about - it's just like watching a film.  Unfortunately not a comedy, although there have been moments, nor a action filled movie.  If I had to describe the style I would have said a bit like the Hammer Horror films of the 70's - unbeliveable storyline, no real purpose and a lack of anything that you can relate to real world thinking.

Let me expand.  Firstly they really think that they're Agile.  They have a Scrum Board, hold daily standups (ok they have 20 people attending and they take over 90 mins but they do stand up) and they consume vast quantities of post-it notes.  I've watched this board for the last three weeks.  Everyday they discuss progress but not one single post-it note has ever moved.  I actually checked to see if they were glued down.  They've never seen anyone from the business but they don't need to because they already know what the solution is.  One product owner dared to send a list of requirements and these were immediately put onto post-it notes and placed in the "blocked" column on the Scrum board - "At least it looks like we're working on those if Bob turns up one day".

Yesterday I sat in a meeting where the IS Programme Manager presented the plans for the next release which is happening in 10 weeks!  Actually he also presented what would be in the releases in Q1, Q2 & Q3 for 2012 as well.  So let's get this straight - Detailed plans for 2011& 2012, releases fixed 12 months in advance, scrums of 20+ people having one & half hour meetings every morning and a lack of customer involvement in development - but we're Agile?  I ran the first Agile Training sessions this week and everyone loved it.  Of course "it won't work in the real world..." was the general feeling.  "And what you're doing does?" I argued.  "Every project you have running is late & overbudget, customers are complaining about bug-filled software & threatening to leave and staff turnover reaching 40% per year".  Apparently that's the point - they're running Agile and it clearly doesn't work in the real world.

Sadly, I don't think I can convince them - they really believe that they've adopted Agile and they really believe they're living in the "real world".  It's a shame a because the business proposition they have is fantastic but they can't change their mindset sufficiently to deliver a solution to meet it. 

But I've accepted the challenge because reminds me of the story of the Prisoner & the King. 

Nasrudin was caught in the act and sentenced to die. Hauled up before the king, he was asked by the Royal Presence: "Is there any reason at all why I shouldn't have your head off right now?" To which he replied: "Oh, King, live forever! Know that I, the mullah Nasrudin, am the greatest teacher in your kingdom, and it would surely be a waste to kill such a great teacher. So skilled am I that I could even teach your favorite horse to sing, given a year to work on it." The king was amused, and said: "Very well then, you move into the stable immediately, and if the horse isn't singing a year from now, we'll think of something interesting to do with you."

 

As he was returning to his cell to pick up his spare rags, his cellmate remonstrated with him: "Now that was really stupid. You know you can't teach that horse to sing, no matter how long you try."

 

Nasrudin's response: "Not at all. I have a year now that I didn't have before. And a lot of things can happen in a year. The king might die. The horse might die. I might die.

 
"And, who knows? Maybe the horse will sing."

and just maybe I can convince them to become really Agile?

Mike

Get control of failing projects - be Agile

I've specialised in a particular area of project management called "Turnaround".  Where other project managers specialise in different aspects of project delivery I specialise in clearing up the mess that some of them leave behind.  If project management was a hospital I'm more the Paramedic or A&E specialist than the long term cardiologist or pediatrician.  You don't ask me to manage your long term care - just breath life back into the patient.

When my kids needed to know what I actually did when I left home for the day I found it a bit difficult to explain what a project manager actually does.  I tried lots of things but finally hit on the explanation that "Daddy's job is to stop the s**t hitting the fan - but when it does he has to clear it up afterwards".  As the years have passed I've realised that I've built my reputation up on the latter.

I'm often asked "... so how do you turn projects around?" normally followed by "... so what extra controls do you put in place to get it back on track?" or "...I bet you have to be tough with people?"

I've thought about it a lot this week, not least because I'm helping a new client deal with a failing critical project, and I've come to the following conclusions from my experience:

• Projects don't fail because of a lack of controls in fact the truth is the opposite.  There are so many controls in place that everyone is wasting time managing the control system and forgetting to actually do something
• Projects don't fail because stakeholders aren't managed properly. Most people in my experience go to work to do a good job not destroy things.  The problem is that we spend so much time "managing" stakeholders & teams that we forget that they need time to actually get on with what they're good at
• Projects don't fail because people don't know what they want.  They struggle because people just don't take the time to think about the best ways to communicate something and make sure that everyone has the same ideas.  No - we'd much rather have controls and detailed documentation that we read, review and comment on.  Wouldn't it be so much better if we simply chatted, agreed the best solution and then got on with it?  So much more effective & efficient
• Projects don't fail because we don't have enough resources, money or time.  They fail because we allow expectations to get away from us or become so intransigent that we oppose change even if the new solution would make what we do more useful and relevant
• Projects don't fail because we don't follow a "proper" process, don't have "proper governance", don't have "rapid action teams" or don't have "change control".  They fail because all of these things, if improperly applied, strangle the innovation out of the best of teams

My daughters still think its amusing for me to think that I'm now fashionable and cutting edge.  But me and my "project busting" compatriots who believe that projects are just containers for actually "doing stuff" are becoming the majority.

For me projects have two type of influences - Gains & Strains.  The higher the Gain to Strain ratio the more likely you are to keep it on track.  So when I'm faced with a failing project I aim to reduce the strains as quickly as possible. 

Typically this includes:

• Reducing command & control mechnisms to the absolute minimum
• Changing from "Project Review" meetings to more informal get togethers once a day to synchonise activity
• Stopping the "management" activity and emphasising the "leader/support" role
• Distracting company control freaks with "plans" and lots of activities that I need them to go away and deal with (that won't impact on the team or the project in any way)
• Taking on the role of dealing with the blockers rather than allocating the tasks

So I guess that means

People over process, Deliver over Control Documentation, Cooperation over Contracts and Change over Detailed Plans

Haven't I heard that before somewhere?

So it looks like my "secret" is that I make projects more agile.  I liked that in the past I was a maverick and did projects differently to everyone else.  Now agile's becoming mainstream does that mean I'm going to have to become a Waterfall evangelist now just to be different.  Now that's a scary thought!

Mike :-)

Lean Contracts & Trust - Are they really compatible?

I was asked an interesting question this morning - "Agile just doesn't work our work with fixed price contracts - so what should we do?"  I guess I understand the problem - when you're designing & delivering using an iterative approach it's pretty difficult to tie down what's the contract is all about.  If you can't do that then it's even more impossible to apply penalty clauses to incentivise suppliers.

The more I thought about it the more other questions came to mind.  Do fixed price contracts really work in any project environment?, Can we really define exactly what's got to be delivered in sufficient detail to deliver a truely accurate cost?, Do penalty clauses really deliver? and What do we have fixed price contracts anyway?  Now I've worked on a wide range of projects including so those with so called "Hard Deliverables" and, without exception, I can say that fixed price contracts never delivered what we expected - but that's in their nature.

There are two ways to look at contracts and it depends on what you believe.

Conventional view - Companies look out for their own interests and Contracts are needed to limit opportunism

Lean view - Assume other parties act in good faith, good relationships limit opportunism and contracts should encourage through incentives

So if we take the lean approach there are some key questions that will be worrying managers: Who takes the risk?  What's the price of trust?, How does our approach change? What does a Lean contract really look like? and Can it really work?

Now I don't profess to be a procurement expert but I do know that lean contracts are very effective in all environments - especially in software development and business transformation.  I've negotiated partnership agreements with suppliers based on Time & Materials with incentives and they've been extremely profitable for both parties.

Luckily for us though, Mary Poppendeck really explains the subject very well in her presentation Agile Contracts - What is trust? She tackles the difficult concepts for lean contracts precisely with good case studies and excellent practical conclusions so I'd really recommend a read.

I'll come back to this subject in the coming weeks.  I believe that extending Agility to partnerships & suppliers is the next barrier for Agile to overcome.  Pulling together the wider end to end team (partners, customers and suppliers) reminds me of the "Just in Time" projects I covered early in my manufacturing career and the key foundation of that was Kanban management....  Trust & partnership were the foundation of those phiolosopies as well and they've coped well over the years.

Maybe I can see a link here - Just in time->Kanban->Agile.  That's what I'm going to talk about soon in this blog.  There might just be a coming together of lean manufacturing & lean projects or BAU & Projects.  That sounds an exciting development.

Agile - it's not complex enough!

I've just finished Prey an excellent book by the late Michael Crichton.  It's a very scary book that follows the development of nanobots that evolve and form autonomous swarms. Although they have no individual intelliegence they demonstrate emergent behaviour in the same way that birds flock or termites build complex homes.  The moral of the book is clear - self organisation can be very effective - and of course dangerous.  It's also easy to see how the fictional story could become a reality - but that of course was Crichton's skill.

It got me thinking, what is this "self-organisation" thing anyway? Do self organising teams really self organise or are they really guided?  Apparently I'm not the only one who's throught of this.  A great presentation by Jurgen Appelo - What (else) can Agile learn from complexity looks at Complexity Theory and Agile.  Now before you click on that "back" button it really is worth a look. 

He looks at the key factors of complexity theory and applies them to Agile and there are some great quotes:

Darkness Principle

Each element of a system is ignorent of the behaviour of the system as a whole... if each element "knew" what was happening to the system as a whole all of the complexity would have to present in that element

This is one of the major issues that traditional management methods fails to recognise.  We believe that the more we know the better we can control something.  However, the reality is that it takes too much time and resource to try and control everything because the control system always needs to be more complex than the project we're trying to control.

Boundaries & Conditions

Self organisation requires that the system is surrounded by a containing boundary.  This boundary defines the "self" that will be developed during the self organising process"

Which implies that all Agile activities must have some form of wrapper.  The concept of a project is well know and tested as a container for self-organisation so why create a new concept.  Agile & Waterfall can co-exist and work together - in fact they're symbiotic.

Fitness Landscapes

The environment is not out there separate from us.  We can help to create the environment... The Spanish have a phrase 'My friend, these is no road - you make the road as you walk'

If ever there was an argument for emergent design in IS projects then this is it.  Emergent behaviour is apparent all around us.  No one "organises" the bread supply for London it just happens.  Our brains are a classic example of how independent elements can combine and a "self" can emerge from the chaos.  However, as we know it takes time for intelligence to evolve and most organisations simply don't have the patience or belief to wait!

Incompressibility

There is no accurate representation of the system which is simpler than the system itself.  In building representations of open systems we are forced to leave things out, and since the effects of these omissions are nonlinear, we cannot preduct their magnitude

Which means - we can't predict the future so why waste so much time trying to plan & deal with things that haven't, and probably won't, happen?


There's a lot more in Jurgen's presentation and I'd really recommend that you read it through.  I'd also recommend Michael Chichton's book because it's just a rally good story (and a lot more believable than Jurrasic Park!).


So does Agile need more complexity?  Absolutely - because it's only when we understand complexity that we can keep agile simple for the rest of us :-)


Happy Friday


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. 

It ain't our culture...

I had a long conservation yesterday about interviewing and interviewees that made me stop and think.  We'd just interviewed an excellent candidate who ticked all the recruitment boxes - great CV, demonstrable successes, clear references and a very credible candidate with gravitas.  However, they turned him down because "he great - the best we've seen - but he won't fit with our 'company culture'"  I was also told that "the problem with this Agile approach is that it delivers things too quickly - can't you slow the team down a bit?"

Now part of that I'm sure was due to a blinkered HR approach that seems to be centred around "harmony" and employing "corporate clones" to develop some mythical perfect culture.  But, "harmony" doesn't mean "balanced" - if an organisation isn't delivering what it should it seems to me that they should be looking for something or someone different to make things happen.  A good team has a balance of people with diverse views & attitudes.  Conflict, managed properly, delivers innovation, competition and fun.  Employing the sort of people that "won't upset the people who are already here" seems very short-sighted.  In fact, it can only lead to stagnation and blandness.

Agile depends on creative conflict to deliver effectively, but then does proper corporate management.  Is the drive for "consistency" leading to the death of Agile?  

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 Certification - something's missing isn't it?

More and more companies are looking for certification or accreditation in Agile or SCRUM methods.  As Agile becomes more mainstream there is a need to distiguish between one CV and another.  One way of favouring candidates is to look for those that have been vouchered for by some certification body such as the Scrum Alliance and the famous Certified SCRUM Master or Product Owner "qualifications"

Now Agile is a very practical skill that demands a great understanding of how to influence & manage the expectations of the SCRUM team and the various stakeholders that surround development.  Far more, I'd argue, than Traditional Project Management.  However, looking at the marketplace at the moment it seems that every Agile training course is concentrating on understanding & managing the process of SCRUM not the people that are involved.

That leaves me with a concern.  I thought that the Agile Manifesto made it clear that we should favour "Individuals & Interactions" over "Processes & Tools" but from my perspective that exactly the oppostite to the approach that the mainstream certifications seem to be taken that tell me about the process and sweep over the people skills.  That's a mistake that Project Management bodies made in the 80's & 90's and it's only in the last 10 years that they've started to realise that knowledge is only part of the equation and that capability must be demonstrated.

SCRUM lends itself to a skills or vocational based certification approach.  Potential SCRUM Masters need to demonstrate that they not only understand the process (and let's be honest that really doesn't take two days of training) but can apply it in the real world.  To quote the Agile Alliance position "employers should have confidence only in certifications that are skill-based and difficult to achieve" Which is exactly where current qualifications fall down.  They only give employers confidence that a person has been exposed to a specific set of knowledge not that they can then apply that in the workplace.

The APM in the UK seem to be taking a stronger line along with the PMI.  Although I still struggle with the concept of Agile Project Management I respect both of these organisations in the way that they carry out and maintain the credibility of their qualifications.  They also offer "Practitioner" and "Expert" levels to their offerings that require demonstration of skills - that's a move I fully support.

However, I'd still like one of the main UK bodies take on the vocation approach - perhaps an NVQ in Agile & SCRUM for SCRUM Masters and Product Owners?

I'm looking at certitication & accreditation in the UK right now and any support would be welcome to help me bring it to fruition.  Leave me comments

Mike