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