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.)


Assurance isn’t our conscience, it’s our coach

A lot of organisations use project or programme assurance as a means of checking people’s homework.  The stance of assurance is something like a particularly robotic teacher marking an exam.  Getting the right answer matters, and the right answer is the answer in the book.  Sometimes there’s flexibility to be interpretive, but often there isn’t; and the people who work in assurance are never going to be rewarded, recognised, or praised for being lenient.  It goes even beyond this into the realm of trap laying in some cases: the assurance function are there to catch you out, to spot the kind of inconsistencies which might be poor practice, or deliberate malpractice, and ensure punishment ensues.

The attitude of change teams towards this kind of assurance is, unsurprisingly, defensive.  If the best outcome you can have from interfacing with assurance is that they don’t give you a kicking, there’s no way the change team can gain anything, and everything assurance require of you is a pure imposition.

What if there was another way, a better way?

Assurance can be a very different experience indeed.  If you provide Assurance functions and activities with a clear, simple goal: improve the outcomes of our projects/programmes/whatever; and staff them with experienced operators in the field they are assuring; if you give them a direct link to feed back to update the methodology when new things are found, and ensure they share the good things they find liberally, there’s a completely different dynamic available.

You can go to assurance, and come out with suggestions on how to fix things; a fresh perspective on problems you’ve been tackling alone; even a public pat on the back for finding a different way of doing things which isn’t the standard process (yet) but works better.  “Works better” could mean “takes less effort input for the same result output” or maybe “gets to the same result faster” but if you’re really lucky it’s “takes less input, gets better output and faster too”.

At the very least, you’ve made sure that whatever problems you are facing are transparently visible.  This can help to overcome the still-common cultural problem of burying bad news.  Everyone has access to assurance, and that means there’s a route to getting problems aired which doesn’t get blocked by, for instance, an incompetent sponsor.

This depends on what the reason for assurance is.  If you are putting assurance in place because you want to improve project outcomes, or the ratio between inputs and outcomes (cost, effort, time versus benefits), a well constructed and appropriately targeted assurance function is just the thing.

If you’re putting in assurance because a lot of projects are going wrong, and your processes aren’t being followed, well that can help too – but it needs to be backing up and supporting a review of the clarity of your processes, and almost certainly some additional training.

If you’re responding to the discovery – possibly by an audit – that you haven’t got good control over your projects, you’ve come to the wrong place.  Adding assurance isn’t how you get better control; reinforcing control is how you get better control, and while there are many different ways to achieve that, simply forcing people to get better at covering up their mistakes – which is the result of adversarial assurance (as described at the start of this piece) – isn’t going to get you better control; it might well make things worse.





Servant Leadership

This is a topic I stumbled across long after I’d established what my values and intentions were in leadership, and I found myself feeling immediately at home with the concept.  Over time, I’ve found this term creeping into sufficiently common use that I can offer it as a description of what kind of leader I choose to, and aspire to be, and I find it is sometimes understood – and often looked up, and then understood.

It’s possible that it’s obvious from my other posts that this is how I prefer to be and act, but it’s also possible that this is a new term to someone reading this blog.

Before I provide a link or two to learned articles on the subject, I’m going to explain what it means for me.

I value myself at least partly based on what I can do for other people.  It makes me happy to help others, and it makes me happy to see others do well.  This doesn’t mean I lack the ability or desire to be competitive – play me at board games and you’ll see some competitiveness – but it does mean that I get a kick out of seeing my team do well, whoever I perceive my team to be.  That sometimes – often, hopefully – includes the leadership of that team above me on an engagement.  I call this heart.

It doesn’t mean that I’m a soft touch.  I want the team to do well; if that means that the best thing for the bulk of the team is that someone within the team leaves, that is what I will attempt to achieve.  I usually try to find a way to turn that person around, repurpose them, or otherwise get a result which is good for them as well, but in the final analysis, I can fire people, and I have.  It’s the hardest thing to do, but leadership isn’t about doing only the easy things.  I call this character.  This is also what I would rely on if someone in my team acted out a prejudiced *-ist attack on anyone to my knowledge.  A team needs a conscience, with sufficient teeth to matter.

Sometimes I have to protect my team.  A leader should shower the praise on their team that he receives from outside, but criticism should stop with the leader.  This does not mean that the team members are immune from criticism, or feedback, but it means that the leader should be the one to pass on that message, in the way which will give most benefit to the individual, and which will cause least avoidable damage; and the leader should be shielding his team from direct attack from outside.  I call this courage.  I’d like a better name for it, but when I want to mentally tick off the list, that’ll do.

I want my team to do well, so when I’m leading a team, I want to find out what things are getting in the way of them doing well, and get them out of the way.  Enabling people at a basic level is a key attribute of any manager: giving people the tools they need to get on with the job, always remembering that tools can be physical, software, intellectual and emotional.  Helping a socially awkward computer programmer (stereotype warning!) find some emotional intelligence and insight into the people around them can improve not just their productivity (as much as getting them a faster computer for compiling code), but it can improve far more that can’t be measured with numbers. Coaching and cajoling people, offering feedback and providing opportunities to learn and grow: these are the ways a leader can transform the effectiveness of their team. What’s getting in their way might be their ability to make decisions within the scope of their job.  Like many other things, making the right decision gets easier with practice and examples.  Empowering people isn’t about giving all of them unlimited sign off authority instantly, but empowering them to make the decisions they need to for a productive and happy working life – *and* – is a great way to get engaged and committed, enthusiastic contributors.  This can take the form of permitting them to flex their start times to something which works better for them.  It can be permitting them to choose to work remotely.  It can be keeping the organisation at arms length while a self-forming Agile team goes through the stages before “performing”.  All of this is still enabling to me, although somewhere in the middle for some people that switches to empowering.  I just view the whole thing as “removing barriers that stop people doing their best”.

The last attribute is foresight.  Some people find this easy, but I tend to the view that the ones who are superb at this don’t do a lot of the other things you need to do.  Nevertheless it is a necessary task.  All the enablement you can offer is not going to bring about the changes you need to deliver unless the direction is clear, and that’s especially hard to find in operational teams; when you’re leading change it’s usually a bit easier.  You can do this poorly and the change can still be delivered, but when you do it well you supercharge the team’s ability to deliver.  The larger the change, the bigger the focus on this attribute.  If you have this, but can’t communicate it, you’re going to at least make some good decisions.  If you have this and can communicate it, you can provide people with a vision of the future that can invigorate and even inspire them.

It’s a tall order, and it needs to be worked on every day.





Expansion is still non-linear

Last time I blogged, I mentioned that adding extra creatives to a project is one area where extra people can make a disproportionately good difference.  Well I implied that.

As with all things, it depends; but if what you need are many creative assets created in line with a brief, I do find that adding extra creatives to the team doesn’t just result in an expanded throughput, it ups the quality.  There’s a synergy in creative activities which seems to result from creatives talking about, and sharing inspiration from, their own and each other’s art.  I’ve seen this work best for graphical creatives, but I’ve also seen this work for wordsmiths as well.

I find it interesting, and I also find it inexplicable.  It ought to work for other intellectually-driven activities too, but somehow.. it doesn’t.  The complex interdependencies of coding make that kind of inspirational collaboration something you only see on rare, beautiful occasions, and you can’t plan for it.  The nature of testing isn’t something where someone else’s results help inspire you to .. find more bugs.  Infrastructure engineers sometimes work in pairs the way programmers often do, and with a similar improvement on quality of outcome as pair programmers get – but seldom, and not reliably.  It’s only creatives who seem to really boost each other’s performance in this way.

Or perhaps I’ve just been consistently spoiled in the creatives I’ve worked with?

(In the interests of balance I should add that I can’t imagine getting a gang of creatives to collaborate on a single individual deliverable together and that having the same magical effect)

It does make me wonder whether there’s a way to get the same effect with extra coders, but without the inherent additional complexity you usually get from independent code generation.