What we can still learn from Mao’s Little Red Book

I am old enough to remember Chairman Mao’s Little Red Book.

I mention this because China’s current leader, Xi Jinping, has recently had his personal political philosophy – so-called ‘Xi Jinping Thought‘ – elevated to part of the Chinese Communist Party’s constitution. So Xi joins Deng Xiaoping as the only leader since Mao to be honoured in this way.

The relevance of this event to the Little Red Book (otherwise known as The Thoughts of Chairman Mao) is that the Little Red Book was itself a very brief distillation of the very large body of Mao’s advice, analysis and sayings to the people of China that is also part of the Party’s constitution. And if you were a radical (or even just a trendy) in the Sixties there was no chance you didn’t at least have a copy of this small, fat tome on your bookshelves. The more enthusiastic type of demonstrator waved it vigorously at police lines, and it was a totem of right-on coolness. Some people even read it, though no-one I knew.

I remember quite a few of the spectacular slogans it contained, and also the complete lack of  conviction they conveyed to ears attuned more to the English language. This of course demonstrated the chasm that separates Chinese from English ideas about language rather than any specific flaws in Maoism. My favourite was ‘Peoples of the world unite and defeat the US aggressors and all their running dogs’. I so wish I had said that. You can see much the same sentiments in North Korean propaganda today.

So what has all this to do with Agile? Well, also during that period there was a story in the British press that seems to have been published primarily to ridicule Maoist revolutionism. It was about a lathe operator in a factory somewhere in China who had said that, once he had read the Thoughts of Chairman Mao, his lathe had turned three times as fast.

Of course everyone in the West laughed. What a fool. What a typical piece of idiotic Maoist propaganda.

But then another journalist found the man and took the trouble to ask him what he had meant. His answer was illuminating. Before he read the Little Red Book, he replied, he had simply come to work each day and followed orders. He had known all along that there were things wrong with his lathe that could easily be fixed but he did not think it was his job to do anything about it. Just obey orders. But once he had read the Great Helmsman’s tome he realised that it up to him to do something about it. So he did, and lo and behold, his lathe worked a lot better.

Not really very astonishing, of course. Yet I spend my life surrounded by staff and managers – often quite senior managers – many of whom would rather die than challenge the way things are done. And no wonder – after all, what would happen if they really took the initiative and did something on their own authority?

Perhaps I can answer that slightly rhetorical question by my own recent experience. I recently attended a long offsite management meeting led by my immediate boss. He’s a good guy – I like him, and he once told me that he had chosen to work in this company precisely because he was tired of bullying corporate cultures.

So far so good. But in the course of this same meeting we happened to talk about whether the company’s managers are empowered. Of course they are empowered, he insisted. I have told them they are. Of course they aren’t, I replied (over and over again – it was perhaps not the most constructive of discussions) – not until both the means and the authority are explicitly put into their hands. Which they had not been.

We came to a bit of an impasse, and started to talk about another subject. As he spoke my boss gave a little dig to one his other team members about a project that had overspent without his permission, and how the project manager had had a dressing down as a result. The amount the project manager had overspent was a small fraction of the total project costs, but this allegedly empowered project manager was in trouble. Most absurdly of all, my boss made it quite clear that, had the manager in question simply asked for permission to do what he did before he did it, he would have been authorised to do it anyway!

Apparently empowerment meant empowered to do things that work, but not things that don’t. Bearing in mind that empowerment is of significance only when you need to make a serious decision, this puts the average manager – let alone non-managerial staff – in an impossible position: they are damned if they do take the initiative, and damned if they don’t. I think I would rather have been Mao’s lathe operator. Except that I’d have had to live in Maoist China, of course.

I don’t know what happened to the lathe operator. Perhaps he succumbed to the Cultural Revolution or the Great Leap Forward – I’m not too clear on timelines here. But knowing what little I do about the realities of power in Mao’s China, I doubt that his sudden sense of empowerment was allowed to range very far beyond fixing his lathe. Whatever encouraging words Mao’s Little Red Book may have contained, the very clear top-down approach to power and control in China at that time would have made it hard – and dangerous – to demand much more than the right to tune his tools. (For anyone interested in Mao’s approach, look up the Hundred Flowers Campaign.)

And that is a lot of the point of – and the problem with – choosing Agile. Not that anyone is likely to end up in a ‘re-education camp’ for enthusing about Agile, but most corporate organisations suffer from a robustly top-down approach to management that makes it very hard to make a success of Agile. You can talk about empowering teams as much as you like, but if the old hierarchies – with the development teams typically right at the bottom – are not removed, no fancy words about empowerment are going to create an Agile culture.

So what do you need to do to ensure that empowerment sticks? Here are a few of the most important items:

  • Change the organisation. No, don’t just give it different names, actually change it:
    • Formally announce that the old hierarchy of teams is dead. Don’t just tell existing teams that they are now ‘Agile’ – explicitly kill the old management structure.
    • Formally define your organisation (at least as far as development is concerned) as a network of networks. This should make the players who operated at different levels in the previous hierarchy into equals.
    • In such a system, the business still tells development what it wants, but development will still have a professional responsibility to make sure they do the right thing for the users, for the long-term value and sustainability of the technology, for the organisation and themselves too.
    • Senior management on all sides must be not only willing but also explicitly tasked with supporting these arrangements and preventing anyone from backsliding into the old ways.
  • Recognise that you may not have the right people to do Agile.
    • Agile can be described as a set of processes, but in truth it’s really based on the commitment of self-disciplined, technically expert professionals. If that doesn’t describe the individuals who work in your organisation, this will be a major and perhaps insuperable obstacle to getting to Agile.
    • So be willing to re-assess everyone who has even the least influence on development for their suitability for the world you are trying to create. Here’s an example (from McKinsey) of what I mean.
  • Make it explicitly clear to the people (business, PMOs, senior IT management, etc.) who used to be able to demand things from the development teams that they no longer have that power, and eliminate the channels they used to have to do so.
    • For example, forbid any direct discussions between the business and the team and make the Product Owner the sole conduit between the two sides.
    • This will free the developers for more useful work, but even more importantly it will protect the team from constant intrusion, distraction and (it must be said) bullying.
  • Make sure that HR understand all this.
    • Their role is no longer to administer ‘human resources’ or (still worse) ‘human capital’, but to foster human relationships.
    • Their previous long cycles (typically a year) need to come down to Agile scale – weeks and months.
    • Likewise, their basic tools are no longer metrics and assessment protocols but identifying and fostering changes that promote collaboration, enthusiasm and all the other virtues of Agile. In other words, HR need to focus on creating a working environment where people positively want to work and have a passion for what they do.
    • Personnel need to be recruited for their all-round fit to Agile – their whole approach to teams, work, organisation, etc.
    • It’s no longer appropriate to think in terms of narrow ‘incentives’. People like to be paid, but if they are really suitable for an Agile organisation, they don’t need to be bribed to work. Good work is more fun than fun.
    • Personnel assessments, rewards and recognition need to change fundamentally to reflect Agile values and methods.
      • A great deal of Agile is about teams rather than individuals, and evaluations need to reflect this fact.
      • Emphasis needs to move to contributions to collaboration and creativity, to quality and to improvement, and away from pure ‘performance’ targets.
      • Apply the same rules to the business and PMO – they must be assessed at least in part in terms of how well they support Agile and the development teams.
      • 360° assessments need to become the norm.
    • As this is very much what I suspect many HR practitioners thought they were getting into when they first signed up, the hard part is likely to be explaining how this can be done rather than getting their buy-in!
  • Make sure that PMO understand all this too. In particular, many of their controls – for planning and scheduling, tracking, resource management, etc. – are no longer appropriate. For example:
    • It makes little sense to track development milestones such as ‘End of requirements’, ‘End of design’, ‘Start of test’, etc. in an Agile environment.
      • The basic units of Agile and non-Agile value – stories and requirements respectively – are too different to be simply mapped onto each other.
      • There are no distinct stages within Agile development – requirements, analysis, design, build, test, deploy, etc. A story is either done or not done, and the distance between start and finish is usually measured in days, not the weeks and months that typify waterfall projects and programmes.
      • On the other hand, Agile releases and iterations have pretty clear boundaries, so you could track them instead.
      • Even more importantly, Agile is all about the actual delivery of working software and real value, not interim milestones. So perhaps it would make more sense to measure in terms of value delivered rather than milestones completed? At the very least it’s far more convincing to the business and senior management.
    • Equally well, in an organisation that uses product teams, PMOs have little influence over resource allocation or management.
    • Change control – in many corporate programmes an endless nightmare – is taken almost wholly out of PMO’s hands, even as an administrative task.
    • There are plenty of other tasks a PMO could get usefully involved in, such as making sure that users who are co-opted to an Agile team have their BAU role either paused or properly back-filled. There are few forces more likely to undermine Agile than insisting that users embedded in a development team also have to complete their day-job.

And so on. If you go for Agile but don’t think about the wider organisational issues, then things will quickly become grim. But if you work on both at once, maybe you really will have a revolution in your organisation.

By |2018-01-09T22:37:24+00:00Monday, November 20 2017|Categories: All, Empowerment, Innovation, Management systems, Organisation, Risk|0 Comments

About the Author:

Chief Architect, Agile201.com.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?             
error: Agile201 is wholly copyright and copy-protected.