When an Agile coach enters a new organization they have two basic problems: assess the state of the organization and apply counter measures. These are problems also face anyone is using Agile. This presentations provides a brief introduction to a set of principles and practices one Agile coach uses in tackling these two problems and which can be used by anyone in their workplace. This is a presentation given to the Toronto XP group on April 18th, 2011.

1. Spotting the Invisible 800,000 lb Gorilla Coaching Techniques to Help Your Team

2. Pre-production Old wine in new bottles Copyright (c) Norbert Winklareth 2

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

4. Copyright (c) Norbert Winklareth 4 No matter where you go, there you are I Love a Man in Uniform Understand the basics physics of knowledge work Life is NP-Hard Strong opinions, lightly held Education is a networking event The Rational Software Development Process: How and Why to Fake It People and Organizations can change Ripples are your legacy

5. 800,000 lb Invisible GorillaDemo Introducing the First Law of the Physics of Knowledge Work Copyright (c) Norbert Winklareth 5

6. The 800,000 lb Invisible Gorilla Law Copyright (c) Norbert Winklareth 6 Product Development is a Queuing System and it works independent of iterations Lead Time Cycle 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 Time Tasks 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)

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

8. Close encounters of the third kind There’s a new kid in town 8 Copyright (c) Norbert Winklareth

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

10.  Alignment Find out the purposes of the organization at as many levels as possible Continually draw connections between what they do and these purposes Watch 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 1 Copyright (c) Norbert Winklareth 10

11. Look at the boss’s shoes 11 Copyright (c) Norbert Winklareth Its their actions, not their words. Do they walk their talk?

12. Autonomous Reflex: Counting 12 Copyright (c) Norbert Winklareth Words/Phrases Delays – occurrence/length (especially small ones) Number of Tasks in a Column/Row Feedback loops – occurrence/length (Psssst: must be at least one per level) Handoffs, Defects, number of smiles Governance Policies – formal/informal ........

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

14. Polaczek-Khintchine Theorem Copyright (c) Norbert Winklareth 14 The higher the developer’s utilization the longer the average waiting time for tasks

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

16. 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? 16 Copyright (c) Norbert Winklareth

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

18. No Models, No Deep Learning 18 Copyright (c) Norbert Winklareth Does the organization create and use models? Have you developed a model of the organization?

19. 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? 19 Copyright (c) Norbert Winklareth

20. 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? 20 Copyright (c) Norbert Winklareth

21. Dead ducks never pull it together Some organizations are not ready to change with your assistance at this time Recognize this and act accordingly 21 Copyright (c) Norbert Winklareth

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

23. Up the down staircase Its countermeasures all the way down! 23 Copyright (c) Norbert Winklareth

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

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

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

27. Garbage In, Garbage Out Not enough effort is spent on understanding and clarifying inputs Help them to do so Copyright (c) Norbert Winklareth 27

28. Cake Slices 28 Copyright (c) Norbert Winklareth Risk reducer & information arrival rate accelerator on steroids Slices do not have to be uniform

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

30. Use Inclines Copyright (c) Norbert Winklareth 30 Rider: 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.

31. Context is the biggest stick 31 Copyright (c) Norbert Winklareth genchigenbutsu To a person carrying a hammer the world looks like a nail Every organization and its people are unique.

32. Copyright (c) Norbert Winklareth 32

33. Appendix – Little’s Law Copyright (c) Norbert Winklareth 33

35. λ= average number of items arriving per unit time, and

36. 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.

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

38. References Copyright (c) Norbert Winklareth 36

39. 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. SayaSone 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 37 Copyright (c) Norbert Winklareth

40. 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 HenrikKniberg & MattiasSkarin, 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 Copyright (c) Norbert Winklareth 38

41. 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 Copyright (c) Norbert Winklareth 39

42. 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

43. Copyright © 2007-8, Norbert Winklareth 41 Additional References continued 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 GojkoAdzic Teamwork is an Individual Skill: Getting Your Work Done When Sharing Responsibility by Christopher M. Avery

44. Copyright © 2007-8, Norbert Winklareth 42 Additional References continued 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)

45. Additional References continued 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 Copyright (c) Norbert Winklareth 43

46. Additional References continued 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 OLavMaassen 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 Copyright (c) Norbert Winklareth 44

47. Additional References continued 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 PhillRozenzweig 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 Copyright (c) Norbert Winklareth 45

48. 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/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 Copyright (c) Norbert Winklareth 46

49. Additional References continued 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 Copyright (c) Norbert Winklareth 47

52. Action Learning by Chris Argyris

53. The Shibumi Strategy by Matthew E. May

54. Getting Results the Agile Way by J. D. MeierCopyright (c) Norbert Winklareth 49