The problem isn’t Agile: 3 models of motivation


Depending on where you like to get your numbers, it’s said that about 50% of all software development now uses Agile. That’s a remarkable achievement for such a profound change to the way we organise our work, our organisations and ourselves.

Whether that figure represents 100% successful implementations of Agile is more open to doubt. I would guess that few Agile coaches or consultants, and still fewer Product Owners, leads, developers or users, would say so. So it’s no great surprise that ‘Agile is dead’ articles seem to appear more and more frequently or that they garner support from what are, in Agile terms, really quite lofty circles – more than one signatory to the original Agile Manifesto, for a start.

So is Agile in its death-throes? Absolutely not.

A brief diversion: I had the good fortune to be taught for several years by Zygmunt Bauman. Professor Bauman was one of the leading lights of post-modern thought – the same fountain from which, I would say, Agile itself sprang. One day I heard Professor Bauman making a brilliant reply to those who thought we should invest more in the hard sciences rather than the social sciences. His argument was that there was already far more scientific knowledge in the world than people who understood it, so plainly the problem was not generating more knowledge but rather (to paraphrase Bauman’s words):

  • How to get knowledge into people’s heads.
  • How to get it out again in the form of useful action.

In other words, the real problem is one of communication, persuasion and implementation. And these are questions for the social sciences, not physics or chemistry or even biology. So that was where (I can see the professor’s pleasant smile as I write) we should be funding research.

What has this to do with Agile? Quite a lot. As management enthusiasms go, Agile should be quite mature by now. The Agile Manifesto came out in 2001, so it’s getting on for two decades old now. We’re long past the time where we needed to put a lot of extra effort into working out what Agile is. The problem Agile faces now is not getting people to understand or accept it in principle, but to make a success of doing Agile. And that isn’t going as well as we’d all like.

But it’s not totally clear where the issue lies: Is the problem that Agile is inherently faulty (as most ‘Agile is dead’ pieces suggest), or are we just not doing Agile properly?

This article doesn’t try to answer this question. Instead I’m going to start with the assumption that the problem isn’t Agile. In fact, the problem has never been Agile. The problem is the familiar one that we’re building stuff (in this case Agile itself) without giving people enough support:

  1. to understand what we’ve built.
  2. to persuade them to want it.
  3. to know what to do with it.

And so, assuming that that is the real problem, the rest of this article focuses on a group of models that offer some insight into why Agile is hard to implement. Fortunately they also suggest ways we could make it a lot easier.

Model 1: The Chasm

The basic problem with implementing Agile is one that is very familiar to change managers.

It can be readily explained in terms of the equally familiar ‘chasm’ model:

The Chasm

Before the Chasm

Looking at this model, it’s not easy to resist concluding that this is also a model of Agile’s conquest of software engineering. Before The Chasm, everything’s fine.

  • Early adopters are keen.
  • They already want Agile.
  • They already understand Agile.
  • They’re willing to go the extra mile for their cause.
  • They aren’t put off by early difficulties.
  • They don’t demand much support.

Now I would guess that the first 10 years of Agile consisted very largely of preaching to individuals on the left-hand side of The Chasm:

  • Innovators (not only the originators of the Agile Manifesto but also many other contributors to the revolution); and
  • Early Adopters, who could see both the value in Agile and its superiority over waterfall.

For these groups, Agile is obviously a ‘good thing’ and they were happy to take the change on board. Implementing Agile among these groups was pretty simple and easy.

So the rest – the next 10, 20, 30 years – will be just as easy. Won’t they?

After The Chasm

Unfortunately, no, they won’t. As we all know, only about 10-15% of your organisation is likely to lie to the left of The Chasm. So if we’re now at 50% penetration, it may well be that most contemporary ‘Agilists’ – roughly speaking the Early Majority – are less than 100% committed to the cause. That’s not to say that they are actually reluctant, but not much has to happen to dent their confidence and enthusiasm. And without confidence and enthusiasm, Agile really is dead.

So after The Chasm, it’s not so fine. Indeed, the farther you move to the right, they’re increasingly:

  • Indifferent. Maybe even actively hostile.
  • Barely aware of Agile & not eager to learn.
  • In need of active support if they’re going to make it to Agile.

So what is the answer? Obviously, it is to give people the support they need. But what sort of support is that, and how are you going to provide it?

In a way the answer is quite simple:

  • Hire genuinely experienced consultants to show you the way (and get you over some of the bigger bumps in the road).
  • Get your people trained. All of them. Properly.
  • Hire decent coaches to help them learn to walk.
  • Implement a decent toolset.
  • Develop or (Warning! Blatant plug!) subscribe to an industrial-strength methodology that embeds Agile organisation, processes and techniques directly into their everyday work.

There. Done. Not cheap, but given the benefits that are likely to flow from Agile, surely worth it.

Bridging The Chasm

Or is it? Well, maybe. But if you’re somewhere to the right of The Chasm, it remains a bit of a risk.

So what can we do to ensure that buying in all those consultants and coaches and tools and methodologies adds up to a successful implementation of Agile? A very large part of the answer comes not only from communicating what you want your people to do (e.g., adopt Agile) but also from understanding the key tools needed to create:

  • A set of messages that are tuned to your audience’s preferred modes of communication; and
  • A mind-set that is receptive to your messages.

Hence the other two models we need to make a success of implementing Agile:

  • Howard Gardner’s seven levers of influence set out multiple modes of communication – from straightforward logical explanation to social proof to offering reward for compliance.
    • Gardner’s toolbox of levers is powerful and persuasive – assuming, that is, that your audience is in a frame of mind to be persuaded.
    • But if they’re not?
  • So we also need to answer a second, equally important question:
    • What kind(s) of situation(s) do you need to create to make sure that the levers you apply actually work?
    • In many ways this question is harder to answer: as anyone in the media will confirm, it’s one thing getting great programmes out, but quite another to get people to tune in.
    • Hence the value of our second model: Robert Cialdini’s seven principles of persuasion.

I should emphasise that both Gardner and Cialdini’s models are used here only as jumping-off points for a more general argument. I add quite a lot of comment and interpretation of my own. So don’t read what follows as a strict account of either!

Model 2: Howard Gardner’s Levers of Influence

In 2004, Howard Gardner, the eminent Harvard psychologist, published Changing Minds: The Art and Science of Changing Our Own and Other People’s Minds.

In it he discussed the notorious difficulty of changing people’s minds, and proposed seven ‘levers’ changing people’s minds.

  • Reason.
  • Research.
  • Resonance.
  • Redescriptions.
  • Rewards and resources.
  • Real-world events.
  • Resistances.

The scale of the change required to adopt Agile is notoriously great: not only does it demand different processes, organisation, roles and responsibilities from, say, waterfall, but it also makes radically different assumptions about how work is to be done at the most profound level. In fact almost everything about waterfall is thrown out, leaving a completely transformed delivery landscape. So getting people, especially individuals who may have spent decades mastering waterfall, to change their entire way of working is a major challenge and requires correspondingly profound thought and forceful action.

So, behind the labels, what are Gardner’s levers? In the next few sections, I suggest:

  • A description of each lever.
  • Examples of how that lever is used in the non-Agile world.
  • Examples of how that lever might be applied to an Agile implementation.
  • That individual lever’s risks, weaknesses and limitations.


The power of Reason lies in its ability to provide an explicit, formal argument both for what needs to be done and how to do it. It uses techniques such as logical arguments, formal models and mathematical calculations.

In the everyday world we are surrounded by examples of Reason:

  • Scientific method.
  • Gantt charts.
  • Business cases.
  • Taxonomies.
  • Logical arguments.
  • Etc.

(More weakly, analogies can communicate the general shape and intention of your approach. However, analogies are open to interpretation, debate and conflict.)

So, when implementing Agile, use Reason to:

  • Lay out Agile’s pros and cons.
  • Define the case for Agile (business, operational and user).
  • Create an implementation roadmap.
  • Set out your implementation schedule, track and approve the budget, assign resources, etc.
  • Model use cases, design formal processes, document explicit roles and responsibilities, etc.

Reason provides the formal backbone of any management strategy. It is also one item you should always have, regardless of what other levers you apply.

  • If you can’t say in a clear, rational form what adopting Agile means, how it will work and how it’s justified (supported by Research), then you are taking a serious risk.
  • So even when other levers may be more important to the overall success of your implementation, defining, agreeing and implementing at least a minimal suite of formal controls can provide confidence and ensure that uncertainty is minimised.

The weaknesses of Reason are familiar to all of us:

  • Reason is not the same for everyone. Or rather, the reasons each person finds compelling can be very different.
    • Even within a single company, what motivates a Chief Finance Officer to accept Agile is not the same as what would justify Agile to salespeople, developers, HR, business operations, facilities management and your customers.
    • So creating and applying the Reason lever can become extremely time-consuming and complicated.
  • Superficially ‘rational’ arguments are often freighted with unspoken assumptions and prejudices. It is crucial that they should be authored and presented by trustworthy sources.
  • In management and business as a whole, there are few comprehensive models of anything, so arguments based on Reason are likely to be at best partial, at worst highly selective, and need supporting by the other types of persuasion.
  • Not everyone is good at reasoning, especially when a rational approach conflicts with emotional commitments and self-interest.


Research provides the information that both:

  • Validates the arguments and models defined when using Reason to explain why Agile is a good idea; and
  • Tracks the real performance of the Agile implementation.

For example, if you were making a journey, Research could be used to justify why the trip was worth taking, and then to tell you whether you’re going the right way, how soon you’re going to get to your destination, how much fuel you have left, etc.

Examples of Research in everyday life include:

  • Performance results.
  • Case studies.
  • Maps
  • Diagnostic tools..

More generally, like Reason, Research is a fundamental component of any rational management strategy. It should be something you have to justify any significant change, regardless of what other levers you plan to apply. And in other cases too, it is an invaluable support to other kinds of justification for Agile.

When implementing Agile:

  • The case for doing Agile in the first place needs to include credible industry data that:
    • Quantifies the benefits Agile can deliver.
    • Shows which parts of Agile successful Agile organisations actually use and which they don’t.
  • It’s valuable to have a defined baseline against which Agile’s costs and benefits can be compared, such as:
    • Productivity.
    • Time to deliver.
    • Defects in production (and how fast they are cleared up).
    • Etc.

However, Research has its weaknesses:

  • Like Reason, Research isn’t as simple or as easy as it sounds.
    • Different Reasons are needed to persuade different groups.
    • So the supporting Research will need to be adjusted for each audience.
  • Solid data about Agile – good or bad – is not as easy to find as one might expect.
    • So a heavily Research-based approach is a challenge.
  • In most organisations, establishing relevant baselines to verify whether Agile is succeeding is:
    • Difficult.
    • Expensive.
    • Disruptive to BAU.
  • Research needs to be robust if it is to be credible.
    • Relatively few people have the time, resources and skills to ensure this.
    • Easily acquired information such as anecdotes, small samples and cherry-picked data is of doubtful value, is usually easily contradicted and all too often can be overturned by a simple ‘So what?’
    • When this happens your Research will actually set your implementation back, not drive it forward.

So although Research is a powerful tool, especially as an add-on to other levers, good Research is hard to come by and bad Research can end up biting you.

Reason and Research both appeal to the intellect. But the intellect is never the only factor in making major decisions, and often it’s not the most important. Resonance is more emotional. It relies on presenting an issue (in this case Agile) in a way that makes the audience feel comfortable with it, believe that it makes sense in the current situation and, if effectively communicated, they may even feel an intuitive enthusiasm for it, even before a more rational case has been made.


In a way, the key skill you need in order to apply the lever of Resonance is very like story-telling: once your audience is really engaged, it’s a lot easier to get them on board. A clear tale of heroes (them), villains (the past), a destination, a clear recognition of the obstacles they will find on the way and how they will bravely overcome them – it all makes for a truly resonant account your audience can really believe in!

Of course, we are surrounded by forms of persuasion based on Resonance:

  • Adverts that try to associate products with desirable lifestyles.
  • Internal corporate marketing programmes based on words like ‘passion’.
  • Dog-whistle politics.

In the context of Agile, Resonance can be used very effectively:

  • Make clear the cultural pre-requisites of Agile – they represent a very high level of achievement, but also match the aspirations and self-image of many software engineers.
    • So the message becomes, ‘That’s the sort of people we are – responsible, pro-active, disciplined professionals.’
  • Emphasise the positive aspects of Agile – the satisfaction of frequent delivery, responsiveness to change, empowerment, etc.
  • Use ‘negative’ resonance – e.g., by emphasising the uncomfortable elements of the previous non-Agile (e.g., waterfall) approach – bureaucracy, rigidity, frequent overruns, etc.
  • Creating Resonance is much harder when faced with a large, diverse audience or complex, multi-dimensional problem.
    • So try to break down your audience and address different segments separately.

Unfortunately the problems and downside of Resonance are also widely known:

  • Agile will have different and even conflicting Resonances for different groups and individuals. It can become difficult to navigate how it changes meaning as the implementation process unfolds.
  • If Agile starts to be surrounded by a negative ‘feeling’ across the organisation (perhaps as a result of early setbacks or the circulation of ‘Agile is dead’ articles), it becomes difficult to recover.


The value of Representational Redescriptions (or just Redescriptions) lies in two basic facts:

  • Different audiences respond best to different messages, formats, language, and so on.
  • The same audience – even the same individual – will be more persuaded if you communicate your message to them on many levels.

So use multiple Redescriptions, and you’ll have a better chance of achieving the desired impact – especially if you suspect that your audience is reluctant to make the desired change.

  • They will respond to your message on many different levels – intellectual, emotional, social, even economic. If one level doesn’t work, another might.
  • The use of multiple Redescriptions can also be used to reinforce your message: by restating the message in different forms, it provides a different view of – and so an additional support for – the underlying idea.

As Gardner observes, there is a tendency for Redescription to be underestimated. We tend to see others as one-dimensional beings (manager, employee, coder, user, etc.) and forget that they are rounded human beings. So don’t just repeat yourself: restate the message in different ways, in different formats, in different contexts.

In everyday life Redescription is extremely common:

  • Written traffic regulations are long, complicated and extremely verbose.
    • This is essential if the law is to be correctly stated and applied and traffic offences are to be judged fairly.
    • But traffic lights and road signs use extremely simple symbols to give instructions and explain conditions that could not be understood by the drivers of fast-moving vehicles if they were expressed in words.
  • Computer manuals explain what a program can do and how it does it in rather wordy manuals.
    • This is essential when you are still learning its capabilities.
    • Computer icons are used to access commands and options that could not be written out (typically not even as single words), given very limited desktop real estate.

Setting is also important. We often find that an idea is more convincing if it is communicated in a friendly, informal environment (e.g., over a drink or at an unrelated event) than in a formal setting directly related to the idea, where there is pressure to conform. It is then that, as Gardner puts it, ‘the usual assumptions and resistances may be idling’[1]

When implementing Agile:

  • Make sure your communications, from high-level aspirations to detailed technical training, are carefully tailored to each audience.
    • The content that conveys the message ‘Agile is a good thing’ or ‘Here’s how we’re going to implement Agile’ will be very different for a business executive, your HR department and a coder.
    • So agree a communications plan that identifies each audience, their unique interests and how you mean to address each one.
  • Phase your communications to suit how far your change programme has progressed.
    • A comprehensive document may be a useful tool for detailing and agreeing the programme up front.
    • But such detail is seldom useful – and often downright obstructive – when you are trying to quickly state the overall process. In those circumstances a one-page summary is usually more than enough.
  • Even when you think Agile is up and running, use posters, briefings and other simple, direct vehicles to reinforce key messages.
  • Make sure that your implementation team understands the value of Redescription and is expert in all forms of communication.

Redescriptions are useful but they are also error-prone:

  • Sometimes a picture really is worth a thousand words. But sometimes it’s obscure, assumes too much to be useful to new users or is just plain confusing.
  • Sometimes having different versions of the same message introduces inconsistencies and contradictions.
    • This is especially likely when informal events based on personal relationships are included.
  • Simplistic symbols can lead to users conventionally interpreting them in ways their creators never intended.

Rewards and Resources

One lesson every change manager learns very early is that if you don’t reward those who are willing to make the change and/or you don’t provide the resources needed to carry the change out, then that change will fail. It’s not exactly a surprising discovery, which makes it definitely surprising that this is still a lesson that needs to be learned by many organisations. So make sure that you plan and distribute the Rewards and Resources at your disposal carefully.

Of course, Rewards and Resources are a fundamental of everyday life, especially in companies and other corporate bodies:

  • We go to work to get paid.
  • In well-run organisations,
    • If we’re asked to take on new, higher or more challenging responsibilities, we are compensated for the extra effort and responsibility.
    • Roles have resources allocated to them, even if it is only time to carry out the corresponding responsibilities.
  • On the other hand, a defining feature of badly run organisations is that Rewards and Resources aren’t connected like that.

The last point also explains the fundamental problem the Rewards and Resources lever is designed to fix:

  • Progress in implementing something new (such as Agile) is likely to stop when you stop providing the corresponding Rewards and Resources.

When using Rewards and Resources to implement Agile:

  • Have a Rewards programme
    • Make it explicit.
    • Tie Rewards to key events and outcomes (e.g., building a credible backlog, starting the first release, etc.).
    • Reward teams for their contribution to Agile as a whole.
    • Track and publicise results and the awarding of Rewards.
  • Make sure that you allocate realistic resources.
    • Agile won’t just ‘happen’.
    • Go back to the earlier section on The Chasm, and consider what is needed to start and to support not just the Innovators and Early Adopters but also the other, more reluctant 85%.
    • Especially in larger organisations, areas that generally need resourcing include:
      • Consultants to provide overall guidance and any specialised change management skills your organisation lacks.
      • Training.
      • Coaches.
      • Building or subscribing to a robust Agile lifecycle.
      • Tools:
        • The tools selection process, licenses and tool training.
        • Data migration and systems integration (e.g., with PMO, finance and reporting systems).
      • Redesign of related systems, processes and organisation (e.g., HR, PMO).
      • The impact of operational staff when a significant fraction of its users are co-opted into Agile teams for a large part of their day.
        • Who will do their day job when they’re not available?
      • The impact on BAU of such a radical change in how your organisation works.

Rewards and Resources are not totally straightforward:

  • If the Rewards and Resources you choose conflict with other levers or with how the rest of your organisation works, you will generate only friction.
    • This is most likely to occur when only part of the organisation is committed to Agile.
    • For example, if IT advocates Agile values but your PMOs still demand bureaucratic reports, hierarchical behaviour, a cadence based on waterfall, etc., Agile will fail.
  • If you start by using Rewards and Resources to effectively bribe teams to implement Agile, when the bribes cease, so may Agile.
  • Although Rewards can point behaviour in the right direction, don’t try to use punishment to stop undesirable behaviours.
    • Punishment usually leads to resentment, resistance and a growing sense that the behaviours you want to create are undesirable.
    • It is much more effective if you publicise the Rewards and the overall success of the implementation.

Real-World Events

Events in the real world can trigger interest in or enthusiasm for an idea that otherwise is neglected or ignored. So when promoting your idea, identifying a relevant Real-World Event can add to its attractions and persuasiveness. The event itself can be seen as a trigger, a warning or anything else – the only question is whether it is persuasive.

The effect of Real-World Events, especially on sales and marketing, is easy to see:

  • Major sporting events (e.g., the Olympics, the World Cup, the Superbowl) increase the sales of almost anything that can be associated with them, no matter how remotely or artificially.
  • After 9/11, sales of Tim LaHaye and Jerry B. Jenkins’ Left Behind series of apocalyptic novels grew by 60%.

Unfortunately, it’s less easy to see how Real-World Events can be used as a lever to influence the implementation of Agile. Still:

  • Either through official announcements, the professional media or your network of contacts, consultants, etc., it is possible to point to how both leaders and rivals in your field are adopting Agile. You should be able to mine a rich seam of events, comments and official statements that you can then present to internal audiences.

But Real-World Events have their limits:

  • The more specific the change you are trying to bring about, the fewer the genuinely relevant Real-World Events become.
  • The distance between the Real-World Event and what you’re trying to do leaves it open to multiple conflicting interpretations.
  • The artificiality of the connection is often clear.
    • Advertisements that try to connect products to major world events – of which there are many – are generally bizarre and often ridiculous.


If Reason and Research are the most public and objective levers at the change manager’s disposal, Resistance is the most subjective and private, and so the least under their control. Not exactly levers, Resistances are the individual and group’s attachments to the old ways of doing thing, or to obstacles that prevent them from changing. As Gardner has put it, they are ‘the ideas that are stale, erroneous, or harmful’.

Resistances are also less amenable to being changed by the other levers. In fact Gardner suggests that ‘change is most likely to come about when the first six factors operate in consort and the resistances are relatively weak’ – and least likely when the reverse is true.

On the other hand, Resistances are especially threatening when a change programme gets into trouble, because ‘such resistances make it easy, second nature, for most of us to revert…’

Gardner suggests three factors that make it especially difficult to overcome Resistances:

  • Ageing: you can teach an old dog new tricks, but it’s definitely harder than training a puppy.
  • Emotional commitments, many of whose original bases are now forgotten or even false, are the submerged rocks of navigating change.
  • Having previously taken a public stance on an issue makes it difficult to change your mind later.

It’s not difficult to add other factors to this list – cognitive dissonance, for example. It also seems to be the case that addressing Resistances directly can be akin to touching a nerve: there are strong reasons why it is precisely here that Resistance is being felt. So a direct approach may only make matters worse.

Conversely, Resistances are easier to overcome when:

  • The change is presented as improving, correcting or mending previous practice rather than abolishing it.
  • The change is led by a respected expert or authority.
  • Gardner’s other levers are applied specifically to remove them.
  • Core values such as professionalism, expertise and delivery are actively distinguished from the practices through which they were previously embodied, and the change is presented as strengthening those values by using better methods.

From the point of view of an Agile implementation, there are many familiar types of Resistance. Here are just a few:

  • Many years of experience of waterfall creates habits of mind (often expressed using phrases like, “Yes, but in the real world…”) that need to be combatted in detail.
  • Some will feel threatened or made anxious by the radical changes in authority and control Agile generates.
  • Acquiring new skills, especially non-technical skills, without a compelling reason can seem an unnecessary effort.
    • Empowerment is not always welcomed, and Agile can look quite like chaos to a poorly informed business community.
  • The intimacy created by Agile’s emphasis on collaboration, collocation, sharing, pairing, etc., can be uncomfortable to some software developers.
  • Many organisations suffer from change fatigue, which needs to be overcome at group level.

[1] Interview in CIO, 1 April 2004.

Model 3: Robert Cialdini’s Model of Influence

Gardner’s model identifies many of the possible channels and techniques that can be used to manage change. But channels alone are not enough.

What kinds of situation or relationship do you need to create to be sure that the messages you transmit have the desired impact? After all, as anyone in the media will confirm, it’s one thing to create great programmes, but quite another to get people to tune in.

To answer this question, Robert Cialdini wrote Influence: Science and Practice, in which he identified seven relationships, either to the person who wants to create change or to the change itself. As you might expect, they overlap somewhat with Howard Gardner’s levers, but taken altogether they provide a quite different and complementary perspective.

This is Cialdini’s list:

  • Reciprocity.
  • Commitment and consistency.
  • Social proof.
  • Authority.
  • Liking.
  • Scarcity.
  • Unity.

So what do the items on this list mean? As with Gardner’s levers, the next few sections go through each of Cialdini’s principles, offering:

  • An explanation for each individual item.
  • Examples from the non-Agile world.
  • Examples of how each item might be used in an Agile implementation.
  • Its weaknesses and limitations.


Ask any anthropologist for the basic principles of human society and ‘reciprocity’ will certainly be an early candidate. As Cialdini himself puts it, ‘We are human because our ancestors learned to share their food and their skills in an honored network of obligation’ (p.29). People like – and feel obliged – to return a favour.

Every day we are surrounded by examples of reciprocity (for good or bad):

  • Exchanging gifts.
  • Doing – and calling in – favours.
  • Distaste for free riders.
  • Political contributions.
  • Tit for tat retaliation.
  • Being a ‘team player’.
  • Revenge.

Agile includes many elements of reciprocity, such as collaboration, sharing information, and a strong expectation of mutual support. When implementing Agile:

  • Make it clear that Agile’s commitment to professionalism means that the relationships between the Core Team, the Product Owner and the stakeholders is one of equals, and that reciprocity is a key element in these relationships.
  • Emphasise how Agile consists of processes with a strong element of reciprocity, such as professionalism, self-organisation, collaboration and teamwork.
  • Ensure that, as each Agile ‘ceremony’ (planning meetings, Daily Stand-Up Meetings, Backlog Refinement, Showcases, Retrospectives, etc.) is created, it embodies the mutual sharing and exchange of experience, information, skills and support, etc.

It is a powerful tool. However, reciprocity can have its problems:

  • It’s tempting to exploit the normal rules of reciprocity to create and exploit indebtedness in others, and so to force change.
    • This is always a mistake: the change will be carried out with bad grace and undone at the earliest opportunity.
    • The unspoken social rule is that favours (even unsolicited favours) should be returned, but perceived tricks should not (or at least, not with favours).
    • It should always be borne in mind that retaliation is also a form of reciprocity.
  • Corporate management messages sometimes attempt to replace control and being paid properly with the illusion (and obligations) of social (and zero-cost) reciprocity.
    • Phrases such as ‘people are our greatest asset’ or ‘treat the company as though you owned it’ often strike employees as insincere.
    • In most cases, any attempt by employees to act on them would certainly end in tears.

Commitment and Consistency

To a large extent, Cialdini’s Commitment and Consistency is the other side of Gardner’s Resistances. Gardner offers as an example of a Resistance the difficulty of changing your mind once you’ve taken a public stance. But this can be turned to the change manager’s advantage. Just as having previously taken a public stance creates a major obstacle to moving forward with the change, so creating Commitment (leading to Consistency) to the change itself is like a ratchet – it creates a new Resistance that will prevent those who make it from slipping back – especially when the going gets tough.

The other side of Commitment is Consistency. Once a commitment has been made, inconsistency is viewed as weak or even dishonest. And this is easily sustained, because the individual’s self-image includes their Commitments, so Consistency with that Commitment will help the individual to also accept related changes, even though the changes themselves are quite hard.

Commitment and Consistency express themselves in many areas of everyday life:

  • Making promises.
  • American schoolchildren reciting the pledge of allegiance every day.
  • Building brand images.
  • Good design.
  • Many religious rituals (e.g., rituals designed to make the sun rise each day in exchange for worship).

When implementing Agile, Commitment and Consistency can play an important role:

  • At each stage in the implementation, make sure that participants, stakeholders and senior executives make explicit and well-publicised Commitments to carrying out their role, providing resources, prioritising implementation, and so on.
  • Do not begin with Commitments that are too demanding or disruptive. Escalate them slowly, pushing a little harder as each new level of Commitment becomes feasible.
  • New Commitments will seem feasible only if previous Commitments were successful. So make sure each new Commitment is reinforced and supported effectively.

Unfortunately there is a downside to Commitment and Consistency:

  • As Ralph Waldo Emerson observed, ‘A foolish consistency is the hobgoblin of little minds’.
    • Sticking too rigidly to a previous Commitment can be disastrous if it turns out to be mistaken or obsolete.
    • Rigid Consistency often demonstrates a lack of understanding of the underlying purpose or principle of the original Commitment.
  • Commitment based on excessive zeal rather than considered reflection and judgement is likely to fail.
    • Zeal can usually be found better outlets.
  • Commitments based on trivial or passing requests and whims undermine the significance of more serious Commitments.
    • Stick to committing to top-level goals, principles and other ‘stakes in the ground’.

Social Proof

Social Proof provides a lever of persuasion because people are generally more willing to do things they see other people doing and more willing to accept the opinions of people like themselves than someone trying to sell them a commercial product of service.

Examples of Social Proof – not all benign – include:

  • Review sites such as TripAdvisor or product reviews on Amazon.
  • Focus groups and opinion polls.
  • Astroturfing (i.e., creating fictional grass-roots organisations to drive public and political opinion).
  • Imitation.
  • Common sense.

A good deal of research in social conformity suggests that there are many areas where Social Proof can lead to highly undesirable patterns of conformity.

  • g., hotel guests were 26% more likely to reuse towels (rather than send them to the laundry each day) if told that most of their fellow guests did so than if they saw a notice explaining the environmental benefits.

Social Proof also works the other way around – as a way of ‘taking the temperature’ on a topic. By analysing the patterns of reviews and opinion, organisations can shape their own products and pitches to tap into collective experience.

Indeed, the mere fact that you are willing to report how real users rate you can increase the credibility of your other actions and statements. It suggests that you are honest, so anything you say can be taken more at face value than it might otherwise be.

When implementing Agile you can use Social Proof in many ways:

  • Prime individuals to take early action and make sure their actions are noticed.
  • Provide alternative (less positive) interpretations for the Social Proof on which practices you need to replace were based.
  • Provide alternative Social Proofs that favour Agile.
    • See Research above.
  • Collect the experience and opinions of participants (e.g., by polling) and publicise the results – not just the ‘official’ top-down view of the process, which will lack credibility.
  • Make sure that successes are broadcast.
    • Make sure that failures are also broadcast, along with your remediating action, and then publicise how you achieved success after all.
  • Create a lessons-learned system, so new ideas can pass directly from team to team rather than being imposed from above.

Social Proof is not perfect:

  • Common sense is what you think when you’re not thinking.
  • If early results are negative, Social Proof (in this case, ‘Agile doesn’t work’) may bog down the change programme as a whole.
  • Social Proof can be hijacked by well-organised and vocal groups (astroturfing).
  • Social Proof can give rise to:
    • Irrational social conformity and compliance.
    • Unreasonable resistance to reasonable evaluation and change.


The great German sociologist Max Weber defined Authority as power plus legitimacy. People will normally obey a legitimate power, and the conventional hierarchical model of corporate organisation is really just a system of authorities. So using Authority is a powerful tool both in getting people to accept change and then to drive it along.

Authority is one of the most common features of everyday life, especially in public. Consider

  • Government.
  • Hierarchical organisations (including almost all business and public organisations).
  • The ‘revealed’ religions (Christianity, Islam and Judaism).
  • The legal system and police.
  • Contracts.
  • Traffic signs.
  • Uniforms (including business dress).

In the context of an Agile implementation, Authority has many uses, especially in a hierarchical organisation:

  • To initiate the process as a whole.
  • To ward off competition from other programmes.
  • To bring other, Authority-based groups (e.g., HR, Finance, PMOs) into line.
  • To ensure resources and priority among competing investments.
  • To create the external conditions for a successful transition to Agile.

However, as far as the change itself is concerned, the closer you approach Agile, the less the part played by Authority should be. A key component of Agile is that it allows experts and professionals to take control of many processes and decisions that were previously controlled by their superiors. In Agile this is based not on simply assigning Authority from above but by recognising the legitimacy of making decisions based on expertise and professionalism.

So although, under the right conditions, obedience to Authority is right (or at least sensible and rational) and disobedience wrong, there can a massive downside to putting too much faith in Authority:

  • A key principle of Agile is to make decisions collectively and to value networks of self-managing and professional experts over hierarchical Authority.
    • This is the opposite of the culture of many organisations.
  • Overuse of authority can reduce individuals you employ for their expertise and professionalism to unthinking automata.
    • For example, experts may bias their opinions and reports to meet the perceived expectations of the relevant authorities.
  • Being in charge does not necessarily mean that you are the person with the right knowledge to make a decision.
    • Always make clear the distinction between authorities (i.e., decision-makers) and experts (i.e., individuals with the knowledge, skill or experience to make decisions).
    • Establish proper relationships between the two at all decision-points in your processes.
  • A wide range of social psychology experiments have demonstrated the ability of uncritical obedience to Authority to lead to disastrous results:
    • Milgram’s experiments on obedience (1961) showed how ordinary people will obey the most shocking orders if they are backed up by Authority.
    • Asch’s experiments on conformity (1953) demonstrated how willingly people deny the evidence of their own senses in order to conform.
    • Zimbardo’s Stanford prison experiment (1971) showed how individuals placed in positions of authority will turn to real violence – even when they know they’re taking part in a psychology experiment.
  • Consider the chilling phrase ‘only obeying orders’.


The power of Liking when trying to persuade others to change is obvious. We are more willing to listen to people we like, and to follow them too. We are probably more willing to consider a change seriously – even one we don’t really want to make – when prompted to do so by people we like. We also want to be liked, which can be a useful lever in creating a collaborative (e.g., Agile) environment. Conversely, research suggests that collaboration as equals can help to overcome prejudice.

So it’s hardly surprising that Liking is a widespread fact of everyday life:

  • Friendship.
  • Likeable (e.g., attractive) people are treated better:
    • In politics, attractive candidates win more votes.
    • Attractive employees are better paid.
    • In court, attractive defendants are sentenced more leniently.
  • Teachers assume that good-looking children are more intelligent.
  • Celebrities are used in selling commercial goods and services or to fill the media.
  • Viral marketing relies on a greater willingness to accept a message that is passed on by a friend.

In the context of implementing Agile, you can make use of Liking by:

  • Having the change led (or at least presented) by someone who is well liked.
  • Use humour and stories (which make you appear likeable) to overcome your audience’s indifference, scepticism and hostility.
  • Emphasising how Agile devolves decision-making to team-level – which is to say, to the level of the people the participants know and (presumably often) like.
  • As far as possible, allowing teams to select their own leads.
    • They will seldom make the mistake of simply choosing someone they like, but the ability to include personal popularity will smooth the process and gel the group as a whole.
  • Piloting and prototyping Agile in teams that already have good relationships with their Product Owner, stakeholders and Extended Team.
    • This will lead to a more sympathetic and supportive relationship that in turn facilitates the process as a whole.

Of course, basing decisions and changes on Liking those who advocate them can have serious repercussions:

  • The notorious ‘halo’ effect tends to persuade us that people we like are also intelligent and capable – even when we have no real evidence that they are. So following those we like purely (or even primarily) because we like them can cause serious mistakes.
  • The need to be Liked can undermine the radical changes Agile requires. Some disruption and discomfort is probably unavoidable, so individuals who are reluctant to make themselves unpopular are unlikely to be able to ‘make it happen’.
  • There is a tendency to defend people and things we like, even when they need to change.


In many contexts, Scarcity is a positive value. Scarcity threatens our independence (i.e., we won’t have access to a scarce resource), so we often value things precisely because they are scarce. It also flatters our vanity to possess rare things – as though their Scarcity makes us special.

In the everyday world , Scarcity is frequently exploited:

  • Advertisements that emphasise the limited number on sale or limited availability.
  • We tend to value things most when they are under threat, so artificial threats are created.
  • Intrusion into other’s privacy (especially celebrities and politicians) is consistently sought by the media because it is rare and valued by the public.
    • Conversely, over-publicised (or publicity-seeking) celebrities can find themselves losing popularity.
  • In the Victorian era, oysters were plentiful and cheap, and so a popular food with the working class.
    • Huge oyster beds lay off the east coast of England, New York harbour and elsewhere.
    • Later, over-exploitation, disease, sedimentation and storms led to the decline of the oyster beds.
    • Their scarcity has since transformed them into over-priced luxury foods.
    • Polenta and lobsters – once standard prison food – have similar histories.

When implementing Agile:

With perhaps 50% of current software development to its credit, Agile is rapidly becoming the norm. So the Scarcity principle is hard to apply. Nevertheless:

  • Emphasise your ambition to achieve not only Agile but also the (relatively scarce) leading edge within Agile, such as continuous delivery.
  • Early in your Agile implementation, create a Scarcity in the right to participate in the pilots and prototyping.

The problems with Scarcity can be summarised as follows:

  • Scarcity can create panic.
  • Our tendency to prize scarcity can cloud our ability to evaluate a situation objectively.


Maybe it’s not surprising that, in the competition-obsessed West, Robert Cialdini only added the principle of Unity several years after he created the original six. Nevertheless, it is an extraordinarily powerful force, even in the most adverse conditions.

Unity is about a sense of identification with others – who are, in some important sense, the same as us. It’s more than similarity or resemblance – ‘like us’ and ‘one of us’ are very different things. And the more we identify with others, the more we are influenced by what they say and do. Hence the importance of Unity to Cialdini’s model of influence.

But Unity goes beyond just influence. The deeper value of Unity is that it is highly motivating – probably more so than, for example, liking or authority. They lead to a willingness to do stuff when asked or told – basically, a rather negative motive. But Unity is likely to lead to a positive desire to get involved. As a result, Unity can lead to:

  • Higher levels of commitment and energy.
  • A greater willingness to overcome obstacles.
  • An enthusiasm for mutual development and support, especially when team mates find themselves in difficulties.
  • A spontaneous commitment to key Agile disciplines such as self-organisation, collaboration and pairing.
  • Attracting better individuals.

There’s no end to the cases where Unity is called for (or sometimes ruthlessly exploited) in everyday life. For example:

  • Shared values (e.g., charity, patriotism).
  • Shared symbols (e.g., saluting the flag)
  • Brand loyalty.
  • Sports fans singing – and warfare.
  • Politicians presenting themselves as an ‘ordinary guy’ or an ‘outsider’ (i.e., just like the electorate).
  • Successful advertising and public information campaigns routinely exploit our desire to be like our neighbours, fellow citizens, etc.

When aiming for Agile, Unity is a powerful tool:

  • Make it clear that Agile is the chosen approach of increasingly many of your audience’s peers in other organisations.
  • As various groups within your organisation migrate to Agile, make sure that other groups see what their colleagues are doing.
  • Repeat how Agile is more and more the norm in software engineering, so non-Agile organisations and teams will become increasingly ‘out-groups’.

But not even Unity is infallible:

  1. Highly unified teams may become super-defensive in the face of the need to change.
  2. Unity can create out-groups as well as in-groups, leading to irrational hostility.

Applying the models

What can we say about making use of these three models?

How do you use them together? Here are a few general pointers:

  1. Take The Chasm very seriously:
    • Early success does not mean that long-term results will be just as easy to achieve – or can be achieved at all by just applying ‘more of the same’.
    • Any strategy demands a phased approach that recognises that the situation changes as you proceed.
    • Quite often later situations change precisely because of what went before.
    • This is exactly as true of implementing Agile as of a marketing campaign, building a business or indeed fighting a world war.
  2. Recognise that, as has often been observed, culture eats strategy for breakfast.
    • If you don’t recognise the fundamental difference between Agile and waterfall and the completely different culture each demands (and creates), then your chances of success are slim.
    • So you need to organise a change process that operates at every level.
    • Garner and Cialdini’s models of persuasion and influence give you many of the tools you need to do this.
  3. Keep in mind the difference between Gardner and Cialdini’s models:
    • Although Howard Gardner’s books cover very similar territory to Cialdini’s and there is some overlap between the two models, they are mostly about rather different parts of the persuasion and change processes.
    • The seven levers Gardner suggests (apart from Resistances, which are obstacles you apply his levers to) are channels and techniques for persuading your audience.
    • Robert Cialdini’s seven principles are more about creating a relationship with and attitude to the change and the change agents.
    • So Howard’s levers are about delivering the right type message, while Cialdini’s principles explain how to persuade your audience to pay attention to and accept your message.
  4. You shouldn’t expect all of Gardner’s levers or Cialdini’s tools to work equally well with each part of your audience or at all phases of the change process.
    • Some people are happy with pure, logical reasoning, while others need social proof, practical examples or public events to propel them into action.
    • They all need to be applied selectively, choosing carefully when, how and on whom you use them.
  5. Choosing the best lever in any given situation and the best way to apply it also depends on simple practical factors:
    • Are you addressing your audience face to face, or indirectly?
    • Are they fundamentally for or against the change, or are their views very mixed?
    • What kind of background do they have? Are they technically minded? Business-minded? Or something quite different?
  6. The success with which you change your audience’s minds also depends on the make-up of the audience.
    • A single, homogeneous audience that shares the same background, work experience, training and motivation is more likely to be happy with a simple, conceptually taut message that is tightly bound to their situation and interests.
    • When faced with a more complicated, mixed audience, a more organic approach works better – one that uses shared experience, common feelings and public events.
  7. You need to match your tools to the phase of the implementation you are in, and how well it is going.
    • Avoid both dwelling on water under the bridge and looking too far ahead.
    • For example, there is a place for detailed technical training, but it isn’t generally at the very start of the change.
  8. Bear in mind the broader change environment – and particularly change fatigue.
  9. Never try to manipulate or deceive your audience into accepting change, and never keep any more secrets than you really have to.
    • They will find out, and they will resent it.
    • At the very least the change will be undermined – and your reputation with it.

Change is deep, complex and hard. But the alternative to change is frequently organisational decline and even death. So it’s critical to master the principles and levers, and not just make a half-hearted attempt or simply to turn back. And if you are going to launch into a change as fundamental as implementing Agile, mastering the models outlined by Howard Gardner and Robert Cialdini is surely worth the effort.

By |2018-02-21T10:51:09+00:00Monday, October 16 2017|Categories: Agile, All, Change, Empowerment, Innovation, Leadership, Organisation, Principles, Thought leadership|0 Comments

About the Author:

Chief Architect,

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.