You want some Banana’s?

by Jon 12. October 2018 09:06
  • You want a standardised process for all teams to work to?
  • You want a standardise your skill set for your team members?
  • You appear to recruit people from similar backgrounds with similar past experiences. 

Standardisation adds risk, variety adds redundancy. The world is complex and changing, variety and options are stronger in a changing world. What outcome are you optimising, today or the future. If you want banana's for today that's cool you know what you want.. but have you considered perhaps you don't want banana's?

n.b don't get me wrong there a clear difference between standardised, standardised and standards. Respect for People in Lean (and also a nod to this in modern agile) appears to be the differentiator between them. Do you want some Banana's?



Bob the Scrum Builders

by Jon 12. September 2018 20:22

How would you rank the following teams?

This retro will help your teams explore some key agile concepts; value, focus, slack, commitment, respect and openness by helping your team members to think about a team from both the customers and a team member point of view. Using a different type of team such as a building team to the one your in will help conversations to flow, as there should be a higher level of psychological safety that will enable team members to think more deeply and share deeper insights. You can try this with your teams, product owners and managers to explore agile principles and open discussions around the relationships between values and trade-offs. I Hope you enjoy trying it as much as I did creating it and trying it out.

The Story

You are doing some building work at your house and you are given the details of 6 building squads who can do a week’s work on a fixed price contract. You the customer pays for one week’s work to the crew at the start of the week. You also have some feedback on how each of the crew’s work, the teams are as follows:

  • Team Mango: Under Promise, Deliver and then stop and go home early
  • Team Banana: Under Promise, Over Deliver what’s needed
  • Team Kiwi: Over Promise, deliver what we promised but in a rush resulting in low quality/botched work.
  • Team Apple: Under Promise and Over deliver including extra things we think are valuable
  • Team Carrot: Promise Exactly and Deliver Exactly as Promised
  • Team Cherry: Over Promise and Deliver some of it; the bits we can or prefer to do.


As appropriate during the retro try asking your team some of the following questions:

How would you rank the building squads from preferred to Least preferred?

Why do you think this team is preferable to that team?

Do all the crews exist, i.e. are any of the crew statements impossible?

What similarities are there between any of these crews and our team?

How is our team different to these teams, where would we be ranked?

What would you change (in the rankings) if we were thinking about the longer term?

Which team would you enjoy working in, and what effect would that have over the longer term?

How does trust fit in?


If your team selects Team Carrot (the ‘perfect’ team) as the top team you may want to ask some questions to explore perfection and the shadow side of perfection:

How realistic is it to expect a team to accurately estimate and deliver to an exact time estimate?


Ask your team summarise any surprising insights and if appropriate focus in to get some team agreements on things to change in response to the retro.

I ran this retro recently with one of my teams and though the insights by my team were interesting. Please drop me a tweet if you want to find out more, if you have any feedback or if anything in this post surprises you.


Agile | Scrum | Retro


I have been asked to increase a teams velocity

by Jon 9. August 2016 12:52

As a servant-leader or a scrum master how would you respond if a manager, product owner said your team 'mustgo faster?

Noel Baron posted this tweet a couple of days ago.

why is it important in an 'agile company' not to push for increased velocity or speed?

A scrum friendly response might be agile teams are self-organising the scrum guide says:

  • No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.
  • The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

These two statements are interesting, but they they don't explain themselves.  

Why is solely up to the development team, and why can nobody tell the Development Team how they go about progressing their work?

Efficiency is a eventual outcome of working in an Effective Team and Enjoying what you're doing as a team.  If the team start treating velocity as a target to improve on each sprint or scrum master pushes an agenda of doing more; you are compromising self organising nature of the team.  This will impact on the enjoyment and the effectiveness of as team team members start to work more individually accept technical debt and ignore the DOD.

Less enjoyment, less effective..... and less effecient over time.

Target Effectiveness and Enjoyment through working together and trying things out and see where that takes you :-)



Chaordic Leadership

by Jon 16. July 2016 22:56

Balanced Chaos and Order -> Creativity and Flow

Chaordic has been used to describe organisations that seek to balance chaos and order to produce an environment where flow and creativity can thrive. The term was coined by Dee Hock who founded VISA; a highly decentralized and highly collaborative organisation that worked with partner banks on a standards that enables the global credit card system to work.

Attributes of Chaordic Leadership

Dee describes the attributes of leaders in an organisation that is seeking to be chaordic:

  • Power: True power is never used. If you use power, you never really had it.
  • Human Relations: First, last, and only principle -- when dealing with subordinates, repeat silently to yourself, "You are as great to you as I am to me, therefore, we are equal." When dealing with superiors, repeat silently to yourself, "I am as great to me as you are to you, therefore we are equal."
  • Criticism: Active critics are a great asset. Without the slightest expenditure of time or effort, we have our weakness and error made apparent and alternatives proposed. We need only listen carefully, dismiss that which arises from ignorance, ignore that which arises from envy or malice, and embrace that which has merit.
  • Compensation: Money motivates neither the best people, nor the best in people. It can rent the body and influence the mind but it cannot touch the heart or move the spirit; that is reserved for belief, principle, and ethics.
  • Ego, Envy, Avarice, and Ambition: Four beasts that inevitably devour their keeper. Harbor them at your peril, for although you expect to ride on their back, you will end up in their belly.
  • Position: Subordinates may owe a measure of obedience by virtue of your position, but they owe no respect save that which you earn by your daily conduct. Without their respect, your authority is destructive.
  • Mistakes: Toothless little things, providing you can recognize them, admit them, correct them, learn from them, and rise above them. If not, they grow fangs and strike. Accomplishment: Never confuse activity with productivity. It is not what goes in your end of the pipe that matters, but what comes out the other end. Everything but intense thought, judgment, and action is infected to some degree with meaningless activity. Think! Judge! Act! Free others to do the same!
  • Hiring: Never hire or promote in your own image. It is foolish to replicate your strength. It is stupid to replicate your weakness. Employ, trust, and reward those whose perspective, ability and judgment are radically different from your own and recognize that it requires uncommon humility, tolerance, and wisdom.
  • Creativity: The problem is never how to get new, innovative thoughts into your mind, but how to get old ones out. Every mind is a building filled with archaic furniture. Clean out a corner of your mind and creativity will instantly fill it.
  • Listening: While you can learn much by listening carefully to what people say, a great deal more is revealed by what they do not say. Listen as carefully to silence as to sound.
  • Judgment: Judgment is a muscle of the mind developed by use. You lose nothing by trusting it. If you trust it and it is bad, you will know quickly and can improve it. If you trust it and it is consistently good, you will succeed, and the sooner the better. If it is consistently good and you don't trust it, you will become the saddest of all creatures; one who could have succeeded but followed the poor judgment of others to failure.
  • Leadership: Lead yourself, lead your superiors, lead your peers and free your people to do the same. All else is trivia.

Personally think the Dee's words resonate strongly in an Agile or Lean environment which seeks to achieve the same aims of Balancing Chaos and Order to help produce Creativity and Flow in a safe environment.



The Stacy Matrix

by Jon 3. April 2016 20:00

The journey from traditional ways of working using Project Management best practice and Waterfall to a world where we are using Agile, Scrum and kanban can be described with the Agreement & Certainty Matrix. This matrix was proposed by Ralph Stacey as part of his work on Complexity Science in the 1990's.

Our Industry and customers have moved from a place where we thought requirements and technology were fixed to a place where acknowledge things are complex rather than complicated and requirements and technology are less well known that we thought.

  • Simple products; are best designed with traditional project management/waterfall as requirements are known and the technology is also known.
  • Complicated products; you pretty know what you want and how you are going to do it could be created using waterfall or they could be evolved using agile.
  • Complex products; where both requirements are changing and evolving and the technology landscape is evolving require an empirical framework. We need to iterate and build on what we know and we welcome change and evolution.
  • Chaotic products; where we don’t know what the requirements are and we don’t know what tech we have to be more freeform. A very responsive product is better suited to kanban rather than scrum.


Powered by BlogEngine.NET
Original Design by Laptop Geek, Adapted by onesoft, and finally some tiny tweaks by JonAlb