We spoke about agile maturity models, agile certification, real agile versus pretend agile and even whether there was a right way to do agile. We did not come to any agreement about whether certification and maturity models were good or bad but we did agree there was no one formula for success in agile.

This seemed logical at first but then I thought there really should be one formula we can apply. That way we can simply measure people on whether they are using it and correct their approach for them.

So after minutes of detailed research and experimentation I came up with the following formula.

In case it needs a little explanation – Success in agile is a function of:

• The sum of the ability(Wi) and care factor (accountability or ACi) of each person in the team divided by their individual cowboy like tendencies (CBi) where n = the number of people in the team;
• Multiplied by the ability of the team to self organise (A-so) and the effectiveness of the governance of the organisation (G-c)
• Where the ability to self organise is equal to the delegated authority (DA) of the team and the clarity of the boundaries the team can speculate and innovate within (CB).
• DA is equal to 1 minus the misalignment of accountability (what you are blamed/rewarded for) and authority (what you can change or make happen/fail). Note that this is regardless of whether you have accountability for what you don’t have the authority to make happen or you have the authority to do things that you are not accountable for (ie someone else gets blamed for).
• All divided by the factors that make it harder to be agile – the number of people in the team ( n) plus the real constraints holding the team back (RC) plus the organisational antibodies that attack new ideas with false constraints and other weapons (AB);
• All multiplied by the team learning factor (LF) which is equal to the sum of the team’s willingness to learn (Wl) and their ability to learn (Al) less the ”Safe to fail fudge factor” (Sf). Sf in turn means the extent to which the organisation says it is safe to fail in general but not this particular time.

Applying this simple formula should therefore lead to successful agile.

Taking it a step further, we can use the formula to produce the following pattern that we can imbed in our code to automate the process in a sub-routine. This is written in King 2.0 but can be translated into Java or Ruby on Rails:

Turns out to be easier than many people think – certainly easier than developing standardised maturity models and robust certification of good agile.

Of course there will be a delay before we get the code written and tested, so in the meantime I guess we can use the following workaround ….. the team should try to do the best they can, measure what happens and try to improve. But since others have also tried before and measured what happens the team should try to learn what others did and add that to their kitbag so they can try to apply the same approaches themselves.

But a comment on a recent article reminded me that I can be completely logical, and still not get my message across, if what I am saying is inconsistent with what people already think.

Akarmin (who left the comment) described the principle of consistency really well so I won’t repeat the description here. But I will provide an analogy and then talk about consistency within a document (as opposed to consistency of the document with the existing views of the audience).

Stories and analogies

When you see a friend from work at a venue that has nothing to do with work, you might not actually recognise them, because you are seeing them out of context. And in the same way when you see a comment in a document that does not match what you expect to see, or what you currently believe, then you will often simply skim the comment and interpret in a way that is consistent with what you already think.

So it is often helpful to provide the reader with a story, an example or a comparison to help them make sense of what you are saying. This helps them anticipated the idea that you are presenting and it also uses the principle of consistency to your advantage but making it appear that what you are saying is consistent with the story they just accepted (does this make it another example of a fallacy?).

Good writers of technical documents will use analogies, stories and so forth really well. Bad writers will use them far to often, or use them to distract from, rather than assist with, the understanding of what is being said.

So if you want to use your own “stories” within a technical document or presentation, you can check the story is useful by being clear on the following:

• The story;
• The point of the story (or the moral of the story); and
• The relevance of the point to the story to the argument or information you are presenting.

Similarly if you are trying to understand someone else’s document, you can also just write next to each “story” (Example, comparison, story, metaphor, etc) what the point of the story is and whether/how it relates to what is being put forward in the document.

Paragraphs, headings and document flow

Documents are easier to read if they unfold in a consistent way. 

A single paragraph should cover only one idea and the first sentence in that paragraph should set the scene for the rest of it. Compare these two paragraphs, for example:

My dog Lassiter is very friendly. He is a Labrador and they are particularly friendly, although dogs are generally friendly. The other day Lassiter …

Dogs are generally friendly, but Labradors are particularly so. Take my dog Lassiter, the other day he …

In the second example, I set the scene in general terms and then provide a specific example. I could have provided a specific observation and then connected it to a more general conclusion just as well, but if I jump around like I did in the first example then it is harder for the reader to follow what is going on. So each paragraph should either begin with a sentence that emphasises it most important point, or provides the context for the rest of the paragraph.

You can further improve the structure of paragraphs if I keep the same point of view and that people don’t provide multiple viewpoints in the one paragraph.

Or, more clearly, you can improve the structure if you maintain a consistent point of view throughout the paragraph (ie don’t hop around between, saying “customers can …”, “you can …” and “It is possible to …”).

Similarly, changing tone, terminology, or fonts within a paragraph can distract the reader from what you are saying.

But what about when you are reviewing a document someone else wrote? One thing you can do is turn each paragraph into a single sentence and see if you can make sense of the document.

Another thing you can do is go through the headings and subheadings in the document without reading the text. These will often provide a high level summary of where the document is going and what overall messages it is designed to convey.

In a good document, all the sub-headings under a heading will relate to both the heading and the other sub-headings.  For example, if the heading is “Cheese” the possible sub-headings might be “History, local varieties, qualities to look for”; or they might be “Edam, Cheddar, Blue”.  But it would be more confusing if the headings were “History, Edam, Other, qualities to look for”.

Predictably, this also means that your own documents will make more sense if you review and align the sub-headings so that they flow well.

So, each paragraph captures one idea and each paragraph within a sub-heading should support or expand on that sub-heading. Then each sub-heading within a section should have the same structure and should support or build on the section heading.  And finally every section should break down, build on or support the overall focussing question of the document.

Thus to make sense of a document, it is useful to not only review the content, but to also review the structure of the document and the purpose of the different sections of the document.

Critics of “logical communication” will quite rightly make the point that a document can be logical, but boring, irrelevant and completely un-compelling. This is true and I should get to talking about it soon.

But before I do I wanted to talk about “Bad logic”. 

A lot of the communication I come across consists of the message “This is true so that is true” which is a logical enough structure.  But is the statement “This is the CFO’s most important project, so we need to deliver it on time” actually logical?

It may be logical to infer from this statement that we will get in trouble if we tell the CFO that her most important project is running late. But this presupposes that delivering it on time will meet the CFO’s needs.

For example, would she be happy if we deliver an embarrassing debacle exactly on time, or might she be a little happier if it was a week late and seen as a great success.

The statement also presupposes that being the CFO’s most important project (an often dubious claim) makes it important. But what if the CFO’s interests are not aligned with those of the customer, the shareholder or the law?

Many business communications rely on inferences (or even implied threats) that require the reader to fill the blanks in for themselves. This is good if you are a dodgy scam artist whose argument will not stand up to critical evaluation, but not so good if you want to convince cynical readers, present a valid case or make a judgement on someone else’s message.

So here is a list of common Fallacies, or flawed arguments. I hope it will be useful in reviewing your own work and in reviewing other people’s. 

Not all fallacies are linked the incorrect conclusions. But they have a habit of distracting us from the real argument. And they can make an argument seem sensible to those who already support it but flaky to those who oppose it.

So even if you think the conclusion is right you might find that using these fallacies inhibits your ability to convince you opponents, or enter a meaningful conversation with them. Similarly, if you look for these fallacies in the information you are given, you will often stumble upon the weak points in an argument, or the areas that the author did not really want to explore.

So how can we assess the overall logic of a document?

The first step is to look at the strategic fit that the document is designed to meet.

If you have access to the author of the document you can simply ask her what the purpose of the document is and who it is written for.  If you don’t have access to the author (or if you are writing the document yourself) then you will need to define these for yourself.

The focussing question

Different types of literature will have different aims, tones and styles.

Technical documents (and business writing generally) are designed to raise and answer a specific question. For example “how do I use this computer system” or “Should we invest $8m in this project”.

So a good technical document should make clear both:

• What question it is addressing; and
• What the answer or conclusion is.

In fact, everything in the document should support the reader in either accepting or rejecting the answer to the question the document addresses. This is one of the challenges I find when writing because I often have lots of “exciting” information to share and thus face a risk of rambling through distracting material.

I find the best way to start a document is therefore to be clear on my “focussing question”.  This is an idea taken from User Based Design and, as the name suggests, is designed to keep the author on track.  The focussing question takes the form of:

How can I communicate [my core message] to [my audience] so that [The document achieves an outcome]

For example this article might have address either of the following questions:

How can I communicate a way to assess the internal logic in documents to students of a class I ran so that they can refresh their understanding of the material we covered verbally.

or

How can I communicate a way to understand the meaning of a document to any reader of my blog so that they can better deal with the gumph that passes over their desk every day.

You can see from this that even this simple article could be written quite differently depending on my focus.

Where you are assessing a new document (or even a series of documents) then you can guess what question and audience they address and what outcome they hope to achieve when you first look at the document. Then you can re-assess this as you learn more about the document(s).

This will help you to assess the overall purpose of each document and also to help identify gaps, assumptions and risks where things do not seem to consistently address the questions you thought they did.

On the other hand, if you are writing your own document then becoming clear on the question you are addressing, the audience and the reason you want them to read the document will make your document far clearer.

A generic opening

Barbara Minto wrote an excellent book on creating useful and compelling reports and I took the following approach directly from it (Note that I read the 1987 version, but there is apparently a new version out).

All business documents should have an opening sentence or paragraph. Many writers think that the purpose of this is to entice the reader to read on. But Minto explains that the purpose of the opening is to both:

• Give the reader the context to understand the rest of the document; and
• Give them the chance to stop reading if either they are not interested in the topic.

So Minto suggests that each opening statement should take the form of “An existing situation; a complication and a resolution”. The existing situation should be a statement that the audience will accept as true, so that you have a starting point. The complication is the reason you are writing the document and the resolution is what the reader can expect to find in the document.

For example I might write “We held a class on writing (“the situation”) and I committed to provide more information on assessing the logic within documents (“the complication”) and so here it is (“the resolution”).

This structure gives the reader the context of where the document comes from and why they should read it (or skip it). Just as importantly the statement gives an anchor for the reader to use when making sense of the rest of the document.

So, you can start your document by writing out your focussing questions for the reader, or you can turn it into a simple “story structure” as suggested by Minto. I recommend the Minto approach because it is simple, clean and flows easily.

But what about other people’s documents? I recommend creating a simple story structure for each section of the document your are reviewing and then seeing if the stories connect to each other. In an excellent document, there will be one introduction for the whole document and each section will expand on that simple statement. In a really excellent document you will even notice that each section begins with the resolution of the last one and adds a complication that then gets resolved in the section, leading naturally to the next question, that in turn is addressed in the next section.

All of this means that:

• If you are writing a document, you can apply the approach shown here to produce a readable and useful document;
• If you are reading a single technical document you have a process for understanding the overall logic (or lack thereof) within the document; and
• When you find myriad documents that are supposed to relate to the same project you can assess whether they relate, whether they duplicate or contradict each other and how they all hang together generally.

My next article will drill further into creating a logical structure within the document, once you have a clear focussing question and know the “story” you are telling.

I promised a class that I would write something on “The Arenas of Change”, which is a theory about how teams interpret reality.

The theory is based on the idea that teams act on their interpretation of reality, rather than on reality itself. The “Arena” is the system within which the team interpret and act on information.  And this is made up of the team’s existing norms, ceremonies and other components of their culture.

By understanding the “arena” in which work and change are occurring, we can understand the way information will be processed and therefore the way the team will act on it.

One of the implications is that, even if my message is logical, the team might ignore it or re-interpret it to suit their current understanding of the world.

So I guess it would be logical to assume that this article will be on the Arenas of change: Unfortunately, I got distracted.

I ran a course on technical writing this week and we discussed the internal logic of a document. And I promised to write up a summary of our discussion on “logic”.

So now I am going to write a couple of articles meandering through both ideas.  In this one, I will simple state that:

When you write a document, you will naturally accept all the arguments that match your existing interpretation of reality. So you may well structure your message in a way you think is compelling; that completely fails to engage an audience who do not share your interpretation.

If you want to be a good technical writer you need to structure your document in a way that allows the reader to understand and challenge your logic.  This is true whether it is a business case, email, blog, telepathic communiqué, whatever.

If your reader agrees with what you are saying, he or she can thus skim to the end and agree that you are very intelligent. If they disagree, then your document should entice them to answer the questions they have as those questions come up. And if they reject your logic, then you should both be able to see the specific point of difference.

If this is logical, then let’s discuss how we can assess the logic of a statement.

Let’s assume I am running a popular training course. You have enrolled and I have sent you a course guide.  On page one is the statement

This is the address and room number for the course. Note that if you are not here by 9am, I will lock the door.

When I write this I think it is quite clear. But if you have ever known a first year philosophy student, then you know that any philosopher can deliver over 10 pages refuting every aspect of what I say.

Our friendly philosophy student might start asking “9am on which day; which door; is there really a door; Is it a course, or is it really an artificial construct, constraining our ability to truly face the abysmal nature of corporeal existence”. And I will respond with “please leave me alone now”.

Minding your P’s and Q’s

What our friendly philosophy student is learning to do is to start applying a simple formula called “If [P] then [Q]”, where P is the first part of the statement and Q is the conclusion.

Let’s look at my statement that “If you are not here by 9am then I will lock the door”.

What I want to say is that if you are there late (after 9am), you will not be able to come into the class until the next break (say 10:30).  But I am not actually saying this: I am forcing you to make this interpretation.

To test the statement I can ask “If [I lock the door at 9am] then [what]”. This reveals that my statement [P] does may not result in the conclusion that I want the reader to get.  In fact I might have meant that “If you are late the door will be locked, so don’t panic.  Just knock and I will let you in”.

Similarly, it is a fair assumption that if you come before 9am then the door will be open.  But in fact I might lock the door at 8:55am and when you complain I might say “I never said I wouldn’t lock it early, only that I would lock it at 9am if you are not there”.  This would be logically correct, even if it is also absurd or annoying.

The P-Q tests are all straight forward and can be applied to just about any claim.  All you do is see if the statement suggests any of these:

• P then Q: If P is true, then Q is true. (or it might be stated as “Q is true because P is true”);
• P then not Q: If P is true then Q is not true (similarly Q is not true if P is true).  For example “He knows how important it is, so he won’t be late” or “It is before 9 so the door will NOT be locked.;
• Not P then Q: If P is Not true then Q is true (similarly Q is true as long as P is not).  For example “If she was not at the meeting then she will assume we are working on option A” or “If it is not after 9am then the door will be open”; or
• Not P then not Q (similarly Not Q because not P): “If she is not a permanent employee she will not care about the project”, or if you are not there before 9am, the door will not be locked.

The approach is to simply find which of the above structures can be found in the statement.  If none can be found then you will need to list the assumptions that could make it true and see if these are valid (or add them).

If you do find one of the structures then you can simply start asking:

• Is P true?: Is it always true?; How do we know”? How would we know if it wasn’t? When is it not true? What does each noun and verb mean in P – could any be misinterpreted? If P is not always true, is it reasonable to assume P is true in this context?;
• Is the connection (then Q or then not Q) valid: Is it always the case? When is it not? What do I need to assume for it to be true? Do the nouns and verbs used in Q have the same meaning as when they were used in P?;
• What is not being said? Does it matter in this context? and
• What happens when I apply the other rules? (for example with the statement “if you are late then I will lock the door” – what happens if I am not late? Can I assume the door is unlocked?).

If you apply this kind of logic test sensibly you will realise that many of our communications fail the logic test. 

If you take it all the way then you will find yourself questioning whether doors exist, but if you use it reasonably you will be able to predict resistance and confusion in your communication.

So the good news is that you can improve the quality of the statements in your own communication and learn to find flaws and dodgy-ness in the communications you are the victim (audience?) of.

The bad news is that a series of statements that are perfectly logical can still be a meaningless message if they do not combine logically, or flow together, or have relevance for the document your are writing.

So grouping statements together logically will be the next blog.

If people classified their requirement as low,however, we would record the requirement in a long list, thank them for their idea and then never talk about it again.  If they classified it as medium then we promised get to it in “phase 2”, which meant after we ran out of money.

People learned over time to classify all of their requirements as high priority so we started adding new classifications like critical or super ultra high, which didn’t help at all.

Once I got involved in agile projects I came across a new approach - “Moscow”, which stands for Must Have, Should Have, Could Have or Won’t have.

This seems to work better but some teams are now changing Won’t Have to Wish to Have – ie might happen.  Unfortunately some are also starting to say Must Have will happen first and Should Have will happen later while Could Have will be in “Phase 2”. 

So here is my interpretation of how to use Moscow to prioritise ideas. It works for stories and also for any other kind of need.

First define the problem you have (or opportunity or grand idea), then come up with some success criteria, risks, potential market or users, a scope and so forth. Now add your more detailed needs, requirements or stories.

Now to prioritise them:

1. Must Have means we must have this as part of the solution. It is a compliance requirement or a given.  If this one requirement represents 90% of the cost of the solution we would either kill the project or include the requirement.
2. Should have means we would be embarrassed not to have it. We could technically produce the solution without it but people would be surprised. For example our competitors or existing product might already do this.
3. Could have means anything else we could do.  But this does not always mean low priority.  Our competitors are pretty much bound to deliver the same Must Have and Should Have ideas as us. But our selection of which Could Haves to include or exclude (or deliver later) will define our competitive advantage – this is what differentiates us from the others. This is also the delighters that Kano refers to in product design – the unexpected things that surprise and delight customers.
4. Won’t Have means this will not happen.  It might be technically impossible, a taboo for our organisation or out of scope. It does not mean “might happen or would be nice”.  It means if you want this included in your solution then kill our project and try again, or talk to us about what we can do instead. Having this honest conversation early in the piece can lead to better expectation setting, better allocation of resources and overall better projects. On top of this the Won’t Have can also provide a constraint or differentiator that provides competitive advantage. For example a won’t have on the iphone was a keyboard. It might have been easier to build a phone with one but a clear understanding of that constraint helped the team provide a fully functioning touch screen that needed to fully meet the user’s (probably unknown) needs.

Actually I am running a training course for some experienced facilitators and the course is about how to run workshops better.

So I have been reviewing conflict management techniques, ways of engaging un-engaged participants and issue resolution techniques.

Interestingly I have just noticed (yet again) that some of the workshop techniques (affinity diagrams and speed dating for example) work for both mitigating “strong personalities” and influencing the “passengers” to stop sitting back and start contributing.

Then I decided to throw in the question compass some abstract/concrete thinking and some fun things like options generators.

But now I have decided to lead with one of the least sensible seeming yet most useful techniques – the grammatically nonsensical question “how do you mean”.

Another facilitator taught me this one – it does not actually make sense so there is no right answer … which gets people to blurt out any answer .. which helps then explore what they really want to say.  I am not quite sure why but it frequently seems to work.

So – 10 experienced facilitators and the first and best tip I will give them is just to ask a dumb sounding question.

I will see how it goes.

The concept is that I will attack an argument by attacking its source (speaker).  So rather than saying I disagree with Fred because of a flaw in his argument, I either

• Explain that Fred is a bit of a wally and therefore not to be trusted in this matter.  The natural conclusion is therefore that we should ignore what he is saying; or
• I say that Fred is not one of us.  All people of a certain grouping (say agile project managers) believe that xyz, which is not what Fred is saying, so as agile project managers we should ignore him and believe (my argument).

The problem with the approach is that I have not assessed or commented on the quality of the point Fred is making, but rather distracted the group from doing so.

This turns out to be a great way to trick people if you want to be evil:

• As Australians we must believe that … (never mind why)
• Fred is from management, so of course he would say … (never mind if it makes sense)
• Waterfall projects are stupid and agile/lean/kanban projects are much better, so we must … (never mind why)

I have noticed a lot of people recently saying we should not do x because it is a waterfall approach to projects or we must do y because that is the agile approach.

The problem, as you can probably perceive, is that “waterfall projects” are not people and so “argumentum ad hominem” does not apply.  So I have invented a new term “argumentum ad waterfallium”.

Now if you are evil, you have a Latin (ish) term to apply to what you are doing.

Also – if you hear someone say “that was how things worked in waterfall so we can’t do it” or “In agile projects you need to have user stories so we need to …” you can respond automatically with “Waterfallias Argumentum ad”.

When they ask “What on earth do you mean by that?” – you can respond with “exactly what I am asking you”.

Just because waterfall is old and agile is cool does not mean we should or should not do something.  I have commented on this in a blurb I did to advertise a talk I am doing.

More widely though – you will often hear people in the workshops you run say that some must happen because “the CEO said it” or not happen because “that was the old way” or “that is what management want us to think”.

When you hear this (or do it yourself) remember – the source of the argument may make us question the motives for the argument but they do not impact the quality or the logic of the argument.

So whenever anyone uses this technique stop and ask them why they disagree with the argument.  You will often find that they struggle to answer that question without reverting to talking about the person rather than the argument.  Which means they are probably not considering the argument at all.

Of course, we like to call it robust discussion when we do so.  And of course I am generally facilitating rather than debating.

So I need to know how to keep conversations “robust enough to be valuable” and “respectful enough to build relationships rather than strain them”.  I therefore employ a range of conflict management techniques when facilitating other people’s discussions.

But sometimes my problem is that I am running a presentation or training course and someone objects to one of my points in a way that is (either by intent or accident) inflammatory and distracting.

For example I once said “blah blah, so if you want a team to be effective then you will need to empower people to make their own decisions”.

The response I got was “no you don’t.  The most effective teams I have been in have been driven by the top.  Everyone knows what they are meant to do and is moving in the same direction”.

Sadly this was a course on empowering teams through servant leadership as part of a change management initiative.  And the same guy, along with a couple of others were not keen on the whole change initiative.

I tried one technique that I often use when I have no idea what to say.  I asked “Can you expand on that?”.   Sadly he and his buddy did, explaining that strong leadership was necessary in tough times, which is where the company is and that therefore empowering people would typically lead to chaos.  So empowerment is what we always pretend we want, when we will really only ever reward managers who are tough and demanding and deliver at the expense of their people.

I could use open questions to further explore areas such as this, but we were already getting off track and at risk of running out of time.

Or I could have disputed what was said, since I had ample evidence to demonstrate that empowered teams are better.  But I feared that a couple of the participants would have dragged the debate on without even listening to my evidence – and some of the other participants were already over watching the show.

I thought of asking the rest of the group for their views, but I was already aware that this guy was both very senior and intimidating to some of the people there.

So I did what I probably should have done earlier.  I agreed specifically with the part that was true and utterly ignored the part that was not.

So I used a specific response someone taught me:

• To give him recognition I said “you are right”.  I would not have said this if he was completely wrong but in this case some of what was being said was true;
• But I don’t want to say that all the allegations are right and nor do I want to get into a long conversation of ones that are wrong.  So I specifically state what was right – “… strong leadership is important in a crisis.  People need to know what the goal is and they need confidence that the team is heading in the right direction”
• Then I brought the conversation back into where I wanted to be going with the course.  ”and that brings us to the next point …”.

This is an approach that works well in many different situations.  The key is to do each stage deliberately, concisely and in order:

1. Validate the person – say “you are right”
2. Specifically state the point that was correct, in one sentence (and completely ignore the exaggerations, giant leaps of logic, or controversial loaded questions).
3. Move on with the next sentence, either with a smooth link to the next topic, or even a clumsy “so now I would like to move onto …”.  (don’t say “does that make sense to you” or do anything else to reopen the conversation).

Practice the approach in safe environments and then use in in tough facilitations.  You will be surprised how well it works.