Spotting the 800000_ lb_invisible_gorilla

Spotting the Invisible 800,000 lb GorillaCoaching Techniques to Help Your Team

Pre-productionOld wine in new bottlesCopyright (c) Norbert Winklareth2

Paul’s First Law of ConsultingEveryone has biases!Everyone has biases!Everyone has biases!3Copyright (c) Norbert Winklareth

Copyright (c) Norbert Winklareth4No matter where you go, there you areI Love a Man in UniformUnderstand the basics physics of knowledge workLife is NP-HardStrong opinions, lightly heldEducation is a networking eventThe Rational Software Development Process: How and Why to Fake ItPeople and Organizations can changeRipples are your legacy

800,000 lb Invisible GorillaDemoIntroducing the First Law of the Physics of Knowledge WorkCopyright (c) Norbert Winklareth5

The 800,000 lb Invisible Gorilla LawCopyright (c) Norbert Winklareth6Product Development is a Queuing System and it works independent of iterationsLead TimeCycle Time (CT)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 TimeTasks to be done.Completed Tasks, (the purpose of the system is to complete as many of these as possible per unit of time)** This formulation is incorrect, the main relationship is correct, see appendix for further discussion.Active Tasks (WIP)

Simplest Thing to Do: Reduce WIPNot easy!It is counter intuitive to most people, andIt is very hard to say in organizations, not nowDon’t and nothing else will be successful in the long runToo much WIP drowns all other improvementsAll Agile Methods, either implicitly or explicitly reduce WIPThis is one of the main reasons for their successCopyright (c) Norbert Winklareth7

Close encounters of the third kindThere’s a new kid in town8Copyright (c) Norbert Winklareth

Breaking the IcePun intended!(They need your help in changing their existing habits)Trust is the ice breakerHappens incrementally over the group; in quantum jumps with individualsBest way to start earning it, is to help them make visible progressDoesn’t matter how small it is, so long as it is visibleRemember you also need trust between team members and between the team and the rest of the organizationAccompany members to meetings with other groups and departmentsThe fact of your presence is an ice breakerBe ready to initiate meetings9Copyright (c) Norbert Winklareth

 AlignmentFind out the purposes of the organization at as many levels as possibleContinually draw connections between what they do and these purposesWatch how people respond. Do they agree, disagree or are they indifferent?Do their actions match the purposes, especially when their words do?Do they keep their nose to the grindstone and their eyes on the horizon?Repeat from 1Copyright (c) Norbert Winklareth10

Look at the boss’s shoes11Copyright (c) Norbert WinklarethIts their actions, not their words.Do they walk their talk?

Autonomous Reflex: Counting12Copyright (c) Norbert WinklarethWords/PhrasesDelays – occurrence/length(especially small ones)Number of Tasks in a Column/RowFeedback loops – occurrence/length(Psssst: must be at least one per level)Handoffs, Defects, number of smilesGovernance Policies – formal/informal........

Over-packing is everywhereCrammed sprint commitments, release plansNot measuring and using velocityNo slack in the systemNot accounting for production issuesMy 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 oneIt reduces predictability, productivity, morale and trust13Copyright (c) Norbert Winklareth

Polaczek-Khintchine TheoremCopyright (c) Norbert Winklareth14The higher the developer’s utilization the longer the average waiting time for tasks

Improv QuotientDo 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?15Copyright (c) Norbert Winklareth

Loop Spotting: Single & DoubleDo 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?16Copyright (c) Norbert Winklareth

Necessity is the Mother of InventionDoes the organization just complain about constraints?OrDo they do nothing about them?OrDo they work to remove them or use them as design constraints?17Copyright (c) Norbert Winklareth

No Models, No Deep Learning18Copyright (c) Norbert WinklarethDoes the organization create and use models?Have you developed a model of the organization?

Change is always non-linearDo they understand that:A small change can cause enormous ripple effectsLarge changes can have very little effectAnd visa-a-versaAnd its effect, big or small, will always be non-uniform over the domainAnd it will happen, so do they expect it?And more often then not, unknowableDo 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?19Copyright (c) Norbert Winklareth

10 years or 1 year 10 timesNeed 10,000 hours or 10 years to become an expert and it must be of different experiencesOne 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 domainEither way, it is just a habitHow many and how deeply entrenched are their and your habits?20Copyright (c) Norbert Winklareth

Dead ducks never pull it togetherSome organizations are not ready to change with your assistance at this timeRecognize this and act accordingly21Copyright (c) Norbert Winklareth

You will miss something big & obviousWhen it does, Don’t Panic!Collectively learn from itForewarned is forearmedSo enlist their aidReduces the chance of it occurringAnd they are also forearmed22Copyright (c) Norbert Winklareth

Up the down staircaseIts countermeasures all the way down!23Copyright (c) Norbert Winklareth

No juggling, no learningIf a person is not doing it, they are not learning itIncorporate this into your training, or better yet train them where and while they are doing the work, I sometimes call it Just-in-TrainingTurns out that doing a physical activity while trying to absorb information improves retention24Copyright (c) Norbert Winklareth

Sam’s Law: Fail fast/Succeed slowlyThe faster the feedback back loop the better the learningIntroduce counter measures ASAP, even hour 1Learning takes time and is non-uniform in how it occursRepetition of successes reinforces positive habits25Copyright (c) Norbert Winklareth

Little deltas win in the long runPower of small numbers repeated many times, like water flowing, is the most powerful force we know ofMost effective at making sustained improvements in social orgabnizations26Copyright (c) Norbert Winklareth

Garbage In, Garbage OutNot enough effort is spent on understanding and clarifying inputsHelp them to do soCopyright (c) Norbert Winklareth27

Cake Slices28Copyright (c) Norbert WinklarethRisk reducer &information arrival rate accelerator on steroidsSlices do not have to be uniform

Keep your hands in your pocketYou are there to help them change, not do their jobsShow them once, if neededStop the line when a problem occurs that you judge they need to addressNot all problems need to be addressed when they occurFocus them on the problemIdeally they should figure out and implement a solutionHelp them catch themselves when they don’t use their solutionRepeat, repeat, repeat, repeat, repeat ...29Copyright (c) Norbert Winklareth

Use InclinesCopyright (c) Norbert Winklareth30Rider: 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 stick31Copyright (c) Norbert WinklarethgenchigenbutsuTo a person carrying a hammer the world looks like a nailEvery organization and its people are unique.

Copyright (c) Norbert Winklareth32

Appendix – Little’s LawCopyright (c) Norbert Winklareth33

Copyright (c) Norbert Winklareth34When 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.

Copyright (c) Norbert Winklareth35Hoop 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:Too much WIP is the major problem for most organizations in the industry and that most people cannot see itUntil you have WIP under control all other changes will be swamped by itIt 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.

ReferencesCopyright (c) Norbert Winklareth36

Main ReferencesThe Happiness Hypothesis by Jonathan HaidtSwitch by Dan & Chip HeathThe Rational Design Process: How and Why to Fake It by David Parnas, http://web.cs.wpi.edu/~gpollice/cs3733-b05/Readings/FAKE-IT.pdfThe Principles of Product Development Flow by Donald G. ReinertsenFast Innovation by Michael GeorgeDrive: The Surprising Truth about What Motivates Us by Daniel H. PinkCoaching Agile Teams by Lyssa AdkinsLean Architecture for Agile Software Development by James O. Coplien & Gertrud BjornvigThe Business Value of Agile Software Methods by Dr. David F. Rico, Dr. Hasan H. Saynai & Dr. SayaSoneA 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.html37Copyright (c) Norbert Winklareth

Additional ReferencesScrumban: Essays on Kanban Systems for Lean Software Development by Cory LadasScaling Lean & Agile Development by Craig Larman & Bas VoddeKanban and Scrum: making the best of both by HenrikKniberg & MattiasSkarin,http://www.infoq.com/minibooks/kanbanscrum-minibookLeading Lean Software Development: Results Are not the Point by Mary and Tom PoppendieckLean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Jim Trott and Guy BeaverKanban: Successful Evolutionary Change for Technology Organizations by David AndersonExecutive Control of Cognitive Processes in Task Switching (http://tinyurl.com/223723) by Joshua S. Rubinstein, David E. Meyer and Jeffrey E. EvansToyota Kata: Managing People for Improvement, Adaptiveness and Superior Results by Mike RotherCopyright (c) Norbert Winklareth38

Additional References continuedhttp://www.limitedwipsociety.org/This site for trying to build up the value of the underlying principles and have it separate from the brand Kanbanhttp://www.kanban101.com/A site to make it easy to get started with Kanbanhttp://www.agileproductdesign.com/blog/2009/kanban_over_simplified.htmlVery good and broad introduction to Kanban and the rational for it from an agile product design specialisthttp://availagility.co.uk/2008/10/28/kanban-flow-and-cadence/Very good overview on these three pointshttp://www.infoq.com/presentations/kanban-at-sepGood presentation on how Kanban is tool for team based process changehttp://leanandkanban.wordpress.com/David Joyce’s blog about his experiences at BBChttp://www.agilemanagement.net/index.htmlDavid Anderson’s site, unfortunately he is not blogging much these dayshttp://miami2009.leanssc.org/speaker-presentations/Videos and presentation from First Kanban conferenceCopyright (c) Norbert Winklareth39

Copyright © 2007-8, Norbert Winklareth40Additional References continuedAgile Estimating and Planning by Mike CohnAgile Management for Software Engineering by David AndersonAgile Software Development: 2nd edition by Alistair CockburnAre 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 TurnerCritical Chain Project Management by Lawrence P. LeachDeveloping Products in Half the Time: 2nd Edition by Preston G. Smith, Donald G. Reinertsen

Copyright © 2007-8, Norbert Winklareth41Additional References continuedEffective Risk Management: Some Keys to Success by Edmund H. ConrowExecutive 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. EvansFast Innovation by Michael GeorgeHP gets 3.4x productivity gain from Agile Management techniques (http://www.agilemanagement.net/Articles/Weblog/HPgets3.4xproductivitygai.html) by David AndersonImplementing Lean Software Development by Mary and Tom PoppendieckFit for Developing Software: Framework for Integrating Tests, Rick Mugridge and Ward CunninghamBridging the Communication Gap: Specification by example and agile acceptance testing by GojkoAdzicTeamwork is an Individual Skill: Getting Your Work Done When Sharing Responsibility by Christopher M. Avery

Copyright © 2007-8, Norbert Winklareth42Additional References continuedKanban in Action (http://www.agilemanagement.net/Articles/Weblog/KanbaninAction.html) by David AndersonLean Software Development by Mary and Tom PoppendieckSoftware By Numbers by Mark Denne, Jane Cleland-HuangThe Elegant Solution by Matthew E. MayThe ROI from Software Quality by Khaled El EmanThe Toyota Product Development System by James M. Morgan, Jeffrey K. LiskerWideband delphi (http://en.wikipedia.org/wiki/Wideband_delphi)

Additional References continuedAgile Estimating and Planning by Mike CohnAgile Management for Software Engineering by David AndersonAgile Software Development: 2nd edition, Alistair CockburnAgile Retrospectives: Making Good Teams Great, Esther Derby and Diana LarsenAgile Testing: A Practical Guide for Testers and Agile Teams, Lisa Crispin and Janet GregoryBalancing Agility and Discipline: A Guide for the Perplexed by Barry Boehm, Richard TurnerCritical Chain Project Management by Lawrence P. LeachDeveloping Products in Half the Time: 2nd Edition by Preston G. Smith, Donald G. ReinertsenEffective Risk Management: Some Keys to Success by Edmund H. ConrowCopyright (c) Norbert Winklareth43

Additional References continuedAgile_BA_Requirements.yahoogroups.co.ukmailing list, haven't seen much traffic on this but Chris Matts is a member and that is a very good thinghttp://decision-coach.com/Chris Matts and OLavMaassen blog, although they do not blog much, their existing articles are very goodhttp://www.infoq.com/articles/real-options-enhance-agilityan 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-optionsice 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 informativehttp://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.htmScott Ambler's view on integrating BA into Agile Development TeamsCopyright (c) Norbert Winklareth44

Additional References continuedGood Boss, Bad Boss by Robert I. SuttonHard Facts, Dangerous Half-Truths, and Total Nonsense: Profiting from Evidence-based Management by Jeffrey Pfeffer & Robert I. SuttonThe Halo Effect: ... and the Eight Other Business Delusions That Deceive Managers by PhillRozenzweigHerding Cats blog, http://herdingcats.typepad.com/my_weblog/Organizational Patterns of Software Development by James O. Coplien & Neil B. HarrisonSucceeding with Agile: Software Development Using Scrum by Mike CohenFreedom from Command & Control: Rethinking Management for Lean Service by John SeddonCopyright (c) Norbert Winklareth45

Additional References continued"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/11109Requires free loginStop Blaming Your Culture by Jon Katzenbach and Ashley Harshak, http://www.strategy-business.com/article/11108Requires free loginThe Art of Software Development by James Shore & Shane WardenThinking in Systems: A Primer by Donella H. MeadowsThe Design of Business by Roger MartinThe Opposable Mind by Roger MartinAgile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise by Dean LeffingerManage Your Project Portfolio: Increase Your Capacity and Finish More Projects by Johanna Rothmanthis 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 goodCopyright (c) Norbert Winklareth46

Additional References continuedhttp://searchsoftwarequality.techtarget.com/news/2240033170/Get-to-know-your-business-analysts - survey on what business analyst dohttp://cdn.pols.co.uk/papers/cutterbusinessvaluearticle.pdf - nice little article on business value.User Stories Applied by Mike Cohen - excellent and helpful bookAgile Product Management with Scrum - Roman PichlerScrum Product Ownership - Robert GalenAgile Excellence for Product Owners - Greg Cohenhttp://ebgconsulting.com/articles.php#agile - articles from a company that specializes in Agile Analysis and Requrementshttp://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 BACopyright (c) Norbert Winklareth47

Spotting the 800000_ lb_invisible_gorilla

More Related Content

Similar to Spotting the 800000_ lb_invisible_gorilla

Similar to Spotting the 800000_ lb_invisible_gorilla (20)

Recently uploaded

Recently uploaded (20)

Spotting the 800000_ lb_invisible_gorilla