Mike MacDonagh's Blog

Somewhere in the overlap between software development, process improvement and psychology

Tag Archives: leadership

I’m coming out as not-Agile and not post-Agile

Big A vs. Little a

Huh? What? I’ve written a fair bit on this blog about agile topics, but I always try to write about agility with a small “a”. I’m not really into Agile with a big “A” though – I’m not into doing things according to a set of rules and having arguments about whether I’m doing it right or not. I’m not anti-agile, but I’m increasingly anti-Agile.

To me, the ideological arguments, definitions of everything, frameworks, money-spinning certifications and money-spinning tooling are what’s wrong with doing “Agile”. Being empirical, reflecting and adapting, honestly communicating and putting people first as an approach is being “agile”.

I don’t really like the term “post-Agile” either though as it comes with a bunch of baggage and is easily misinterpreted – and I still see benefits in adopting agile practices. I don’t want to see another specific set of rules or a statement or beliefs with elitist signatures. For me what’s next after agile is about dropping the ideology in software process, destroying the ivory tower of trademarks, formal definitions, money spinning tools and money-spinning certification programmes.

We need to get rid of the League of Agile Methodology Experts and if anyone says “Ah, but this is different” when showing a website of process content then you have my permission to hit them with a stick.

So what does the future look like?

Software development is a complex social activity involving teams of people forming and self-organising to work together, sometimes in teams of teams which is even harder. As technology is increasingly abstracting up and raising in maturity so is the way that developers, managers and organisations think about software and doing software. I think the problem is getting increasingly social, and the solutions will start looking increasingly social using more “soft practices”.

Software process improvement agents/consultants/coaches/mentors (including myself) need to take a long hard look at themselves. Are they telling people how to do it right when they can’t even write HelloWorld in a modern language? I’ve said that to some acquaintances in the industry, generously qualifying “modern language” as something significantly commercially used in the last 10 years and seen them look quite offended at my insulting affront to their professional integrity. I’ll go out on a limb and say you can’t coach a software development team if you don’t know how to write software.

So… software process improvement?

TOverlapping concerns in process improvementhe world runs on software, it’s everywhere and it’s critical. Getting better at doing software, improving the software value chain, is a noble aim and will continue to be as it means getting better at doing our businesses and our lives.

For me process improvement (dislike that phrase as well) is going to be more about combining psychology based business change practices with the best bits of a wide variety of ways of working (agile, lean, Scrum, what you currently do, RUP, Kanban, various workflow patters etc.) with technical software development practices like continuous integration, continuous delivery.

We need to work together, not as “leaders and followers” or “consultants and clients” but as collaborative peers working together to apply specialist skills and experience so that we can all improve. Smart people should be treated as smart people, we have much to learn from them and should be thinking in terms of fellowship rather than leadership.

I’m calling this overlap “soft practices”* because the term is evocative of:

  • The practice of doing software
  • The practices involved in doing software
  • Being able to deal with people is sometimes called  having “soft skills
  • Soft power

What do you think about “post-Agile”?

* I’ve even set up a company called Soft Practice to do this stuff, that’s why I’ve not been blogging much recently, who knew there’d be so many forms to fill in!

Edit 14/8/13: Seems others are now talking about the same things: Ken Schwaber, Dave Anderson, Aterny

Zen and the art of Enlightened Software Development

When I started doing software I was a simple developer interested in elegant code and shiny things. I worked in a small software house that taught me many bad practices in terms of configuration management, change control, estimation, management etc. It was an incredibly valuable experience for me in learning how not to do things and led me to strive for something better even though at the time I didn’t really know what it might be.

That led me through a path of process definition and documentation (RUP) and a rather limited following of an iterative lifecycle. I remember a conversation I once had with one of my project managers (when I was an architect) asking if we were going to do “Use Case Analysis” on a particular project or just skip straight into “Use Case Design”. The question puzzled me then because it felt like a trap and I didn’t really understand what I was being asked.

It puzzles me even more now as I know understand “analysis” to be a stop-and-think-for-a-moment activity and I’d always do a bit of analysis of my requirements, however these days it’s extremely unlikely that it’d be an analysis UML model, instead it might be a sketch, a conversation and a bit of thinking before another conversation.

So I moved from process prescription to process understanding, applying the spirit of doing things well rather than the letter of whatever current process law was in fashion. Following on from that I’m not really interested now in the details of what a book says someone’s role should be or how people should interact instead I think the real challenges in software development are social, not collections of technical practices (although there is  value in evolving better practices and tooling).

A colleague of mine commented recently that 20 years ago when he was doing software it was possible to understand everything from the metal all the way to the blinking lights on his bit of hardware. Software development in just 20 years has progressed incredibly and it’s just not that simple any more. We can understand the basics all the way through the stack but not all of the details. There are so many bits interacting that it’s just too complex. As a result the problems, technology and team working are all abstracting away from the tangible mechanistic past.

Developers are on a path from technical skill to mastery, as they begin to understand the kung fu of software engineering they can apply experience and deep understanding to solving the technical problems, doing away with formal process and just using the practices that they intuitively need, happily breaking the “rules” to get the job done in an efficient high quality way. I’m not entirely sure where brogrammers are on this evolutionary path, I’ll leave that up to you.

The problem, if it even is a problem, is that each person in an organisation is somewhere different along this path and even if they’re at the same point in the same dimension they might not be aligned in their interests and motivations. This makes team working amongst inherently complex social creatures a tricky proposition. The sweet spot is a team of fully enlightened software kung fu masters but that’s a really hard target to meet for a number of reasons. Consider the flower of team working evolution weirdness, which area is your team in?

One reason that this sweet spot is difficult to hit is because in any organisation half of the developers are below average in technical and social skills. Sounds horrible but is obviously true and the larger the organisation the more likely it is to be the industry average, not the organisational average.

This means that the centre of skill gravity for any team is unlikely to be on the w00t side of the scale.

In most large organisations the teams are more likely to be flattened pancakes across this bell curve taking in a reasonable representation of the organisation as a whole (especially as the highest skilled are often distributed amongst an organisation to attempt to bring up other teams.

This isn’t necessarily a problem though as there is value in diversity and individuals will each have different ways of thinking about things that can bring value to teams and organisations.

I’m beginning to think that the purpose of classic software process, and classic software process improvement is to try and move people along this scale from basic developer to software ninja, helping them to gain mastery through experience and feeding in the experience of others. When a team moves along this scale they begin to not need their process mentors any more and will seize their autonomy.

Technology is increasingly commoditised by innovation, as is software development and software process. I used to spend a lot of time teaching people Object Orientation but these days everyone just seems to know it, it’s nothing special or new, it’s just what people do. Similarly people are increasingly aware of the value of iteration, limiting work in progress, continuous integration and delivery. They need less process and less instruction as this stuff is becoming business as usual at least in more mature organisations.

As these problems are being solved I think that bigger problems are coming to the fore as they’re less hidden by low level development issues. The questions I see a lot of clients wrestling with are things like:

  • How can we foster the right kind of organisational culture?
  • How do we deal with requirements, architecture, releases, resources etc. in a complex system of systems environment?
  • How do we bring together multiple divergent interpretations of “agile”?
  • How do we manage outsourcing contracts in high speed agile projects?
  • How do we motivate and engage the business and technical communities?
  • etc. etc.

For me doing these things in a social collaborative way, that values individuals and teams, is Enlightened Software Engineering and encompasses the buzzphrase of the moment: Agile at Scale.

Solving these problems is less about technical skills and technical process content and more about social skills, psychology and understanding. Both from a coaching and business perspective.

So what’s my point?

My point is that software process improvement needs to focus less on individuals and more on teams, and teams of teams. That we should avoid ideology and take the best bits of knowledge and experience wherever we find them, growing our teams and individuals.

Also that we should apply more psychology to software process and business change finding socially resonant patterns for how we do things. True mastery involves not worrying about “breaking the rules” and from the outside can easily be confused with ineptitude.

Resonating social patterns with project processes

People are social complex agents, organising people is a bit like herding cats, however when people are working together collaborating in teams they can achieve amazing things. So why is it that some approaches and teams structures work and others seem to cause problems?

I’ve been thinking about things like nudge theory, servant-leadership, agility in software development, lean business, social business, serious gaming and agile at scale. Most people tend to think that these are all (or mostly) good things, they’re often desired bottom-up in businesses and support “faster, cheaper, better, happier” agendas. All good things that tend to be desirable at every level of a business and yet a lot of my work is about helping individuals, teams and businesses towards this simple agenda using these kind of things because although the goal is simple and the change is desirable, actually doing the change isn’t easy.

All of these things seem to “feel right” to people and are generally desirable and yet they are often at odds with traditional management techniques which tend to compartmentalise people and decompose everything into linear hierarchies.

So why is it that treating people like complex social creatures works better than treating them as simple functional unit? Er… because that’s what they are, people. I’d love to know why people think the opposite can ever work?

I think that the reason that the list of things up there is generally so successful at working towards faster, cheaper, better, happier business is that they are socially resonant. That is, ways of thinking about work such as agile software development are congruent with normal human social behaviour, that’s why they work.

Nudge theory acknowledges that people are lazy and don’t do what you tell them to. Delayed gratification doesn’t motivate most people so put things you want people to do in their way and gently nag them about it. Make it easier to do the right thing, make the wrong thing harder and more formal. The rise of the adult playground is a great example of this. People don’t want to be told what to do, they want their ability and contribution to be valued. Servant-leaders are ideally placed to nudge people, which they can do based on their personal social relationships.

One of the reasons that the agile movement has taken off as well as it has is because it treats people like people, in fact that’s in the agile manifesto! By aligning ways of working to normal human behaviour you are enabling your team to get on and do things intuitively, normally and comfortably.

Photo of east gate of Roman Forum

Photo by Mykola Swarnyk

I’ve been applying this kind of thinking to large scale project structures and that’s led to the Project Forum practice (think Roman Forum rather than phpBB!) which I’ve described as a “middle-out” management structure as it’s not bottom-up or top-down. Instead it’s more like a tribal council bringing together the leaders of other groups to an area where they can all have their voices heard. It’s democratic and social, it doesn’t pretend there isn’t any conflict instead it provides a vehicle to resolve that conflict. This structure resonates with democratic political structures from the tribal council all the way to parliamentary democracy.

In this model, the Project Manager has a pressure from the business to deliver and he gets to impress this upon the other members. Customers with a pressure for quality or short-term goals get to understand why their concerns need balancing with scope and resources. Contributing teams get to have their agendas and issues collaborated on by the wider group and can manage supply and demand of their resources. Wherever there is conflict the way to resolve it is through open honest communication, the Project Forum is that vehicle, providing a sort of open parliament. Yeah, I know it’s not a great name but I’m not good at naming things.

Most cultures have evolved away from autocratic dictators towards representative democracy in one form or another because that’s the way people want to collaborate socially. So why not apply the same model to large projects? Thousands of years of history already tells us it works.


This blog is part of a series on Holistic Communication: The linguistics of business change. Introduction, ethics and table of contents is all in the first post.

Scaled Agility: The Project Forum

Name: Project Forum (Middle-out management structure) – Agile at Scale practice

When it might be appropriate

  • In situations where multiple competing stakeholder groups with different agendas are required to work together
  • In situations where multiple product groups need to collaborate on a bigger outcome
  • Where there is a conflict in direction, resource management/ownership or scope between collaborating groups
  • System of systems development

What is it?

The Project Forum is an application of agile philosophy to large project structures. Rather than impose a hierarchy of decision making from the Project Manager downwards the Project Forum is a virtual team in the middle of all stakeholders.

The Project Forum is a self-organising democratic group that balances competing voices and concerns, owns high level scope and architecture, runs the high level release train and performs integration activities for the product.

Use of the Project Forum practice does not prevent any communication directly between contributing groups it only provides a vehicle for that conversation when it’s relevant for the wider project.

From Traditional to Agile at ScaleThe Project Forum practice is an example of Agile at Scale combining social business practices, technical software practices and ways of working to make a simple way of doing big complicated bits of work.

Read more of this post

Simple software project measures

I’m not a big fan of metrics, measures, charts, reporting and data collection. I’m not terribly impressed by dashboards with 20 little graphs on showing loads of detailed information. When I’m involved in projects I want to know 3 simple things:

  • How quick are we doing stuff?
  • Are we on track or not?
  • Is the stuff good enough quality?

There can be some deep science behind the answers to those questions but at the surface that’s all I want to see.

Organisations need to know that teams are delivering quality products at the right pace to fit the business need. To achieve this goal teams need to be able to demonstrate that their product is of sufficient quality and that they can commit to delivering the required scope within the business time scales. If the project goal may not be achieved then the business or the team need to change something (such as scope, resources or time scales). This feedback mechanism and the open transparent communication of this knowledge is key to the success of agile delivery.

The goal of delivering quality products at the right pace can be measured in many complex ways however, when designing the Project Forum agile at scale practice we looked at just 3 measures. In fact I should probably call them 2.5 measures as the throughput/release burnup can be considered mutually exclusive (if you’re continuous flow or iterative). The most important measure is people’s opinions when you go and talk to your team.

Simple Measures Dashboard

Note: in the measures section I often refer to “requirements” as a simple number, this could be a count, a normalised count, magnitude, points, etc. it doesn’t matter what’s used so long as it’s consistent.

Read more of this post

Social Business: Because people do the work

People, working together achieve business goals. Processes, plans and organisation charts don’t.

A group of people forming human relationships and interacting is often called a “team” but another equally applicable term is a “social network”. Add a common goal to do some work as opposed to sharing pictures of their latest cooking/pet/kid and you’ve got a bit of social business going on whether it’s recognised or not.

To get work done effectively you need teams to work together effectively and that means enabling the team to form relationships and collaborate together as a social network.  So how do you create an environment that fosters social networks focussed on achieving their goals and interacting with the wider organisation?

The answer to that question is variously termed “Enterprise 2.0″ (which I hate), “Social Enterprise” and “Social Business” which is a little ambiguous as it could relate to a business incorporating internal social awareness into it’s ways of working but it also refers to businesses who are aware of their interaction with their external community. Both of these meanings are based on the same awareness, only the direction of attention is different.

Any business can be enhanced by enabling people to work well together through cultural changes, process (ways of working) changes and supporting tooling. Image a world where:

  • You have an idea to improve your business capability, talk to your work mates who are sitting near you about it who help you refine the idea a little
  • You post the idea on a general ideas list within your organisation adding some tags to relate it to general topics
  • Other people in the organisation react to your idea based on finding from a tag feed, an activity stream, their relationship (work or social) with you etc.
  • They comment on your idea adding relevant experience and knowledge
  • Someone else IMs (Instant Messages) you about the idea and adds some useful thoughts
  • The idea has formed into something that sounds like it might be worth the company investing some time in, you promote the idea to a company backlog.

So far none of this feels like “work” and yet a network of people are forming around an idea that improves the business adding their expertise and opinions, collaborating on and for the business.

  • The idea gets given some time to investigate so you create an online project area, inviting the previous contacts to have a look and interact
  • You decide to have a meeting to look at the various ways forward for the idea, two team members are remote so they video conference in
  • You blog the meeting minutes to the project area so other interested people can add useful insights
  • During the lifetime of the project various team members post status updates and blogs about the progress, customers and users interact directly through face to face discussion, virtual discussion threads, vote on requirements etc. while the team continuously radiates progress and quality information in an open transparent fashion.

This part was definitely work but socially aware collaboratively work making use of a range of technologies to enhance the team’s way of working.

This is an example of social business, and one which I’ve had for real with one of my clients. You might already have things like wikis, a blogging platform, micro-blogging, social group areas, project areas etc. in which case integrating them and driving cultural change through soft practices to “allow” individuals to interact in a trusted collaborative environment might be necessary.

Alternatively you might have none of these things, but don’t worry you can get them for close to nothing as there are several excellent open source solutions for each of the technology features mentioned, in fact some open source packages (Social Business Software or SBS) can do most if not all of the above!

What does “Agile at Scale” mean?

There’s a lot of talk in the process improvement industry about the meaning of “agile at scale”, devops, lean and agile for a number of reasons. One reason that I’ve seen in successful agile organisations is that as development maturity increases with true agile adoption bigger problems present themselves. This is the natural progression of the science of development, what used to be considered complex (like Object Orientation) is now normal, a commodity. Innovation in ways of working is happening at the organisational, cross-team, cross-product level.

For me agile at scale (I’ve got fed up of the quotes already) means a couple of different things:

  • Repeating agile successes embodied in a team across an organisation (scaling out?)
  • Applying agile thinking to cross-product projects
  • Applying agile and lean thinking to development organisations
  • Applying agile and lean thinking to high assurance environments like medical, security, financial, safety critical, audited, regulated businesses.

Agile and lean? Yep, both with lower case letters. I’m not particularly interested in ideological approaches to software development, I believe strongly in taking the best bits of whatever processes, techniques, practices etc. you find externally, mixing them up with internal practices and ways of doing things to develop simple, pragmatic approaches to ways of working. Both agile and lean schools of thought promote minimising unnecessary work, shorter delivery cycles and higher quality, continuously learning lessons and empirical decision making.

The agile manifesto gave us:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Some great practices have evolved for applying agile and lean thinking like scrum, kanban etc. However all of the complex organisations I’ve worked with have found that there’s still space for more thinking in terms of how to run a software business, how to deal with big complex system-of-system problems, multiple competing stakeholder sets, programme and portfolio management etc. Not surprising really because the agile movement wasn’t about trying to do any of that stuff.

However organisations who are successful with agile transformations want to apply the successful open and honest philosophy behind the agile manifesto to other parts of their business as well as bigger and bigger projects and programmes because the results of “doing agile” (I promise I’ll stop with the quotes soon!) are so attractive when it’s done well, namely:

  • Shorter delivery cycles, higher quality
  • Deep engagement between customers and development teams leading to respect, collaboration and better morale
  • Quick identification of when things are starting to go wrong

Consider the following model, not uncommon amongst large organisations:

Diagram of nominal large inter-dependant organistion structure

This represents a typical software department or vertical section of a software department with a portfolio that provides the funding for work. Big portfolio’s are normally broken down into a number of programmes which in turn may levy high level requirements onto organisations (organisational sub-divisions that own multiple products) which may affect both legacy and new product development. Often within a vertical section of a business there will be many cross-dependencies in terms of requirements, technical dependencies etc. For many large businesses this picture is overly simplistic, indeed I’ve not included things like projects, component teams and a variety of business organisation constructs like product centres, feature teams etc.  So how do you apply agile and lean philosophy to this lot and more?

You can’t simply repeat the same practices recursively throughout an organisation to deal with larger scale complexity.  Imagine a chain of scrum-of-scrums, daily stand-ups at every level (at the same time, or staggered to allow representation up the chain?), sprint plans at programme level etc. What about if the business is regulated, audited, security focussed, high risk financial, safety critical, etc.

Ok, so what’s agile at scale then?

Agility at Scale is applying the spirit of agility and lean thinking if not the letter to these bigger problems. It’s about:

  • Valuing individuals and interactions, encouraging collaboration, reducing layers of communication over processes, tools and hierarchy
  • Valuing working software in the form of quality releases from short development cycles over comprehensive documentation, business analysis, enterprise architecture documentation
  • Valuing customer, business, developer and operations (see DevOps) collaboration over contract negotiation
  • Valuing good governance, transparency and honesty in progress, plans, costs and impediments over regular reporting
  • Valuing responding to change over following a plan at all levels of the business

Agility at scale is focussed simply on reducing unnecessary bureaucracy, reducing time to market and improving value.

So how do you achieve it?

The application of:

Of course each of those (and more!) is a complex can of worms in itself. A lot of these higher scale practices are only just emerging from high maturity complex (post-)agile organisations but in time more of those things will turn into links.

A good example of  “Agile at Scale” in action is the Project Forum practice

As always this blog is  a stream of consciousness so please, let me know your opinion?

What does a self-organising team really mean? Organisation!

The idea of a self-organising team is pretty established in agile software development, as a (post-)agile coach/mentor I sometimes find myself working with teams who are trying to self-organise. Here’s my approach for transitioning a team from being externally organised to becoming autonomous and self-organising.

The first thing to point out is that I believe that the result of a self-organising team practice is an organisation. I don’t know what the the organisation will be ahead of time, that’s what the team work out. What I do (and I think others should do) as an agile mentor/coach is:

  • Bring to the team methods and techniques they can use to self-organise
  • Information of self-organising and how to interact with other teams in an organisation
  • Experience of different structures and behaviours
  • Facilitation and support of the organisation

It’s not my job to organise a team, it’s my job to help them organise themselves.

Being an architect/designer at heart I take a simple approach to this kind of thing and think about it in terms of mission, structure and behaviour.

Mission

Team’s need to have a purpose. I believe in team’s seizing autonomy and declaring their purpose, even in a complex bureaucratic organisation. So long as senior management are willing to let people they employ to do a complex technical job actually do a complex technical job then there tends not to be a problem. Unfortunately it sometimes takes enlightened leaders to do this but I’ve seen more and more of them in both the private and public sector. A team needs to know it’s purpose and agree on it.

Structure

Structurally there are some nice ways of working out who should be in a team and what their role is. I recommend using competencies rather than roles. Competencies are a description of the skills required to deliver the mission of the team and come in levels ranging from the most basic to the most advanced form of e.g. Tester. Either grab some from a suitable process.

Get the team together and get them to score themselves on the range of competencies required. This achieves a couple of things:

  • Builds mutual understanding between team members of where the various skills lie and what level they’re at leading to mutual respect and avoiding misunderstandings around what people are “meant” to do
  • Establishes whether the team has enough coverage of the required skills for the job, without this knowledge how can a team commit to anything?
Competencies don’t need to be met my an individual, a combination of the individuals involved might meet the required competencies overall and that’s great when they, and the rest of the team, understand how they fit together.
An externally imposed organisation chart does not meet these goals.

Behaviour

Team’s need to know how they’re going to work so they need to understand their functions. As a starter I’d suggest that software development teams have the following functions:

  • Production (delivery of working product)
  • Communication (both internally with customers and with external stakeholders)
  • Decision making
    • Way of Working
    • Buy-in to the mission and direction
    • High level scope
    • Changes to agreed scope

A true agile team does all of these things as it includes all of the people and skills necessary (from devs, testers, users, customers, ops people etc.) to achieve them. The team is the vehicle for doing these things.

Each of these things is the tip of a fairly large iceberg. But the team need to work on understanding their Way of Working to do the production job. The team need to agree how they’ll communicate with each other and externally. Both of these are Ways of Working decisions. All function in a team comes down to decision making. Ways of working, communication techniques, scope management etc. need to be constantly refined which means you need constant decision making within a team.

Even buy-in to the team mission and direction (planning and/or technical) is a decision making process. It often happens implicitly with someone charismatic selling a vision and everyone kind-of nodding but that’s not the only way of doing it.

Different decision types deserve different methods

Just because a team is groovy and agile doesn’t mean that every decision should be fully democratic. For example when doing a customer demo to see if the product is on track it’s not normally open to a general vote on whether the product meets the customer’s needs or not. Usually the customer tells you and you have to put up with it.

I’ve written some blogs before on methods of decision making, methods for selecting a decision making model and some case studies applying all of this. The basic process is:

- identify the different categories of decisions the team needs to make
- identify (using a variation of the Vroom-Jago model) the mechanisms the team will use to make each decision type
- facilitate the decison making process reminding the team of their chosen mechanisms

Output

The output of a self-organising practice is an organisation. Since I believe in honesty and transparency I think that the best way to define and communicate this stuff is in a Team Charter. A Team Charter can simply be:

Mission

Some blurb about what the team does – Mission statement

Assertion of rights the team assumes – Autonomy

Who the team is

Who’s in the team, what’s their ability, how do they contribute to the required competencies – Structure

How the team works

A little bit about the practices the team uses. Such as using a continuous flow model, an iterative approach etc. Including the decisions the team makes and how they make them – Decision Making

If you’d like me to help your team self-organise get in touch. Do you have any other ideas on self-organising? Do you use a different approach?

Get your point across using positive statements

This is a simple one but amazingly important: use positive statements.

A positive statement is something like “to sprint you must run fast”. Conversely a negative statement is something like “to sprint you must not run slowly”. The problem with using negative statements is that for them to be processed by the listener the concept being negated (in this case running slowly) has to be represented first by the listener before being negated. Here’s two examples, one about software and the other about addiction. Then I’ll cover the more devious application of the technique before finishing with the positive application.

If you tell someone not to do something first they have to think about doing it, a bit like my purple penguin example in the introduction to this blog series.

Software

Here’s an example from software process training I used to hear regarding RUP phases: “The RUP phases Inception, Elaboration, Construction and Transition are not requirements, design, implementation and deployment…” This was a well intentioned phrase aiming to dispel a common misconception when risk-value lifecycles were first being introduced to classic waterfall minded managers. Unfortunately this sentence actually reinforces the misconception one and maybe two reasons, firstly it’s a negative statement meaning the listener has to make that link in their mind between these phases and the waterfall stages and then negate it. The second reason is that it’s too easy for a tired person on a training course to miss that key “not” word and totally misunderstand the trainer’s intention.

This happened to a colleague of mine who used this sentence and the client’s training manager sitting on the course mis-heard (swore they didn’t when challenged) and never used my colleague’s training services again.

Addiction

Imagine someone who’s going to give up smoking. Friends with decent intentions may say “Just don’t think about smoking” and yet the end result is that the listener has to think about smoking (linking in all of their anchored states).  In fact there’s a whole industry of negative statements around giving up smoking that are designed to make people think it isn’t an easy thing to do.

My first sentence might sound a little odd. Normally the phrase is “trying to give up smoking” but that’s because the word “try” presupposes failure which is why marketing folks have done their best to ensure it’s the normal way of talking about giving up. Just think of all of those adverts for giving up aids that tell smokers how hard it is. Sneaky.

The Sneaky Side

The problem is that a negative statement sneaks in a sliver of representation that counters the stated meaning. There’s a really insidious side to this when considering negative questions. Negative questions are any question including the word “not” (even in the form of a contraction when it’s even more sneaky) and they are a clever way of embedding pre-suppositions. Here’s an example:

“Don’t you think using positive statements is a good idea?”

Expand it out and it becomes:

“Do not you think using positive statements is a good idea?”

The second form of the question sounds very odd and unnatural. In fact it’ll confuse many people for a moment (excellent pattern interrupt) and yet the first form doesn’t sound so strange, and yet rather oddly people will almost always agree to a statement using a negative contraction. Magicians and mentalists use this trick a lot “Couldn’t you have changed your mind at any point?”, “Haven’t I been reasonably honest about …?”. And of course if the entertainers are doing it you can be sure the sneaky salespeople, callous cold-readers and other such charlatans are doing the same. In fact this particular construct is used especially heavily by cold readers, the effect is multiplied based on the level of rapport at one far end of the see-saw even slight nudge is enough to direct a listener.

If you consider the basic form of the question “Do you think using positive statements is a good idea?” you’ll notice that’s it’s neutral, it doesn’t presuppose an answer in any direction. That’s the difference.

The Positive Side

I’ve written a lot on the ethics of using somewhat sneaky linguistics before so I’ll leave out that discussion again. But there are some great positive ways to use this knowledge. Here’s an example from this very post (+10 internet points if you noticed it earlier)

In the section about addiction I wrote: ” there’s a whole industry of negative statements around giving up smoking that are designed to make people think it isn’t an easy thing to do”. I deliberately used a contracted negative statement that presupposes that it is an easy thing to do. I used a negative statement to cause a positive representation.

Another simple way to use this knowledge is to simply use positive statements. Tell people what you want them to do and think. Avoid telling people what not to think. (er.. two negatives in one sentence what the…?)

This works especially well with children, instead of telling them not do something (such as “stop being noisy”) tell them what to do positively (such as “be quiet”). The first makes the kid think about being noisy, the second makes them think about being quiet. However it must be said that even the most carefully crafted sentence isn’t going to get a little kid to be quiet, but that’s ok they’re meant to be noisy.

Finally

So, aren’t you glad you read this?


This blog is part of a series on Holistic Communication: The linguistics of business change. Introduction, ethics and table of contents is all in the first post.

Decision making case studies

I’ve previously blogged on a decision making model that involves understanding the decision making process and then the different ways a group can reach agreement and how to choose which method to use in which situation. This post covers some real case studies from my own experience that apply this model and help discuss some the issues involved.

This post won’t make sense without reading How to reach agreement in a group – autocracy vs. democracy as it contains the decision tree and questions this post refers to.

Read more of this post

Follow

Get every new post delivered to your Inbox.

Join 344 other followers

%d bloggers like this: