How to achieve agility (1)

This is a big topic.  Be prepared for installments.  Also sweeping generalisations about large organisations, for which there are a number (small) of very good counter-examples.

Webster’s describes someone who is agile as being: “marked by ready ability to move with quick easy grace; having a quick resourceful and adaptable character”.

The Agile Manifesto offers these priorities for Agile software development:

Individuals and Interactions over processes and tools
Working Software over comprehensive documentation
Customer Collaboration over contract negotiation
Responding to Change over following a plan

And Dilbert describes it this way:

That means no more planning and no more documentation.  Just start writing code and complaining.”  and
Agile programming doesn’t just mean doing more work with fewer people.

Webster’s defintion would be a good place to start; the Agile Manifesto offers some very applicable wisdom, and is underpinned by some quality thinking on good principles.  Guess which one of the three definitions is the one you’ll come across most often?

“Doing more work with fewer people, no planning, no documentation” (and often: no requirements, no engagement from the business, but still the expectation that the documentation turns up and you can tell 6 months ahead what you’ll deliver then…)

To understand the reason why this happens, we have to consider what most corporate psyches value.  The vast majority of large organisations you will work for (whether as a permanent worker or a consultant/freelance) are listed on some kind of stock market, and it is important to understand how this influences corporate culture and psychology.  Stock markets value one thing more than its true value, and to the exclusion of valuing at times the more obvious things.  I am not talking of profit.  I am not talking of long-term shareholder value.  I am talking of predictability.

When working in a number of large organisations it has become clear to me that the ability to disrupt expectations – even by delivering value early, or cheaply – is not valued in relation to its contribution to the short or long term value of the business; large organisations complain that they are unable to be truly innovative (which by observation I would say is often true), and instead spend large sums of money investing in, and purchasing, solutions from the truly innovative, smaller organisations; or outright buying those smaller organisations.  Large organisations often have organisational units devoted to innovation (which in itself tells us a lot about the culture they have vis-a-vis innovation), and talk a good talk about disrupting the market; but fail to recognise that it is their own culture which is stifling innovation, and it is apart from anything else this drive for predictability which has its hands firmly clutched around the throat of anything new.

Explicity: I believe a predictable failure is often more palatable than an unexpected success.

To realise the full value of the kind of change which Agile working can bring, there are an army of obstacles which need to be overcome.  The predictability culture is one, and it casts a shadow downwards from the CEO or the CFO across the whole organisation, until it reaches a level where the conscious understanding of the need for it has evaporated, and has been replaced by a cultural, reactive, instinctive mistrust of the unpredictable.  This inflexibility is characterised by the lack of responsiveness to opportunities, as well as the squashing of innovation.  It is most frustrating when exhibited without explanation or conscious knowledge by the low-end of senior management.

So when large organisations talk about becoming more agile, they aren’t always saying what they mean.  They don’t truly believe they can or should become capable of turning around new product development within a shorter period than ever before, truly responsive to the market place, and bringing unexpected new value to their bottom line.  They mean instead an incremental adjustment to average project life cycle with attendant cost benefits.  They mean the same old thing, but a bit slicker.  They mean the Dilbert definition.

The good news for those organisations is that it is almost certainly possible for them to do more with less, and without the difficulties that adopting a truly Agile approach across the whole organisation would bring.  The bad news for them is that sooner or later, another, more disruptive and innovative organisation is going to eat their lunch.  (And to be clear, I don’t think the adoption of Agile development or Agile delivery replacing waterfall project delivery is the key reason why.  It is instead the very wise saying: “Culture eats strategy for breakfast”, attributed to Peter Drucker and Mark Fields variously, hits the nail on the head.)

 

JFDI, or the illusion of fast delivery

Every now and then a change is issued as a JFDI.  Blanket exemption from everything, throw resources at it, just get it done.  (If you don’t know what JFDI stands for, ask someone old enough to vote).

In an organisation which has a good level of control over its change, JFDI is the exception.  In a badly run change organisation, JFDI is the norm.  In an organisation which is too rigid, nothing is ever done by JFDI.

Did I just say that no JFDI is a bad sign?  I did, and it can be. For two reasons.  First the less contentious JFDI learnings.

Organisations need to be cautious about doing change via JFDI routes because JFDI destroys value before it delivers anything.

As soon as you do something by a JFDI route, stampeding through process gates and ignoring boundaries of responsibility, you show that the organisation can ignore all those safeguards you’ve been putting in place with the assurance, training, communications, and best practice processes.  That’s a bad precedent to establish.

JFDI tramples on other people’s work.  If you aren’t on the JFDI train, don’t get in its way.  This discourages people from working on anything else, destroys teams already in place (by robbing resources), weakening committment, morale, and initiative, and harming the long-term retention of those thrown under said train.

JFDI ignores strategic considerations – in a software change organisation, it often ignores architecture and design patterns, testing best-practice and planning, stop-to-think time – whether it’s a good idea to continue or not; in a manufacturing organisation (where it’s very rare indeed) JFDI represents shipping a prototype without testing.  In some organisations it’s simply unthinkable.

The aftermath of a JFDI delivery can be wide and long.

Wide: across the organisation which has been afflicted, many projects will have been disrupted.  The cultural impact can also extend beyond the boundaries of those obviously involved – not just the team who delivered the JFDI change, nor even only those who were the recipients of the change, but also the supporting teams – the Finance team, the HR team, the trainers; the PMO or assurance teams; often the testers; IT support (both internal and for external customers).  The negative impact on individuals can, and often does, lead to staff turnover or at least burnout.

Long: change debt.  That whole class of things which are the consequence of having done things the fast way, rather than the right way – technical debt, architectural debt, training debt or process debt, organisational debt.  Technical debt and architectural debt often take years to recover from, and sometimes last the lifetime of the platform which has incurred them – with a knock on effect on many or all changes to that platform.  Training debt results in people being ill-equipped to support the change which has been rushed through, and that in turn demotivates people who are good, provides excuses for failure to all, and reduces the positive impact of whatever change was rushed through.  Process debt is like training debt, but represents the impact of not having designed the right processes in the first place, and no amount of training can fix this if the process people are learning is a bad process.  Organisational debt is a surprisingly common problem which goes unnoticed: when the organisational design has not been updated to allow for the changes which have been brought about, there are gaps in accountabilities and responsibilities – or these have been aligned to a group which doesn’t have a good, organic reason to care about the thing they’ve been given to look at.  I’ve seen an organisation which had absolutely no one accountable for shipping the product to the customer (it was a digital product, but there was still no one, and no organisational unit, which was held accountable for the customer getting the product – the IT department had taken care of it).  Changes cause creeping drift, and every now and then it’s important to realign design and reality (one way or another) and see there aren’t any gaps.

So JFDI comes at a price.

Sometimes organisations make the choice to sacrifice some of the good things that fall by the wayside during a JFDI delivery to achieve something of great value – a takeover (in either direction); hitting a particular deadline for a tremendous opportunity, or to avoid a hideous regulatory hurdle; the sort of disaster or emergency which, for instance, 9/11 represented, and what some organisations did in the aftermath of that.  If they do it conscious of the consequences, and with a recognition of the mess they’ll have to clear up afterwards, they can not only plan for that, but genuinely reduce the impact of these bad things – especially the ones which impact people.  Morale, commitment, initiative, the culture – these all rebound if they recognise that this JFDI thing is an exception, a response to something that happens only rarely, and not the normal way of doing things.

If organisations do JFDI delivery too often, the debts mount up calamitously, much like the stables of Augeas, and it is a labour of Herakles to clear it up.

But…

If there’s no ability to overturn the fences from time to time; if there’s never a situation where you throw caution to the wind and just go for it in a JFDI manner, the organisation you’re looking at may well be suffering from being too hidebound and too cautious.  That doesn’t bode well for the future, and for fending off competitors.  I know there are business domain exceptions – I do not want to be the first to fly on an airliner that’s never been tested, or even which runs software which was produced JFDI; other than in these business domains, the total lack of JFDI can even indicate that the organisation has reached the kind of steady state without change which is the last rattle of a business dying, peacefully, in its sleep.  While a business can rarely recover from this sleep of death, it is typically only with an injection of a very different senior leadership team, and that often comes at this point by aquisition.

And a total absence of JFDI can mean that the organisation has given into the illusion that it controls its market entirely, and can predict everything; and that is also dangerous.  It means that sticking to the plan is more important than pursuing an unexpected turn, which is an environment in which very little (if any) innovation can flourish.  It can happen to organisations at the very peak of their arrogance, and topples large and healthy organisations from their commanding position.

 

Flushing the Matrix

Finishing off the exploitation of this particular line of thought – and the film reference that goes with it (sorry) with some of the slurry at the end.

Bad things come to those who wait.

The worst challenges of Matrix Management are logical progressions of the concept, and probably inadvertent, but they are common enough to be something to watch out for.

Salami!

In the kind of change Wolf Bear are involved with, the primary activity of most of the individual contributors on a given project or programme is one requiring focus, attention, and thought.  It might be cabling a server rack well, or it might be writing code, or identifying what felt wrong about a particular functional test, or making a good consistent set of icons for navigation around an app, or a dozen other things that require attention.

Matrix management is sometimes used to slice people’s time too thinly to properly concentrate on what they are delivering.

The focus required can take quite a lot of time to muster, to reach full effect. This is often referred to as “getting in the zone”.  For a lot of coders (for example) it’s a necessity to have a long run up at solving particularly challenging problems, and that doesn’t make them a bad coder – often quite the opposite.  Understanding and getting into the context of a particular project or activity isn’t something that just happens, at least for most people.  Context shifting comes at an intellectual, energetic, and motivational cost, and it harms the concentration and reduces output.

With matrix management, some organisations think they can spread people out ever more thinly, and receive the same results.  A cariacature of a project manager often repeated is: “A project manager is someone who thinks that if producing a baby takes a woman nine months, putting 8 extra women on the job should produce the baby in a single month.”  Many organisations behave as if they believe that they can equally split a person across 4, 6, or even (the worst I’ve seen) 16 different projects and still receive the same attention, quality, and output.

I notice that in every large organisation I’ve seen adopt this kind of approach they have been careful to avoid doing it to flagship projects (programmes, etc.).  Any time you see a behaviour consciously avoided for flagship projects, you know that the organisation knows it harms delivery, and they choose that compromise for the less important things either because it’s how it’s always done (intellectual apathy), or because it’s a compromise they are willing to make.

The results at the negative end of the spectrum include some that are pretty obvious – slower completion, lower quality, increased rework – but they also include some less obvious results: the consequences of forcing people to work in a way which they know they are less good at destroys motivation, lines them up for the kind of performance review which drives them to leave (and sometimes leave permanent employment entirely), and even if their performance review doesn’t suffer, the constant drudgery of producing something less good than what you know you could if you were just given the chance is debilitating.  This is the illusion of efficiency – it feels cheaper to split people across projects – over effectiveness.  It is often better to focus on doing a few things well and quickly than doing many things at the same time, but taking longer to finish anything.  There are scholarly articles in the canon of psychology exploding the myth of multitasking on an individual level, but organisations as well only have so much focus too – but that’s for another article.  True efficiency is a result of comparing the total inputs with the total outputs, but the perception of efficiency is not always as well thought out.

In short: careful with focus; it is fragile, and if it’s too dilute, it harms progress dramatically.

Matrix Dumps

There’s a consequence from matrix management on the (leadership of the) team from whom the matrix resource is drawn.  Very few people become leaders of teams because they are thrilled by utilisation spreadsheets.  (I would like to think it is none, but a variation on Rule 34 probably applies).  If you take their team away on a regular basis and largely divorce them from what the team are doing, what do you expect their response will be?

The team leader might stay.  All organisations have a degree of turnover in staff, but the fastest to leave are seldom the ones you want to leave.  A team leader who knows he has little to do with the way his team work may not take the care and attention a motivated one would in recruitment of replacements.  This snowballs rapidly: if people work in a team where they know the manager no longer cares, they also lose their interest.  That fuels a drop in engagement, which in turn often increases staff turnover, and the problem accelerates.

As a change leader, this can rob you of the tools you need to deliver change – effective, engaged contributors.  The short term solution is to bypass the more irritating consequences of matrix management and, especially on large, demanding changes, adopt resources wholesale.  Longer term, the changes needed to resolve this issue are more pervasive, and harder to achieve.

 

This is the disconnect is what lies at the heart of my problem with matrix management: the disconnect between the host organisation and the change vehicle. It is the underlying cause of most of the problems I’ve laid out here, and it is hard to resolve systemically.  Recognising the organisation’s true priorities and focusing on those is an organisational approach with a lot of merit; but it’s hard to get the different competing areas within a big organisation to be patient while other areas get their changes carried out.

This is mostly a problem with waterfall organisations.  Agile’s resourcing is for another time.

 

Deeper into the Matrix

light green characters on a black background

Continuing on the theme of Matrix Management … and hoping this sequel doesn’t suffer the same fate.

Developing the Matrix

When your organisation is working hard, and trying to get the most change done there’s a common casualty: Personal development.  Some line managers try to align their resources to the projects which will provide them inherent opportunities to develop, but a lot seem to either lack the time, or are not permitted the chance to flex resources to reflect their hopes, aspirations, and interests.

This isn’t a responsibility you’ll find in any project brief, but remembering that the intent of all projects is either to build, or to protect, the value in the business, and recognising that the combination of motivating and directing your team is not always easy in a matrix environment, it is in your interests and the project/programme’s interest to get involved.  Approach the team members you’ve been assigned and who you can get around to (that’s not going to be everyone in a 200+ person, 2 year, 3 continent programme), but as a minimum those you directly manage within the change organisation, and find out what they want to learn next.  See if you can angle a way for that to be baked into their role on your project.  If they want cross-training into another skill, see if you can facilitate an introduction to someone within the project who can help them out.  This isn’t your main activity; this isn’t the purpose of the project or their engagement with it – but it’s a way of giving them something which in many cases they aren’t getting any other way, and it pays you back greatly.

Considering the time they spend working on your project, you’ll be seeing more of them than their line manager does.  Invest time in them and how you can help them, and you’ll find a team who do give a lot more of their best for you.

Matrix: Because I choose to

Which brings me to the question of motivation.  Matrix management doesn’t inherently provide good motivation to the members of your team to do their best, or even their second-best, for you.  With the combination of the remote performance punishment reward cycle (often annual; as discussed above usually by a line manager who knows very little about the project contribution); the lack of personal investment in the outcome of most changes for the individuals in this environment; and particularly if there’s the salami-slicing of splitting people across multiple things at once (more of that anon), the motivation of those who work under a matrix manager can be very thin.

If you need the best out of the people on your change, and that’s the case if it’s demanding for them or you as a change leader, you need to motivate them.  When they are working for your change all day, every day, if you’re not taking care of their motivation, ask yourself: who is?  Self starters are great, but not everyone is one, and if your team is going to produce something excellent, you need the best out of a lot of them, not just a few.

For a large proportion of their working day, those individual project contributors, or for larger projects or programmes, even those managers, are going to be your vehicle for carrying out your job, so spend some of your focus on them.  One of the best ways is to engineer opportunities for some personal development for them. Another, simple one, is feedback – again, already discussed.  Offering them some flexibility that they don’t otherwise have – like a later start in the morning, provided that doesn’t harm the needs of the team and the delivery – it’s often surprising what will make a difference.  Remembering always that for a lot of people: motivation isn’t money.

If they are getting all they need from their existing management, you’re not trying to take over, so leave well enough alone.  If they are the kind of self starter who doesn’t need any help like that, again, leave them in peace.  For the others, remember that while they are working on your change, they are your team.

 

 

The Matrix? Do you want to know what it is?

light green characters on a black background

Another movie quote, from The Matrix (1999).

Matrix management is a common affliction.  It is adopted as a way of managing multiple people across an organisation into different temporary organisations (i.e. projects or programmes) without formally transferring them out of their original organisations.  That’s the simple version.  The more intricate version, often adopted in larger organisations in the hope it creates efficiencies (cost savings), is where people are not only loaned out to projects/programmes, but to multiple such temporary organisations at one time.

I’ve given away my position on this in the first line of the previous paragraph.  It’s not that the idea is utterly terrible – in fact it can be done well, and have some really surprisingly good results – but the execution is usually so dreadful that I use the term “affliction” deliberately.  Let’s look at some of the worst sins.

Matrix Performance Desserts

Within the world of work we all get managed towards better performance, at least in theory.  The fact that some contractors (freelancers for those across the sea) cite annual appraisals as the strongest motivator for going that route – rather than the increased financial rewards – speaks volumes about how well that entire process is handled in many organisations.  Nevertheless, in theory we receive coaching on how to improve our performance from our line manager, who has pastoral care responsibilities for us; and in theory in many organisations they are also supposed to support our career development.

So what if all the work we do as individuals, or the vast majority of it, is done for projects via matrix management?

Time and time again line managers are divorced from the quality of their staff’s work.  Matrices are a very good place for poor performers to hide.  It makes me question the point of having any line management in the traditional sense when people within that line are spending all their productive time working in projects away from the perception of the person.

I didn’t say simply “how bad their staff’s work is”.  The lack of visibility cuts both ways. It’s demoralising to work hard for a project/programme, make a real contribution, and then discover that in your end of year review your performance has been marked as mediocre.

Some organisations have the good sense to put in place a means of recognising and rewarding good performance in a more tactical way.  I have yet to encounter an organisation which has a good way of giving just desserts to non-performers in a similar manner – if there’s anybody out there with suggestions, please pass them on!  Neither of these two are a substitute for the performance review goodies – in typical organisations your individual, performance related pay does not necessarily reflect tactical rewards at all, and permanent pay rises are more a question of the line manager’s perception than the value delivered to the company.

I have an odd habit.  I like to collect ways of saying thank you (in different languages for instance).  Last time I counted, I got to around 50 different languages I could communicate thank you in, including some very peculiar ones.  This – albeit not in different languages – is a habit I strongly commend to anyone who has to deal with Matrix Management as part of their role.  Certainly not every week for every contributor, and there will be times when it’s a lot less often, or only a subset, but cultivate a habit of feeding back about good performance to both the contributor and their line manager as a regular part of what you do as a matrix manager.

When it comes to poor performance, the same principle applies.  You don’t have to write a foul-mouthed rant about someone’s unlikely parentage and personal habits, but you should feedback, again to both the contributor and their line manager, if you can see development areas that the person needs to focus on improving.

A bit of coaching to the contributor is useful here too: encourage them to set aside that feedback, from any such matrix engagements, and use it with their line manager during the review process if such a thing happens.  (And since you’re going to be constructive if you’re giving “please improve” feedback – always – you can encourage them to consider for themselves how they can act on that feedback.).

This approach could be shocking for the line manager, so it’s worth letting them know that you will be doing this.  Make sure that they understand that if you’re going to them for an escalation, or for them to take action, you will explicitly say so to them in your communication.  Otherwise every time you do this you may be getting more and more demoralised resources.

I will be jacking back into the Matrix again soon…

A beginning is a very delicate time

“A beginning is the time for taking the most delicate care…” – Frank Herbert, Dune.

The title of this is taken from the 1984 film version of a book I enjoy tremendously, and both quotes are good observations, particularly reflecting the natural world.  New born creatures are delicate, and vulnerable.

With changes, you could be forgiven for thinking the same is true.  Certainly the behaviour around them in many large organisations would lead you to believe that.  The start of projects is often the time when bad news and negative thoughts are hidden, or manipulated.  Risks, downsides, recognised areas of doubt or uncertainty: these are not shared with the decision makers who decide which projects get to continue, and which need to wait.  People treat new projects, programmes, workstreams, unbuilt products as if they were newborn babies, gently, quietly, and with care.

The result is that far more projects (etc.) get attempted than should be; and both the inputs and outcomes of those projects are sometimes very different from what was expected.

The beginning of an endeavour like a project is not a time to be delicate.  It is a time to blow the bloody doors off.  It is a time to thrash around with the idea and see whether it really will hold water.  It’s a time to examine, to question, to try different ideas.  In a healthy, mature change organisation, a lot of changes will stumble at this hurdle.  Some will fall entirely, others will take time to be rethought and approached differently.  Some are already just right, and will go ahead with a confident step knowing that they have already been through a testing time and stood their ground.

Aside from the well known adages about the proportion of effort spent in design versus build, there are other important effects of getting things a bit more right early on, and its opposite.  Right: better-set expectations, the right support early on, well identified stakeholders and supporters.  Wrong: constant political firefighting, distracting detractors, the wrong stakeholders (see earlier comments about Decision Weakness).  Right: A good proportion of the right people in the team to start with.  Wrong: Hammers, where you needed screwdrivers.  Right: time to fight the battles that really need fighting.  Wrong: doing things you know are wrong for the business because a deadline is approaching but you can’t take the time to fix it.

This speaks to the culture of an organisation in general.  If there is a good culture of openness and transparency, the decision makers will know whether ideas are being presented to them having been through a challenging filter, and be better able to trust them; they will also know that a rejection now is not a rejection automatically forever.  If there is a culture of spin and misdirection, projects (and sometimes even programmes) will be started with the gatekeepers having one idea of what will be the outcome, when, and how, and the people in the change vehicle being launched either having a different idea or no idea at all.  “No idea at all” is absolutely fine when the people signing the cheque know that they are backing something entirely exploratory.  Indeed they should be reserving a portion of their change budget (organisation-wide) for just that sort of investment because that’s where the unexpectedly good returns and innovation come from.  It is never fine, however, when they have been sold a different expectation, and it will cause trouble for everyone involved, often particularly those least to blame for it.

One real world example I can think of involves a programme which was started with a very open idea within the culture of that programme – a “let’s see what we can achieve” kind of idea; however the parent organisation was under a much more concrete impression.  If there was a tacit agreement that it would be presented as concrete but continue as blue sky, that tacit agreement fell by the wayside when there was a change of executive management.  Suddenly the open money pit became far less open.  Expectations morphed into demands.  Before very long after the executive change, in my judgement after a generous period of time nonetheless, this programme was stopped.

In the process, the careers of the individual contributors at that institution were blighted.  They had spent a year, or several, working in a culture which was at odds with the parent company culture, acquiring a way of working alien to the parent company.  Their old positions were filled, permanently.  They were looked at, on returning, with a bit of suspicion.  By the end they had been directly disadvantaged financially – as they were deprived of performance bonuses because their programme had (abjectly) failed to achieve the targets it had been set.  If they were completely honest on their CVs when they left that organisation – many did, shortly after – they couldn’t point to the thing they’d worked really hard on being any kind of success, so perhaps even their post-company careers were blighted also.  I can think of dozens of people caught in this particular situation who had nothing to do with the failure of this particular programme.  Most of those I could see being to blame seem to be doing very well for themselves now, although I do know they too had to endure some tough days when things were evidently going badly while the programme was still being run.

Imagine instead a known, arm’s length more risk-oriented investment vehicle, created to attack innovation directly, with a properly understood acceptance of failure, and a deliberate attempt to bring things to a head appropriately quickly… no tarnishing of careers, no great surprise when it isn’t a raging success for any particular line of development, and everyone knows what they are getting into at the start.  (Incidentally, that’s what that company have now set up).

So, in summary: at the beginning, don’t handle the idea with kid gloves, beat the snot out of it.  If it’s still risky, make that really clear to the decision makers.  Changes are best beaten up early, if they are to avoid being beaten up often.

 

 

Expansion is non-linear

One of the first thoughts when you have a change where you have more money than you can currently spend, but less time than you currently need, is often to expand the team.

This can be a big mistake.

If the current team aren’t performing as well as they ought to be, adding more people will seldom fix the problem.  Quite a lot of reasons for poor performance by a team of contributors will only be worsened by additional people.  I’m most familiar with technology-enabled changes, so let’s take a few examples from that space.

If you’re having trouble getting the build to be stable, adding more developers – and letting them code new code – will not make the build more stable.  You’ll get more new code through, perhaps, with a proportion of mistakes – Erasse humanum est (Seneca?).  If you aren’t using automated testing (why not?), adding additional testers will increase the complexity of coordination between them, eat up time while they become familiar with the product and test scripts, and differing judgements may well alter the things identified as bugs (often: upwards).  More architects do not result in a quicker architecture (quite the reverse).  More designers do not result in faster design results.  More creatives … well actually, sometimes more creatives really does improve things – and I’ll come back to that in a bit.  If your team just isn’t performing with the velocity you expect (whether on Agile or waterfall or some other variation), adding extra people isn’t going to fix anything by itself.

You have to understand the problem you are solving by bringing in extra people.  If those people can start work without interrupting those who are already working, be productive entirely independently of the existing people, and deliver product to at least the same quality, extra people can help.  So many things we do in technology changes – and in many other spaces – are strongly interdependent, however, that many hands do NOT make light work, and it is rather a case of too many cooks spoil the broth.

Sometimes, the problem of speed is better solved by taking people away.

Now I know there are times when the person everyone wants to take away is the change leader – project manager, programme manager, scrummaster, whatever.  If they are serving the team/project/programme/organisation well, they aren’t harassing for pointless updates.  Sometimes, the only thing has been to go and get the coffees, teas, doughnuts or whatever, and if that’s all I can do: good enough.  Sometimes the thing I do which helps the team to get things done is intercept all the people who are trying to find out when the widget will be finished, and lead them away.  That’s definitely a valuable service.

Sometimes, though, it’s not as nice a job as that; because sometimes the right thing to do to allow the team to speed up is to remove someone from the team.

I’ve liked a lot of people I’ve worked with; and not all of them have been good at their job.  One of the difficult tasks in Change Leadership is spotting when someone is having a negative impact on the Change you need to bring about, and removing them from the position where they are able to cause a problem.

I had a pair of programmers pair-programming in a series of sprints.  One of the programmers was a rock star – not a prima donna – but extremely quick, very accurate, very effective.  (He’s also my go-to example for why asking for a number of years of experience is a bad metric of quality – after 9 months of Java programming he was without doubt the finest Java programmer I’ve ever come across.  He still is, years later).  The programmer he was paired with had, nominally, more experience.  He was also Mr Slow.  He was not stupid, and I don’t think he was lazy; but he had no drive for programming, and his attention wandered constantly.  Adding an extra pair of programmers would have meant slowing down while they got up to speed, and wouldn’t have solved the real problem.

The urgent problem wasn’t even the velocity of the project.  I could handle the customers well enough that we were fine with that, as it happened.  The real problem was the velocity of the rock star programmer.  It was painful to watch him have to shift mental gears to try to keep coaching the other programming, bringing him on board, helping him understand what had been coded, and then letting him have a contribution.  It was even MORE painful to watch the frustration and itchy fingers when Mr Slow ‘drove’ the keyboard.  I needed to resolve this problem so that I didn’t lose an outstanding programmer for the sake of being merciful to a far less exciting one.  Or to prevent a murder.

If you’re kind, you can often find something for the person who isn’t working out to do which is more to their skillset and preferences, and makes better use of them – which, after all, is good for them and good for the company.  He made a perfectly acceptable project manager in the end.

If you’re leading a change, and there’s money on the table to help you speed up, think hard about whether extra people will give you what you need, or whether there’s another underlying problem.  Remember that just because someone is offering you what they think will help you doesn’t mean you have to take it.

 

That old sinking feeling

Whenever you take over a change of any size, you spend some time getting to grips with what has gone before.

As an aside – the ability of an organisation to pass a project (programme, workstream, change) from one person to another and be confident that there will be a decent continuity of knowledge between the two people is a key marker of maturity in change leadership.

I like to start by getting to know some of the people on the change, because that’s after all the only way to get any change delivered: working with people.  You find out a lot, often things that aren’t related to the change itself or their ability to work.  But directly and immediately relevant: you also find out things which aren’t documented.  In my experience, always.  It doesn’t matter how good the handover has been, or (at least so far) how comprehensive the documentation, you’ll always turn up something extra by talking to people – well in fact, mostly by listening to them.

Listening is in every field a key leadership skill.

You can find out how people feel about working on a project (even if that’s not what they are talking about) by what things they think you ought to know.  You can find out a surprising amount about their ambitions and career development goals in some cases – information they just don’t share with their line managers for a variety of reasons.  And most likely you find out things about the change you didn’t already know, from the documentation, or from the handover.

In an Agile project you often get to find out things like which person estimates high in the planning you do (I personally like planning poker, but other methods work too).  You can find out little things that help you to motivate people – that Jane likes coffee, that Bob likes Early Grey Tea (and doesn’t like Star Trek), and that Sam can’t resist cakes or biscuits, but really wants to.  Most of all, you can find out how coherent a change team has become – how much they have gelled – by the way they talk about each other, and about the change.

Or, and this comes back to the title of this article, you can find out that the team don’t agree on what the goals of the change are.  You won’t find that documented in quite that way in most handovers – and a lack of transparency in the culture (we don’t want to hear bad news) is often at the root of that. With any kind of waterfall project, a vague, badly understood scope, is a sign of Bad Things.  It’ll surprise some people to hear that it’s as bad in Agile too, but exhibits itself in a different way.

In all organisations – if you know differently, please do let me know! – there’s a limit to the resources available to bring about any particular change.  In waterfall style projects that’s often set up front, before you really know the detail of what you’re going to deliver, and at an early stage you try to estimate how badly wrong you’re going to get it, and call it contingency.  In pragmatic Agile, it’s often the case that you get given enough money for a set number of sprints, and a relatively fixed business goal, and you do your best to achieve it.  (In platonic Agile, where the world is organised entirely around Agile, you don’t have to do this because you start earning real business value along the way and people are happy to fund you forever or what passes for it).  Sometimes the budget cut off expresses itself in a different way – a restriction on the number or size of teams, periodic reviews of value achieved – but in principle there’s a limit to the blank cheque, and you need to deliver within that limit.

In waterfall, everyone expects you to come back and ask for more money at some point.  (I know that it doesn’t always happen, but it’s common).  In Agile, and for good reasons, the dynamic is different: but even in Agile, if you don’t focus on what your business goals are, on what you are trying to solve as a problem, you will drift.  In neither case is it the responsibility of the people I talk to when I’m taking over a change to either fix or even identify the problem.  Some do, some don’t, I consider it a bonus when they do.  However, change leaders can diagnose that this problem exists when many people you talk to have an idea what the scope / goal is, but they are all different.  (If no one has any idea, the problem might be this, but it might also be a terrible communication culture, and that’s entirely too common too).

If you take over a change, and find this problem, you probably just found your top priority thing to fix.

Lessons Unlearned Again

Within the legion of people some organisations employ to help guide change to a safe conclusion, there are many people doing a difficult and often (sadly, literally) thankless job – the PMO.

Let’s leave aside for the moment discussions of whether Agile doesn’t need a PMO (or project managers) because that’s a different discussion for another time.  A lot of places still have them, and they deliver a lot of value.

It is extraordinary the range of skills you come across in a PMO organisation.  I’ve seen the full range from people who just help out a bit with the administration of projects, right up to people who, if they were to choose to do so, could without difficulty run an entire project and programme management practice, or be a very successful programme director, all called “PMO”.  Some people choose the PMO path because they think that they will help more that way; some choose it as a way into project management; some choose it as a way out.

A PMO within a programme has a lot of responsibility, but also a lot of influence and even power.  A good PMO can make a change leader’s life considerably easier; an influential one can make it much harder; and let’s consider too, there are some change leaders who need their life made a bit harder, because for example they are running their change (project or programme) ineptly, or even with malice aforethought.  As long as the PMO isn’t too entranced by, or unduly influenced by, the change leader, they can act as a brake on things going too far wrong.  That’s one of the good reasons for having a PMO reporting line as a practice which doesn’t run too close to the change leader reporting line.

At an enterprise level, if the PMO is divorced from the day to day realities of make change effective, something else happens. The tendency to focus inwards, on tools and processes and project management artefacts (seldom programme management artefacts I note), seems to increase over time.  One of the most important things for any PMO which includes process or methodology responsibilities (and setting up governance definitely has a large overlap into methodology) is feedback.  Ongoing and continuous, detailed, and evidence based feedback.  When you lose this, the Enterprise level PMO particularly runs the risk of proliferating practice but failing to understand either the impact on the changes, or the benefits (disbenefits…) of the processes they create.

When the number of mandatory deliverables just keeps going up, and the intricacy of the process persistently increases, it is time to refresh your EPMO with an influx of new blood.

 

Lessons unlearned

Many of the challenges of bringing about change in organisations are the same, but starting at a new organisation and encountering things again which I thought were old problems, long since solved, the last time I saw them reminds me that while there will always be someone ahead of you, there will also probably always be someone behind you.

When you start at a new place, and you are focused on delivering change, you start to look for the things which are going to cause you problems straight away.  In some places, it is resources – getting the budget, and the people, to realistically do what is required of you.  In other places, it’s that you are a captive organisation – an organisational unit belonging to another, far larger or more powerful organisation, and unless your priority becomes their priority, making change happen is extremely hard indeed.  In some places the enemy is the process.  In some, it is the lack of process.  Surprisingly often, a challenge will be something I think of as “Decision Weakness”.

Decision Weakness is a combination of a couple of factors.  The most obvious one for change leaders is: the inability of the (nominally) appropriately empowered leaders to make decisions.  This surfaces in a number of different ways, but a very common one is the desire to ship off the decision to a number of other “leaders”.  Trying to pin someone suffering from decision weakness down to making a decision without escalating it so far up the tree in a given organisation that you can never get that higher echelon’s time is frustrating and often fruitless.  This results in a waste of more senior people’s time and an astonishing proportion of the delay in getting changes delivered, or even more so in getting them stopped when their business case no longer holds water.

Decision Weakness also manifests in another way.  I’ve often referred to it as “insincere signoff.”  The person making the decision has a momentary rush of blood to the head, and actually agrees to something.  Be careful that you have this recorded in some unambiguous manner, because what will happen later – either as a result of buyer’s remorse, or as a result of a strangely inaccurate memory – is the denial of the decision by the decision maker.  This insidious problem can be very damaging to change leaders – typically more so to project managers, whose decisions are nearly always provided by external resources – but they can bite programme managers and directors when the decision weakness is far enough up the chain; or when for instance the host organisation’s operational leadership agree, then later disagree, to host the organisation and change output created by the programme.

Frustration sets in all around with Decision Weakness.  Those more junior see the decisions being made, then unmade; or stagnation setting in.  They quite rightly feel indignant that their efforts are not being allowed to be successful or proceed because of the failure of someone more senior – often quite a lot more senior – and if they aren’t fit to take these decisions, why are they in the more senior role?  This is a question I often have a lot of sympathy with.  If you can’t deal with the increased responsibility, don’t seek it, don’t let it be thrust upon you, or at least have the backbone to delegate to someone who can, and defend that position.  It also causes frustration in more senior – often Cxx level – executives, who have a view that change should happen, they want it to happen, and why isn’t it happening?

The organisations I’ve seen this most prevalent in are the ones where there are both too many levels of management, and too many managers.  This Decision Weakness stifles innovation; slows all kinds of change; kills agility; wastes a great deal of effort – both financially, but also precious focus, which large organisations already find it difficult to muster; and it drives good, agile, delivery-focused people out of the organisation to somewhere where they can get things done – compounding and accelerating the issue.

Decision Weakness.  It’s a bad thing.