spotting the 800000_ lb_invisible_gorilla

Spotting the Invisible 800,000 lb Gorilla

Coaching Techniques to Help Your Team

Copyright (c) Norbert Winklareth 2

PRE-PRODUCTIONOld wine in new bottles


Paul’s First Law of Consulting

• Everyone has biases!• Everyone has biases!• Everyone has biases!


I Love a Man in Uniform

The Rational Software Development Process: How and Why to Fake It

Education is a networking event

Strong opinions, lightly held

No matter where you go, there you are

Life is NP-Hard

Ripples are your legacy

Understand the basics physics of knowledge work

People and Organizations can change


800,000 LB INVISIBLE GORILLA DEMO

Introducing the First Law of the Physics of Knowledge Work


The 800,000 lb Invisible Gorilla Law

Tasks to be done.

Active Tasks (WIP)

Completed Tasks, (the purpose of the system is to complete as many of these as possible per unit of time)

Lead Time

Cycle Time (CT)

Product Development is a Queuing System and it works independent of iterations

Little’s Law applies and it says: LT = WIP / CT **

Easiest way to reduce LT is to reduce number of Active Tasks, which improves Total Lead Time

** This formulation is incorrect, the main relationship is correct, see appendix for further discussion.


Simplest Thing to Do: Reduce WIP

• Not easy!– It is counter intuitive to most people, and– It is very hard to say in organizations, not now

• Don’t and nothing else will be successful in the long run– Too much WIP drowns all other improvements

• All Agile Methods, either implicitly or explicitly reduce WIP– This is one of the main reasons for their success


CLOSE ENCOUNTERS OF THE THIRD KIND

There’s a new kid in town


Breaking the Ice• Pun intended!

– (They need your help in changing their existing habits)• Trust is the ice breaker

– Happens incrementally over the group; in quantum jumps with individuals

– Best way to start earning it, is to help them make visible progress• Doesn’t matter how small it is, so long as it is visible

– Remember you also need trust between team members and between the team and the rest of the organization

• Accompany members to meetings with other groups and departments– The fact of your presence is an ice breaker– Be ready to initiate meetings


Alignment

1. Find out the purposes of the organization at as many levels as possible

2. Continually draw connections between what they do and these purposes

1. Watch how people respond. Do they agree, disagree or are they indifferent?

2. Do their actions match the purposes, especially when their words do?

3. Do they keep their nose to the grindstone and their eyes on the horizon?

4. Repeat from 1


Look at the boss’s shoes

Its their actions, not their words.Do they walk their talk?


Autonomous Reflex: CountingWords/Phrases

Number of Tasks in a Column/Row

Handoffs, Defects, number of smiles

Delays – occurrence/length

(especially small ones)

Feedback loops – occurrence/length

(Psssst: must be at least one per level)

Governance Policies – formal/informal........


Over-packing is everywhere

• Crammed sprint commitments, release plans• Not measuring and using velocity• No slack in the system• Not accounting for production issues• My standard question for Iteration based development:

In the last 4 sprints, how many did you have with zero carry over?

– Over 80% say none or never or one• It reduces predictability, productivity, morale and trust


Polaczek-Khintchine Theorem

0.0

5.0

10.0

15.0

20.0

25.0

30.0

35.0

45% 50% 55% 60% 65% 70% 75% 80% 85% 90% 95%

The higher the developer’s utilization the longer the average waiting time for tasks


Improv Quotient

• Do the people bounce around stuff or is it all just straight forward and routine handling of stuff?

• Spontaneous or constantly on quard?• Do people build on others work?• Is everything at the same priority level?• Are they just floating whether the currents take

them or navigating the rapids?• Are they constantly looking over their shoulders, to

see if they are being watched?


Loop Spotting: Single & Double

Do they have feedback loops?Are they just positive or negative ones?Do they have enough of them?

Are they learning/improving within the system?

Are they learning/improving the nature of the system?


Necessity is the Mother of Invention

Does the organization just complain about constraints?

OrDo they do nothing about them?

OrDo they work to remove them or use

them as design constraints?


No Models, No Deep Learning

Does the organization create and use models?

Have you developed a model of the organization?


Change is always non-linear• Do they understand that:

– A small change can cause enormous ripple effects– Large changes can have very little effect– And visa-a-versa– And its effect, big or small, will always be non-uniform over the domain– And it will happen, so do they expect it?– And more often then not, unknowable– Do they understand that this variability, this risk, this unknown aspect,

is the economic potential of the future?• Do they account for this when they imagine future states?

– Do they imagine future states?• What are they doing to learn from it?


10 years or 1 year 10 times

• Need 10,000 hours or 10 years to become an expert and it must be of different experiences

• One way to think about what this means is:– The more expertise one has, the more

comfortable you are with the occurrence of variation within the domain• Either way, it is just a habit

• How many and how deeply entrenched are their and your habits?


Dead ducks never pull it together

• Some organizations are not ready to change with your assistance at this time

• Recognize this and act accordingly


You will miss something big & obvious

• When it does, Don’t Panic!• Collectively learn from it• Forewarned is forearmed• So enlist their aid– Reduces the chance of it occurring– And they are also forearmed


UP THE DOWN STAIRCASEIts countermeasures all the way down!


No juggling, no learning

• If a person is not doing it, they are not learning it

• Incorporate this into your training, or better yet train them where and while they are doing the work, I sometimes call it Just-in-Training

• Turns out that doing a physical activity while trying to absorb information improves retention


Sam’s Law: Fail fast/Succeed slowly

• The faster the feedback back loop the better the learning– Introduce counter measures ASAP, even hour 1

• Learning takes time and is non-uniform in how it occurs– Repetition of successes reinforces positive habits


Little deltas win in the long run

• Power of small numbers repeated many times, like water flowing, is the most powerful force we know of

• Most effective at making sustained improvements in social orgabnizations


Garbage In, Garbage Out

Not enough effort is spent on understanding and clarifying

inputsHelp them to do so


Cake Slices

Slices do not have to be uniform

Risk reducer &

information arrival rate accelerator on steroids


Keep your hands in your pocket• You are there to help them change, not do their jobs• Show them once, if needed• Stop the line when a problem occurs that you judge they

need to address– Not all problems need to be addressed when they occur

• Focus them on the problem• Ideally they should figure out and implement a solution• Help them catch themselves when they don’t use their

solution• Repeat, repeat, repeat, repeat, repeat ...


Use InclinesRider: reason, will, rational mind. Has limited capacity, i.e. can be used up.

Elephant: passion, unconscious mind, emotions and habits. Overpowers the rider quite easily. Naturally follows gravity.

Positive inclines work best.Reinforce good behavior.

Minimize penalizing bad behavior.


Context is the biggest stick

genchi

genbutsu

To a person carrying a

hammer the world looks

like a nail Every organization and its people are unique.


APPENDIX – LITTLE’S LAW


When I gave this presentation on April 19th, 2011 to the Toronto XP group, Michael Sahota, challenged the formula I used as being Little’s Law, LT = WIP / CT. I got this formulation from Michael L. George, James Works * Kimberly Watson-Hemphill’s book, Fast Innovation, Page 51 and from Peter Abilla’s blog post, http://www.shmula.com/littles-law-for-product-development/263/. His formulation comes from the work of Hoop and Spearman, Factory Physics. I was unable to demonstrate at the time that the variation I showed was correct, however I promised that I would. This is appendix is the result of my effort to do so.John Little who proved this law in 1961, using the formulation stated by Philip Morse in his 1958 book, Queues, Inventories and Maintenance, which is L = λW where:• L = average number of items in the queuing system,• λ= average number of items arriving per unit time, and• W = average waiting time in the system for an itemFrom a product development point of view we are more concerned with completion rates, and flow time or time in the system, then in arrival rates. Hoop and Spearman, prove the connection between arrival rates and completion rates, for a discussion of this see, Stephen C. Graves excellent overview written with John Little, "Little’s Law," (with J. D. C. Little), Chapter 5 in Building Intuition: Insights from Basic Operations Management Models and Principles, http://web.mit.edu/sgraves/www/papers/Little's%20Law-Published.pdf, Page 92.

http://www.shmula.com/littles-law-for-product-development/263/

http://web.mit.edu/sgraves/www/papers/Little's%20Law-Published.pdf


Hoop and Spearman’s work leads to the formulation: Flow Time = Inventory (WIP) / Throughput. Throughput is often referred to as Average Completion Rate, which I called Cycle Time, but that inference is wrong is they have a reciprocal relationship: Throughput = 1 / Cycle Time. Based on this much closer reading, my formulation of Little’s Law is not correct, in that I have incorrectly used the term Cycle Time when I should have used Average Completion Rate.That said, the relationship between WIP and Flow Time, what I called Lead Time, is correct and is the main point I am trying to get across at that point. Thus I stand by my three assertions made in that section of the presentation:1. Too much WIP is the major problem for most organizations in the industry and that

most people cannot see it2. Until you have WIP under control all other changes will be swamped by it3. It is easier to reduce WIP then it is to reduce the Average Completion Rate I have chosen to leave the formula in the text as that is how I presented it, although when I present the formula in future I will no longer use Cycle Time. My thanks to, Michael Sahota, for challenging me on my incorrect formulation. Any errors that remain are mine and not the authors I referenced.


REFERENCES


Main References• The Happiness Hypothesis by Jonathan Haidt• Switch by Dan & Chip Heath• The Rational Design Process: How and Why to Fake It by David Parnas,

http://web.cs.wpi.edu/~gpollice/cs3733-b05/Readings/FAKE-IT.pdf• The Principles of Product Development Flow by Donald G. Reinertsen• Fast Innovation by Michael George• Drive: The Surprising Truth about What Motivates Us by Daniel H. Pink• Coaching Agile Teams by Lyssa Adkins• Lean Architecture for Agile Software Development by James O. Coplien & Gertrud

Bjornvig• The Business Value of Agile Software Methods by Dr. David F. Rico, Dr. Hasan H.

Saynai & Dr. Saya Sone• A Cool Neurological Explaination for the Power of Small Wins, by Robert Sutton,

http://bobsutton.typepad.com/my_weblog/2011/04/a-cool-neurological-explaination-for-the-power-of-small-wins.html

http://web.cs.wpi.edu/~gpollice/cs3733-b05/Readings/FAKE-IT.pdf





Additional References• Scrumban: Essays on Kanban Systems for Lean Software Development by Cory Ladas• Scaling Lean & Agile Development by Craig Larman & Bas Vodde• Kanban and Scrum: making the best of both by Henrik Kniberg & Mattias Skarin,

– http://www.infoq.com/minibooks/kanbanscrum-minibook• Leading Lean Software Development: Results Are not the Point by Mary and Tom

Poppendieck• Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway,

Jim Trott and Guy Beaver• Kanban: Successful Evolutionary Change for Technology Organizations by David

Anderson• Executive Control of Cognitive Processes in Task Switching

(http://tinyurl.com/223723) by Joshua S. Rubinstein, David E. Meyer and Jeffrey E. Evans

• Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results by Mike Rother


Additional References continued• http://www.limitedwipsociety.org/

– This site for trying to build up the value of the underlying principles and have it separate from the brand Kanban

• http://www.kanban101.com/– A site to make it easy to get started with Kanban

• http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html– Very good and broad introduction to Kanban and the rational for it from an agile product design

specialist• http://availagility.co.uk/2008/10/28/kanban-flow-and-cadence/

– Very good overview on these three points• http://www.infoq.com/presentations/kanban-at-sep

– Good presentation on how Kanban is tool for team based process change• http://leanandkanban.wordpress.com/

– David Joyce’s blog about his experiences at BBC• http://www.agilemanagement.net/index.html

– David Anderson’s site, unfortunately he is not blogging much these days• http://miami2009.leanssc.org/speaker-presentations/

– Videos and presentation from First Kanban conference

http://www.limitedwipsociety.org/

http://www.kanban101.com/

http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html

http://availagility.co.uk/2008/10/28/kanban-flow-and-cadence/

http://www.infoq.com/presentations/kanban-at-sep

http://leanandkanban.wordpress.com/

http://www.agilemanagement.net/index.html

http://miami2009.leanssc.org/speaker-presentations/

Copyright © 2007-8, Norbert Winklareth 40

Additional References continued

• Agile Estimating and Planning by Mike Cohn• Agile Management for Software Engineering by David Anderson• Agile Software Development: 2nd edition by Alistair Cockburn• Are iterations hazardous to your project? by Alistair Cockburn (

http://alistair.cockburn.us/index.php/Are_iterations_hazardous_to_your_project%3F)

• Balancing Agility and Discipline: A Guide for the Perplexed by Barry Boehm, Richard Turner

• Critical Chain Project Management by Lawrence P. Leach• Developing Products in Half the Time: 2nd Edition by Preston G.

Smith, Donald G. Reinertsen

http://alistair.cockburn.us/index.php/Are_iterations_hazardous_to_your_project?





• Effective Risk Management: Some Keys to Success by Edmund H. Conrow• Executive Control of Cognitive Processes in Task Switching (

http://www.apa.org/journals/releases/xhp274763.pdf) by Joshua S. Rubinstein, David E. Meyer and Jeffrey E. Evans

• Fast Innovation by Michael George• HP gets 3.4x productivity gain from Agile Management techniques (

http://www.agilemanagement.net/Articles/Weblog/HPgets3.4xproductivitygai.html) by David Anderson

• Implementing Lean Software Development by Mary and Tom Poppendieck• Fit for Developing Software: Framework for Integrating Tests, Rick

Mugridge and Ward Cunningham• Bridging the Communication Gap: Specification by example and agile

acceptance testing by Gojko Adzic• Teamwork is an Individual Skill: Getting Your Work Done When Sharing

Responsibility by Christopher M. Avery

http://www.apa.org/journals/releases/xhp274763.pdf

http://www.agilemanagement.net/Articles/Weblog/HPgets3.4xproductivitygai.html

http://www.agilemanagement.net/Articles/Weblog/HPgets3.4xproductivitygai.html



• Kanban in Action (http://www.agilemanagement.net/Articles/Weblog/KanbaninAction.html) by David Anderson

• Lean Software Development by Mary and Tom Poppendieck• Software By Numbers by Mark Denne, Jane Cleland-Huang• The Elegant Solution by Matthew E. May• The ROI from Software Quality by Khaled El Eman• The Toyota Product Development System by James M.

Morgan, Jeffrey K. Lisker• Wideband delphi (

http://en.wikipedia.org/wiki/Wideband_delphi)

http://en.wikipedia.org/wiki/Wideband_delphi



• Agile Estimating and Planning by Mike Cohn• Agile Management for Software Engineering by David Anderson• Agile Software Development: 2nd edition, Alistair Cockburn• Agile Retrospectives: Making Good Teams Great, Esther Derby and Diana Larsen• Agile Testing: A Practical Guide for Testers and Agile Teams, Lisa Crispin and Janet

Gregory• Balancing Agility and Discipline: A Guide for the Perplexed by Barry Boehm,

Richard Turner• Critical Chain Project Management by Lawrence P. Leach• Developing Products in Half the Time: 2nd Edition by Preston G. Smith, Donald G.

Reinertsen • Effective Risk Management: Some Keys to Success by Edmund H. Conrow



• Agile_BA_Requirements.yahoogroups.co.uk– mailing list, haven't seen much traffic on this but Chris Matts is a member and that is a very good thing

• http://decision-coach.com/– Chris Matts and OLav Maassen blog, although they do not blog much, their existing articles are very

good• http://www.infoq.com/articles/real-options-enhance-agility

– an article on Real Options by the above two, I recommend reading the comments as well. Understanding and using this greatly benefits prioritization.

• http://www.infoq.com/presentations/software-with-real-options– ice presentation by those two and yes I am a big fan ;-)

• http://www.limitedwipsociety.org/2009/05/27/feature-injection/– interesting view on using pull at the feature level and the importance of specifying testing criteria on information

discovery, read the set of comics, they are very good and informative

• http://www.agileproductdesign.com/blog/ – This is Jeff Patton's site, he does a lot of work consulting on Product Design and Requirements, sadly not writing very

much these days, however these two articles are very applicable to your interests:

• http://www.agilemodeling.com/essays/businessAnalysts.htm– Scott Ambler's view on integrating BA into Agile Development Teams

http://decision-coach.com/

http://www.infoq.com/articles/real-options-enhance-agility

http://www.limitedwipsociety.org/2009/05/27/feature-injection/

http://www.agilemodeling.com/essays/businessAnalysts.htm



• Good Boss, Bad Boss by Robert I. Sutton• Hard Facts, Dangerous Half-Truths, and Total Nonsense: Profiting from

Evidence-based Management by Jeffrey Pfeffer & Robert I. Sutton• The Halo Effect: ... and the Eight Other Business Delusions That

Deceive Managers by Phill Rozenzweig• Herding Cats blog, http://herdingcats.typepad.com/my_weblog/• Organizational Patterns of Software Development by James O. Coplien

& Neil B. Harrison• Succeeding with Agile: Software Development Using Scrum by Mike

Cohen• Freedom from Command & Control: Rethinking Management for Lean

Service by John Seddon

http://herdingcats.typepad.com/my_weblog/



• "That’s the Way We (Used to) Do Things Around Here“by Jeffrey Schwartz, Pablo Gaito, and Doug Lennick, http://www.strategy-business.com/article/11109– Requires free login

• Stop Blaming Your Culture by Jon Katzenbach and Ashley Harshak, http://www.strategy-business.com/article/11108– Requires free login

• The Art of Software Development by James Shore & Shane Warden• Thinking in Systems: A Primer by Donella H. Meadows• The Design of Business by Roger Martin• The Opposable Mind by Roger Martin• Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the

Enterprise by Dean Leffinger• Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects by Johanna

Rothman– this is very good introduction on how to manage multiple projects, the portfolio, it is important for

BA's, in fact everyone, to understand the larger processes they are working in and her advice on doing Portfolio Management is very good

http://www.strategy-business.com/article/11109

http://www.strategy-business.com/article/11108



• http://searchsoftwarequality.techtarget.com/news/2240033170/Get-to-know-your-business-analysts - survey on what business analyst do

• http://cdn.pols.co.uk/papers/cutterbusinessvaluearticle.pdf - nice little article on business value.

• User Stories Applied by Mike Cohen - excellent and helpful book• Agile Product Management with Scrum - Roman Pichler• Scrum Product Ownership - Robert Galen• Agile Excellence for Product Owners - Greg Cohen• http://ebgconsulting.com/articles.php#agile - articles from a company

that specializes in Agile Analysis and Requrements• http://www.bridging-the-gap.com/how-i-became-an-agile-business-

analyst/ - always nice to have a first hand account of someone learning how to do something and here it is one becoming a Agile BA



• http://www.agiledad.com/Documents/BAWhitepaperJune.pdf - another similar view• Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale

Scrum, Craig Larman and Bas Vodde• The new user story backlog is a map (http://tinyurl.com/3mpuot), Jeff Patton• The product owner and the product-shaped hole (http://tinyurl.com/dyyn33), Jeff

Patton• The Toyota Product Development System by James M. Morgan, Jeffrey K. Lisker • Wideband Delphi (http://tinyurl.com/2wclrp)• xUnit Test Patterns: Refactoring Test Code, Gerard Meszaros• The Three Pillars of Executive Support for Agile Adoption

(http://tinyurl.com/cteab5), Esther Derby• Lean Software Development by Mary and Tom Poppendieck • Refactoring Databases: Evolutionary Database Design, Scott W. Ambler and Pramod

J. Sadalage



• HP gets 3.4x productivity gain from Agile Management techniques (http://tinyurl.com/dfyswo) by David Anderson

• Action Learning by Chris Argyris• The Shibumi Strategy by Matthew E. May• Getting Results the Agile Way by J. D. Meier