A compassionate reading of the Agile Manifesto

The four points of the Agile Manifesto read

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

which Agilists are at pains to point out does not mean: "no process, tools, contracts or plans", but -- as the manifesto goes on to say -- "while there is value in the items on the right, we value the items on the left more".

Now Olaf Lewitz has written a wonderful articulation of why the items on the left are more highly valued than those on the right:

Now, when I read the four statements from a compassionate point of view, having worked with hundreds of organisations where people cling to documentation, plans, contracts, processes and roles, I have a more holistic perspective.  

All of the things on the right are commonly used for three purposes:  

1. To hide lies, to avoid trust, 
2. To cover somebody’s ass (make sure it’s not my fault), and 
3. To defer acknowledgement of uncertainty. 

 The basic emotion behind all of these strategies is fear.

In other words: the items on the right give protect against negative outcomes and the related fears, while those on the left emphasise freedom and fruitfulness.

Depending on the situation one may need to play some defence, but the ideal is to move forward positively.

Scrum Master characteristics: From Good to Great

A fantastic blog post from Geoff Watts (inspectandadapt.com) enumerated desirable characteristics of good Scrum Masters, and how to take them to the next level in Towards a Definition of a Great Scrum Master. He used elements of the list in his book: Scrum Mastery: From Good to Great Servant-Leadership.

I've added categories and reformatted the original list for reference and readability:

Accountability
A good Scrum Master will hold team members to account if needed.
A great Scrum Master will hold the team to account for not holding team-mates to account.

Communication
A good Scrum Master encourages people to talk to each other.
A great Scrum Master encourages people to listen to each other.

A good Scrum Master says what needs to be said.

A great Scrum Master knows the power of silence.

Growth

A good Scrum Master helps every member of the team grow. 

A great Scrum Master encourages growth as a team. 

A good Scrum Master notices areas for improvement in the team. 

A great Scrum Master recognises & highlights strengths of the team for them to build on.

A good Scrum Master will coach the team to succeed. 

A great Scrum Master allows failure & encourages the team to learn from their mistakes (from Christina Ohanian).

A great Scrum Master is chosen by the team and Product Owner. 

When she's done all she can, it's time for another great Scrum Master (from Mike James).

Servant-Leadership

A good Scrum Master serves the team. 

A great Scrum Master fosters servant-leadership throughout the team. 

A good Scrum Master  is wary of influencing the team with what they say & do. 

A great Scrum Master can act normally and the team still make their own decisions.

A good Scrum Master will be indispensable to a team. 

A great Scrum Master will make themselves dispensable. And wanted.

A good Scrum Master asks to understand so they can serve. 

A great Scrum Master asks so the team understands and can serve itself.

Teamwork

A good Scrum Master helps teams use "yes, but" effectively. 

A great Scrum Master helps teams find more space for "yes, and".

A good Scrum Master facilitates co-operation between people. 

A great Scrum Master facilitates collaboration.

A good Scrum Master listens to what is said in the daily scrum. 

A great Scrum Master listens to what is not said in the daily scrum.

A good Scrum Master will help maintain team harmony. 

A great Scrum Master will guide a team through disharmony to reach a new level of teamwork.

Inspect and Adapt

A good Scrum Master helps a team meet their definition of done at the end of a sprint. 

A great Scrum Master helps a team extend their definition of done.

A good Scrum Master will help teams optimise their process. 

A great Scrum Master will help the team get past process.

A good Scrum Master helps the team hold a balanced retrospective. 

A great Scrum Master helps the team hold a focused retrospective.

Working with the Product Owner

A good Scrum Master facilitates the Sprint Review so the team gets to demo to the Product Owner . 

A great Scrum Master ensures that the PO is already aware so the demo can be for other stakeholders.

A good Scrum Master will be a bridge between the Product Owner and the team. 

A great Scrum Master will reduce the need for a bridge.

A good Scrum Master helps write stories so that the team is ready for sprint planning. 

A great Scrum Master helps the Product Owner make time before and during the Sprint to write and talk to the team.

Relationship to the larger organization

A good Scrum Master protects the team from distraction. 

A great Scrum Master finds the root cause of those distractions and eliminates them.

A good Scrum Master helps a Scrum team survive in an organisation's culture. 

A great Scrum Master helps change the culture so Scrum teams can thrive.

Good prioritizers; bad prioritizers

Even though there are many excellent techniques to prioritize a project or a backlog of work -- e.g. Story Mapping and MoSCoW -- it doesn't mean that it's easy.

In the various Agile approaches we usually split high-level prioritization and estimation between different roles: the stakeholder representative / customer or proxy / product owner (in Scrum) prioritizes the over-arching product backlog, while those who will do the work (typically a development or delivery team) estimate the cost.

Good prioritizers

• seek bang-for-buck
• own the project vision (or at least thoroughly understand the intent)
• strive to get the "must haves" down to around 20% of the backlog
• are great listeners who distil insights from a range of stakeholders
• expect to learn a lot along the way
• are privy to high enough level information to order the relative value of different pieces of work (quantification, e.g. cost-of-delay, would be even better!)

Bad prioritizers

• try to please everyone, and may be punished for "poor customer service"
• negotiate for as many "must haves" to be around 80% of the backlog
• think they know pretty much what's needed up-front
• struggle to synthesise a coherent picture from multiple stakeholders
• bargain with or push the delivery team
• may be exposed to too much detailed information

Entrepreneurs, especially those who are spending their own cash seem to have an advantage in terms of setting priorities because they are crafting their vision (although they may struggle with new information that challenges their pre-conceptions) and typically have both significant financial and emotional investment.

In an organizational context these advantages can be easily lost in the org chart.  We need to deliberately set up or carve out favourable conditions for our prioritizers to do a good job.  Then our Agile techniques can work wonderfully well.

My Talk on Design by Contract, Functional Contracts, Automated Testing and Static Typing

Last night I gave a well-received ;-) talk on Design by Contract at the Melbourne Functional (Programming) User Group.

Here are the slides:


For clojurists: James Sofra said afterwards that my talk reminded hime of this recent talk: Beyond Contracts.

Taiichi Ohno on Kaizen: Don't be a Fool!

According to the Kaizen Institute's blog, gemba panta rei, Taiichi Ohno once scolded a subordinate for following his instructions too closely:

You are a fool if you do just as I say. You are a greater fool if you don't do as I say. You should think for yourself and come up with better ideas than mine.

Some Reflections on Values

Here's a short quiz: Match the company to its corporate values:

• Companies: IBM, Toyota, Enron
• Values:
• A. Communication, Respect, Integrity, Excellence
• B. Challenge, Continuous Improvement, Go and See, Respect, Teamwork
• C. Client success, Meaningful Innovation, Trust and personal responsibility

[Answers are at the bottom of the post.]

At first blush they all sound pretty good.  After all, who doesn't love a manifesto, motherhood statements, and apple pie?

Systems of Values

In exploring examples of systems of values one might also examine

• Religious creeds: the 10 commandments, the Golden Rule, etc.
• Practical philosophies: the Agile manifesto, Scrum values, XP values
• Insights: e.g. Seligman on Happiness
• Your child's school's values
• Your personal values

It seems to me that value statements present us with at least three challenges:

1. Explicit values vs tacit values
2. The sheer quantity of possible values
3. What to do in the presence of conflicting values

1. Explicit vs tacit values

The war between appearance and substance, perception and reality is ongoing.  At their best explicit values can capture and promote positive ends by conserving what is good and guiding aspirations to do better.  At their worst explicit values devolve to propaganda, or as we say nowadays "spin".

Actions speak louder than words: An interesting exercise is matching actions to explicit values and taking the leftovers and framing tacit values that they match.

2. So many values ...

Consider needs:

In the face of so many possible and overlapping values consider starting with a lists of needs and selecting a small number that are personally relevant and reasonably independent.  The aforementioned needs have the following headings: connection, physical well-being, honesty, play, peace, autonomy, meaning.  The journey from a need to an espoused value is from necessity or desire to intended action.

Maslow's hierarchy of needs -- in ascending order: physiological, safety, love and belonging, esteem, self-actualization -- is another categorization worth examining.

Self-Determination Theory identifies Competence, Relatedness and Autonomy as key.  Dan Pink subs in Purpose for Relatedness and rebrands Competence to claim Autonomy, Mastery and Purpose as the keys to intrinsic motivation.

Some other interesting examples:

Tim Gallwey and co. explore the relationships between Performance, Learning and Enjoyment -- the vertices of the "PLE triangle" -- in The Inner Game of Stress. Organizations typically obsess over Performance (the obvious, outward objective) over the other two (internal, enabling objectives).  If performance is poor (or feels empty), try focussing on learning and/or enjoyment for a while. Performance may well improve as a consequence.

At Kaizen camp Melbourne 2013 Ian MacDonald's System Leadership Theory was touched on.  In MacDonald's schema: trust, fairness, honesty, dignity, courage, and love are identified as core values that manifest in different ways depending on the work culture of an organization.

Mix and match

I've identified some categories that I find useful for comparing systems of values:

• Ethics: Without ethics, who are we?
• Purpose: What am I trying to achieve?  Why does the organization exist?  What distinguishes it? 
• Performance: How am I /we doing?  Can we survive?  Can we excel?
• Learning: How do we improve and get better, especially in the face of threat and/or competition?
• Safety and enjoyment: Without safety, enjoyment, connection and fulfilment it will be difficult to thrive and survive long-term. [Oft-stated, sadly oft-ignored.] 

If an organization doesn't value all of these in some shape or form, that's going to leave a significant weakness.

3. Values Conflicts

Values Conflicts were the main subject of discussion in the values session at Kaizen Camp.  Discussion of examples suggested that values-conflicts may be over-diagnosed and clashes of competing self-interest under-diagnosed.

Nevertheless, the following commandments ;-) were suggested as guides to dealing with values conflicts:

1. Thou shalt not prostitute your values.
2. Thou shalt not retreat into learned helplessness.
3. Thou shalt understand alternative points of view.
4. Thou shalt understand operational imperatives.
5. In a difficult situation, thou shalt look for ways to achieve the deeper aim, while honouring your values.
6. Thou shalt not set up systems that reinforce bad behaviour.

The first five commandments boil down to understanding and sticking to your own values, while striving to understand other perspectives and systemic factors, and employing creativity to find win-wins. The last item is preventative.

The Value of Values

Your beliefs become your thoughts,
Your thoughts become your words,
Your words become your actions,
Your actions become your habits,
Your habits become your values,
Your values become your destiny.
― Gandhi

Quiz answer key: A = Enron, B = Toyota, C = IBM

Don Reinertsen's talk on Flow to the Limited WIP society - 8 Big Ideas

Don Reinertsen approves (and corrects!):

@agilejitsu Nice summary. To clarify: optimum failure rate in PD is frequently 50% (500k ppm); in 6 sigma mfg 0.00034 % (3.4 ppm). 10^5 diff
— Donald Reinertsen (@DReinertsen) July 31, 2013

Introduction

In Principles of Product Development Flow: Second Generation Lean Product Development Don Reinertsen takes an economic/scientific approach to adapting lean approaches from manufacturing to product development, including but not limited to software development.

In doing so, Reinertsen provides the beginnings of a scientific basis to many of the empirical practices of Agile.

Interview (24 mins):  http://www.youtube.com/watch?v=G-NbrISyfvM

Reinertsen says: "I believe that people in the Agile software space are doing a better job at using Lean in Product Development than companies that have forty years of experience with Lean Manufacturing, and that's because the Lean Manufacturing people have this toxic idea that variability is always bad and that it is feasible to eliminate variability.  In highly repetitive manufacturing processes there's some truth to that, and in manufacturing processes you don't need to innovate.  In Product Development you need to innovate in order to add value.  As a result, if you try to drive out variability you drive out all of the innovation!"

Several of the principles that apply in Lean Manufacturing

• Minimise variability
• FIFO queues
• Waste as enemy #1

have to change when the context shifts to Product Development.

In terms of applying Lean continuous flow to Software product Development Reinertsen is inclined towards Kanban-based systems over Theory of Constraints-based systems.  He recommends David J Anderson's book, Kanban: Successful Evolutionary Change for your Technology Business for elucidation.

Reinertsen's book is quite dense: a 600 page book compressed into just under 300 pages.  The density makes Don's summary talks worthwhile: he intends to write a 150 page version for non-Engineers "one day".

Summary of Reinertsen's talk to the Limited WIP society

• Melbourne, 11 December, 2012
• Some highlights from Reinertsen's two day workshop in an hour, plus questions
• Slides from a similar talk (lots of overlap): http://gotocon.com/dl/jaoo-aarhus-2010/slides/DonReinertsen_UnderstandingTheMagicOfLeanProductDevelopment.pdf

Eight big ideas:

1. Economics: use quantified models
2. Queues: the invisible enemy in product development
3. Variability: not the enemy: can profit from it (analogous to volatility in Financial Engineering)
4. Batch size: reducing batch size is the #1 way to reduce queues
5. WIP constraints: #2 way to reduce queues
6. Cadence: offers additional performance opportunities
7. Sequencing: additional gains available by prioritising Weighted Shortest Jobs First in queues (c.f. FIFO suffices in Manufacturing)
8. Feedback: fast feedback loops enable better economic performance in the presence of uncertainty.

Big idea #1: Economics

"Provide product developers with good decision support information to make economic decisions."

• What you get: "An apolitical framework from which to make multivariate trade-offs".  Enables effective decentralization of control.
• The alternative: "Get into ideological debates."

The #1 thing to quantify: cost of delay (e.g. $ lost per month of delay of project delivery)

How accurate do you need cost of delay to be?  Inter-rater reliability of individuals' intuition of cost-of-delay at the same organisation:

• Average: 50 : 1 spread
• Best: 10 : 1
• Worst: 200 : 1

"Any analysis beats intuition."

Implementation requires the construction of a quantitative model: in questioning Reinertsen said he can build this from the implicit P&L in a typical project business case, and that it's a lot less flaky than the ROI model, but he didn't give an example or recipe.

• Outline of a quantitative model from Jason Yip: http://www.slideshare.net/jchyip/estimating-cost-of-delay
• A qualitative (color-coded) approach: http://agileconsulting.blogspot.com.au/2011/03/using-cost-of-delay-functions-to.html

Big idea #2: Queues

"Invisible, unmanaged queues are the root cause of poor economic performance in Product Development."

Managing the invisible: make physical artifacts: e.g. Kanban boards, Scrum boards.

Why queues matter: queues

• increase cycle time
• lower quality
• increase variability
• increase risk
• raise overhead
• lower motivation

Just like a freeway at peak hour, running close to capacity blows out queues:

Clearly, minimising excess capacity drives costs way up.  To minimise total cost, the cost of delay needs to be explicitly known:

Incidentally, these U-shaped optimisations crop up a lot in Lean Product Development.

Big idea #3: Variability ain't all bad

There's upside, too.  C.f. Financial modelling: volatility implies opportunity (positive risk), as well as downside (negative risk).

This is different from manufacturing, where variability is all bad.

Big idea #4: Reduce batch size

"Halving batch sizes halves queues and halves cycle time."

Pros:

• Easy and cheap to implement
• Easy to reverse if there are problems

Big idea #5: Reduce cycle time by limiting WIP

"Reduce cycle time by limiting WIP"

Little's formula: Average cycle time = average WIP / average departure rate

Visual control systems (e.g. Kanban boards) help.  These, with cumulative flow diagrams, show queues in a way that Gantt charts don't.

At the project level, serializing projects (rather than running many in parallel) means that:

• early projects are finished faster, delivering value sooner
• deferred projects can benefit from: more time for requirements to mature; learnings from earlier, completed projects

Big idea #6: Cadence

"A synchronised cadence offers additional performance advantages."

Cadence:

• makes maximum wait times predictable
• reduces coordination costs
• enables smaller batch sizes

Replace asynchronous processes with synchronous processes.

Big idea #7: Flexible sequencing

"Proper sequencing offers additional gains."

C.f. Hospital emergency room: expedite the person having a heart attack!

In continuous flow, prioritising according to weighted shortest job first (WSJF = Cost of Delay / Time) can result in gains of up to 96%:

A qualitative approach to WSJF for the Scaled Agile Framework

Big idea #8: Feedback

"Fast feedback loops enable better economic performance in the presence of uncertainty."

"Optimum failure rate in product development is frequently 50% (500k ppm); in 6 sigma manufacturing 0.00034% (3.4 ppm)."

Example: Hospital waiting room

• Two patients enter with chest pains
• Heartburn or heart attack?
• What to do?

1. Buy information cheaply: find out if it's a heart attack (differential diagnosis / tests)
2. Stabilise the patient, then treat at leisure: this lowers the Cost of Delay.  C.f. Give the customer the most valuable feature(s) first, then take your time with refinements.