Iron Lean

 From a Lean perspective, is ironing the bottom 1/4 of your shirt a waste? (The part that gets tucked in).

***

The MoSCoW Unprioritisation Prioritisation Technique

The most popular requirements prioritisation technique in the universe is called MoSCoW.

The acronym stands for:

M - Must have

S - Should have

C - Could have

W - Won't have

The problem with MoSCoW is that it's really not a prioritisation technique.  

It's just a priority labelling technique.  All it does is let you label the requirements.  It doesn't tell you which of the requirements ought to be labelled 'Must have' and which ones ought to be labelled 'Won't have'.

MoSCoW is no different from using colour codes on requirements such as: green for must haves, blue for should haves, yellow for could haves, and red for won't haves. 

***

The Road Not Taken Because You Shouldn't Take It

If you don't know where you're going, it doesn't matter how far ahead you are.

***

Mini Book Reviews

Reframing Organizations: Artistry, Choice, and Leadership 4th Ed.   Lee G. Bolman and Terrence E, Deal.

Recommends viewing organisations through 4 frames or lenses: factory, family, jungle, and temple, to get a better understanding of how an organisation works and avoid being clueless about problems in the organisation.  ‘Reframing’ is about dismantling existing frames of mind about the organisation and rebuilding into a new frame.

Scenario-Driven Planning: Learning to Manage Strategic Uncertainty. Nicholas C. Georgantzas and William Acar. (1995).

Scenario-planning is a management tool against ‘dogmatism’ and ‘fads’. It enable articulation and validation of mental models about the future. The book is full of practical and diverse examples, plus a plethora of references to relevant literature.

“The Fox” by Frederick Forsyth

“The Fox” is the latest thriller from perhaps my favourite fiction writer.

What I like most about Forsyth's works is the sense of being educated while reading. He brings the readers to part of the world they have never been, and likely will never be.  I don't just mean physical places in the world, but also 'worlds' like the world of spies and the echelons of power.

This time Forsyth brings together the themes of cyberattacks, North Korean nuclear aspirations, Russian leadership thuggery, and hopes for a geopolitical control of the West, special forces of the West, the East, and the middle East.

In his trademark style, Forsyth includes lots of insider information in his story.  This is mostly what draws me to his works – I subconsciously feel (unjustifiably I know) that fiction is a waste of time and find it hard to justify spending time on them when there’s so much non-fiction around.  (I don't have the same problem spending hours watching fiction TV shows and movies, though).

Compared to his original masterpieces,  “The Jackal”, and “The Dogs of War”, this one feels thin.  The characters are cardboard depth (though that is somewhat usual for all of Forsyth’s works).  The story was too neat, too easy, too fantasy-like, almost like a Disney movie for grown-ups.  The young hacker was too skilled, his special forces security too lucky, the closure of the story too convenient.

Nevertheless, it was still a page-turner for me. I had to resist flipping to the last chapter to see how it all ends.

The other best thing about Forsyth’s works is his technique of letting us into the thinking and decision-making of the primary characters.  While their personalities were cardboard cutouts, getting inside the minds of these first rate political thinkers were 90% of the enjoyment.

Readers who have a technical background in cyber-security are well-advised to suspend disbelief.  This is where the facts fall really short and the limits of Forsyth’s technical knowledge appears shallow, maybe even uninformed. Hopefully, his knowledge is more authoritative in areas where I don't know much about, and the non-fiction aspects of this book are not fiction.

Book Review of ‘Fundamentals of Project Performance Measurement’

This short book (119 pages) covers the basics of measuring project progress via earned value management.

The author (Robert R. Kemps) argues that you cannot measure project progress simply by monitoring cost expenditures versus budgeted expenditures. If your actual expenses by a certain date is less than the budgeted expenses by that date, that information doesn’t really tell you anything – are spending less than expected or are you simply running behind schedule? Adding the work completed to the measure gives you better understanding: you can now tell why your project is spending less than expected. It could be because, some of the work that was expected to being had not yet begun.

Kemps also underlines the importance of technical performance as the third measure to factor in. Just because work is reported as being complete does not mean it is complete.  Unfortunately there is not much information in the book as to how to measure technical performance besides ensuring that it is tracked.

A baseline is important, the author asserts, because without it, the integrity of the project progress measures (and by extension, project management), is at risk, because readjustments to cost and schedule and technical performance leaves no trace behind.

It lists neither references nor a bibliography.

Recommendation: A basic book on earned value measurement, useful as an introductory reference for both the motivation behind earned value and how to do it.

No Such Thing as ‘The Four Agile Values’

Everyone should just stop referring to ‘The Four Agile Values’ or ‘The Four Values of the Agile Manifesto” 

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: 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.

Why? Because this so-called 'The 4 Agile Values' does not exist.

Consider the following:

1. There Are 8 Values Listed in the Manifesto

If by ‘4 Values’ is meant the following: 

1. ‘Individuals and interactions’, 
2. ‘Working software’, 
3. ‘Customer collaboration’, and 
4. ‘Responding to change’

Then please note we have eight values listed (not four): 4 values on the left plus 4 values on the right, making a total of eight values.

The manifesto affirms: 'there is value' to the four items on the right. So if you regard the items on the left as values, you need to regard the items on the right as values too. We value family over careers. Does that mean we don’t value careers?

The authors did not put worthless items on the right: 'Customer collaboration over cheating the customer'

They also did not say 'Individuals and interactions, etc' trump everything (see point number 3 below).

2. The 'Values' Are Merely Trade-off Preferences

If you consider the 4 values to be the 4 listed earlier, then please note that these are simply statements of relative value, not of highest value.  Hence, they do not merit the definite article 'The'.

Read them as saying, “between responding to change and following a plan, we regard the former more important”. (How much more important is not indicated).

The signatories shared interesting trade-offs they have ‘come to value’, trade-offs that upend (what they consider) the normative trade-offs in software development. No suggestion is made that these are the only trade-offs they value, nor even the most important ones, but merely the tradeoffs that make their approach different. 

3. The Principles List Even More, Even More Important Agile Values

The Twelve Principles call out other ideas important to the signatories (and by extension to Agile development): customer satisfaction, continuous delivery, frequent delivery, motivated individuals, support, trust, face-to-face conversation, measure of progress, working software, sustainable development, technical excellence, good design, simplicity, best architecture, best requirements, best designs, team effectiveness. Some of these arguably carry equal, arguably even more, weight to the ‘4 Agile Values’.

The first sentence of the manifesto also mentions two ideas valued by the signatories: 'doing it' and 'helping others do it'

4 The Manifesto Never Talks About 'Values'

The manifesto never uses the word 'value' as used in the phrase 'The 4 Agile Values'. In that phrase, 'Value' is a noun that means 'something intrinsically desirable'. These refer to ideas like 'emotional intelligence', or 'integrity'.

The manifesto says that the signatories have come to ‘value’ A over B. The word ‘value’ here is not the same word as the noun. This verb means ‘to consider highly’, as used in 'we value efficiency'. Valuing something does not necessarily turn that thing into a 'value': I have come to value good quality leather shoes over cheap shoes, but good quality leather shoes isn't one of my values.

The manifesto uses 'value' as a noun when it speaks of "there is value..." but this noun carries the different meaning of 'having worth' (the opposite of the word 'worthless'), like gold has value to a jeweler, but dirt does not.

In short, the manifesto never talks of 'values'.

5. Surely There Are Now More Than Four!

The verb tenses in “we are uncovering…” and “we have come to value” indicate that the list is preliminary, and describes a point-in-time state of affairs that is hoped will continue onward. It would be surprising (shocking) if they meant for it to be the final uncovered preferences for all time (or even for a few years).

Referring to 'The 4 Agile Values' after so many years is a serious indictment of the movement, for it means no new Agile-specific value trade-off have been ‘uncovered’ since 2001. (Calling them ‘The Original 4 Agile Values’ would still be wrong -- see points 1 and 2).

Fnally, referring to 'The 4 Agile Values' surrounds them with an aura of being untouchable and unchange-able.

So please stop talking about 'The 4 Agile Values', because doing so promotes misunderstanding and inhibits uncovering of new 'better ways of developing software'