Your SlideShare is downloading. ×
0
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Spotting the 800000_ lb_invisible_gorilla
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Spotting the 800000_ lb_invisible_gorilla

1,941

Published on

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 …

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.

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,941
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
23
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Spotting the Invisible 800,000 lb Gorilla<br />Coaching Techniques to Help Your Team<br />
  • 2. Pre-production<br />Old wine in new bottles<br />Copyright (c) Norbert Winklareth<br />2<br />
  • 3. Paul’s First Law of Consulting<br />Everyone has biases!<br />Everyone has biases!<br />Everyone has biases!<br />3<br />Copyright (c) Norbert Winklareth<br />
  • 4. Copyright (c) Norbert Winklareth<br />4<br />No matter where you go, there you are<br />I Love a Man in Uniform<br />Understand the basics physics of knowledge work<br />Life is NP-Hard<br />Strong opinions, lightly held<br />Education is a networking event<br />The Rational Software Development Process: How and Why to Fake It<br />People and Organizations can change<br />Ripples are your legacy<br />
  • 5. 800,000 lb Invisible GorillaDemo<br />Introducing the First Law of the Physics of Knowledge Work<br />Copyright (c) Norbert Winklareth<br />5<br />
  • 6. The 800,000 lb Invisible Gorilla Law<br />Copyright (c) Norbert Winklareth<br />6<br />Product Development is a Queuing System and it works independent of iterations<br />Lead Time<br />Cycle Time (CT)<br />Little’s Law applies and it says: LT = WIP / CT **<br />Easiest way to reduce LT is to reduce number of Active Tasks, which improves Total Lead Time<br />Tasks to be done.<br />Completed Tasks, (the purpose of the system is to complete as many of these as possible per unit of time)<br />** This formulation is incorrect, the main relationship is correct, see appendix for further discussion.<br />Active Tasks (WIP)<br />
  • 7. Simplest Thing to Do: Reduce WIP<br />Not easy!<br />It is counter intuitive to most people, and<br />It is very hard to say in organizations, not now<br />Don’t and nothing else will be successful in the long run<br />Too much WIP drowns all other improvements<br />All Agile Methods, either implicitly or explicitly reduce WIP<br />This is one of the main reasons for their success<br />Copyright (c) Norbert Winklareth<br />7<br />
  • 8. Close encounters of the third kind<br />There’s a new kid in town<br />8<br />Copyright (c) Norbert Winklareth<br />
  • 9. Breaking the Ice<br />Pun intended!<br />(They need your help in changing their existing habits)<br />Trust is the ice breaker<br />Happens incrementally over the group; in quantum jumps with individuals<br />Best way to start earning it, is to help them make visible progress<br />Doesn’t matter how small it is, so long as it is visible<br />Remember you also need trust between team members and between the team and the rest of the organization<br />Accompany members to meetings with other groups and departments<br />The fact of your presence is an ice breaker<br />Be ready to initiate meetings<br />9<br />Copyright (c) Norbert Winklareth<br />
  • 10.  Alignment<br />Find out the purposes of the organization at as many levels as possible<br />Continually draw connections between what they do and these purposes<br />Watch how people respond. Do they agree, disagree or are they indifferent?<br />Do their actions match the purposes, especially when their words do?<br />Do they keep their nose to the grindstone and their eyes on the horizon?<br />Repeat from 1<br />Copyright (c) Norbert Winklareth<br />10<br />
  • 11. Look at the boss’s shoes<br />11<br />Copyright (c) Norbert Winklareth<br />Its their actions, not their words.<br />Do they walk their talk?<br />
  • 12. Autonomous Reflex: Counting<br />12<br />Copyright (c) Norbert Winklareth<br />Words/Phrases<br />Delays – occurrence/length<br />(especially small ones)<br />Number of Tasks in a Column/Row<br />Feedback loops – occurrence/length<br />(Psssst: must be at least one per level)<br />Handoffs, Defects, number of smiles<br />Governance Policies – formal/informal<br />........<br />
  • 13. Over-packing is everywhere<br />Crammed sprint commitments, release plans<br />Not measuring and using velocity<br />No slack in the system<br />Not accounting for production issues<br />My standard question for Iteration based development:<br />In the last 4 sprints, how many did you have with zero carry over?<br />Over 80% say none or never or one<br />It reduces predictability, productivity, morale and trust<br />13<br />Copyright (c) Norbert Winklareth<br />
  • 14. Polaczek-Khintchine Theorem<br />Copyright (c) Norbert Winklareth<br />14<br />The higher the developer’s utilization the longer the average waiting time for tasks<br />
  • 15. Improv Quotient<br />Do the people bounce around stuff or is it all just straight forward and routine handling of stuff?<br />Spontaneous or constantly on quard?<br />Do people build on others work?<br />Is everything at the same priority level?<br />Are they just floating whether the currents take them or navigating the rapids?<br />Are they constantly looking over their shoulders, to see if they are being watched?<br />15<br />Copyright (c) Norbert Winklareth<br />
  • 16. Loop Spotting: Single &amp; Double<br />Do they have feedback loops?<br /> Are they just positive or negative ones?<br /> Do they have enough of them?<br />Are they learning/improving within the system?<br />Are they learning/improving the nature of the system?<br />16<br />Copyright (c) Norbert Winklareth<br />
  • 17. Necessity is the Mother of Invention<br />Does the organization just complain about constraints?<br />Or<br />Do they do nothing about them?<br />Or<br />Do they work to remove them or use them as design constraints?<br />17<br />Copyright (c) Norbert Winklareth<br />
  • 18. No Models, No Deep Learning<br />18<br />Copyright (c) Norbert Winklareth<br />Does the organization create and use models?<br />Have you developed a model of the organization?<br />
  • 19. Change is always non-linear<br />Do they understand that:<br />A small change can cause enormous ripple effects<br />Large changes can have very little effect<br />And visa-a-versa<br />And its effect, big or small, will always be non-uniform over the domain<br />And it will happen, so do they expect it?<br />And more often then not, unknowable<br />Do they understand that this variability, this risk, this unknown aspect, is the economic potential of the future?<br />Do they account for this when they imagine future states?<br />Do they imagine future states?<br />What are they doing to learn from it?<br />19<br />Copyright (c) Norbert Winklareth<br />
  • 20. 10 years or 1 year 10 times<br />Need 10,000 hours or 10 years to become an expert and it must be of different experiences<br />One way to think about what this means is:<br />The more expertise one has, the more comfortable you are with the occurrence of variation within the domain<br />Either way, it is just a habit<br />How many and how deeply entrenched are their and your habits?<br />20<br />Copyright (c) Norbert Winklareth<br />
  • 21. Dead ducks never pull it together<br />Some organizations are not ready to change with your assistance at this time<br />Recognize this and act accordingly<br />21<br />Copyright (c) Norbert Winklareth<br />
  • 22. You will miss something big &amp; obvious<br />When it does, Don’t Panic!<br />Collectively learn from it<br />Forewarned is forearmed<br />So enlist their aid<br />Reduces the chance of it occurring<br />And they are also forearmed<br />22<br />Copyright (c) Norbert Winklareth<br />
  • 23. Up the down staircase<br />Its countermeasures all the way down!<br />23<br />Copyright (c) Norbert Winklareth<br />
  • 24. No juggling, no learning<br />If a person is not doing it, they are not learning it<br />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<br />Turns out that doing a physical activity while trying to absorb information improves retention<br />24<br />Copyright (c) Norbert Winklareth<br />
  • 25. Sam’s Law: Fail fast/Succeed slowly<br />The faster the feedback back loop the better the learning<br />Introduce counter measures ASAP, even hour 1<br />Learning takes time and is non-uniform in how it occurs<br />Repetition of successes reinforces positive habits<br />25<br />Copyright (c) Norbert Winklareth<br />
  • 26. Little deltas win in the long run<br />Power of small numbers repeated many times, like water flowing, is the most powerful force we know of<br />Most effective at making sustained improvements in social orgabnizations<br />26<br />Copyright (c) Norbert Winklareth<br />
  • 27. Garbage In, Garbage Out<br />Not enough effort is spent on understanding and clarifying inputs<br />Help them to do so<br />Copyright (c) Norbert Winklareth<br />27<br />
  • 28. Cake Slices<br />28<br />Copyright (c) Norbert Winklareth<br />Risk reducer <br />&amp;<br />information arrival rate accelerator on steroids<br />Slices do not have to be uniform<br />
  • 29. Keep your hands in your pocket<br />You are there to help them change, not do their jobs<br />Show them once, if needed<br />Stop the line when a problem occurs that you judge they need to address<br />Not all problems need to be addressed when they occur<br />Focus them on the problem<br />Ideally they should figure out and implement a solution<br />Help them catch themselves when they don’t use their solution<br />Repeat, repeat, repeat, repeat, repeat ...<br />29<br />Copyright (c) Norbert Winklareth<br />
  • 30. Use Inclines<br />Copyright (c) Norbert Winklareth<br />30<br />Rider: reason, will, rational mind. Has limited capacity, i.e. can be used up.<br />Elephant: passion, unconscious mind, emotions and habits. Overpowers the rider quite easily. Naturally follows gravity.<br />Positive inclines work best.<br />Reinforce good behavior.<br />Minimize penalizing bad behavior. <br />
  • 31. Context is the biggest stick<br />31<br />Copyright (c) Norbert Winklareth<br />genchigenbutsu<br />To a person carrying a hammer the world looks like a nail<br />Every organization and its people are unique.<br />
  • 32. Copyright (c) Norbert Winklareth<br />32<br />
  • 33. Appendix – Little’s Law<br />Copyright (c) Norbert Winklareth<br />33<br />
  • 34. Copyright (c) Norbert Winklareth<br />34<br />When I gave this presentation on April 19th, 2011 to the Toronto XP group, , 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.<br />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:<br /><ul><li> L = average number of items in the queuing system,
  • 35. λ= average number of items arriving per unit time, and
  • 36. W = average waiting time in the system for an item</li></ul>From 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, &quot;Little’s Law,&quot; (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&apos;s%20Law-Published.pdf, Page 92. <br />
  • 37. Copyright (c) Norbert Winklareth<br />35<br />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. <br />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.<br />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:<br />Too much WIP is the major problem for most organizations in the industry and that most people cannot see it<br />Until you have WIP under control all other changes will be swamped by it<br />It is easier to reduce WIP then it is to reduce the Average Completion Rate<br /> 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, , for challenging me on my formulation. Any errors that remain are mine and not the authors I referenced.<br />
  • 38. References<br />Copyright (c) Norbert Winklareth<br />36<br />
  • 39. Main References<br />The Happiness Hypothesis by Jonathan Haidt<br />Switch by Dan &amp; Chip Heath<br />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<br />The Principles of Product Development Flow by Donald G. Reinertsen<br />Fast Innovation by Michael George<br />Drive: The Surprising Truth about What Motivates Us by Daniel H. Pink<br />Coaching Agile Teams by Lyssa Adkins<br />Lean Architecture for Agile Software Development by James O. Coplien &amp; Gertrud Bjornvig<br />The Business Value of Agile Software Methods by Dr. David F. Rico, Dr. Hasan H. Saynai &amp; Dr. SayaSone<br />37<br />Copyright (c) Norbert Winklareth<br />
  • 40. Additional References<br />Scrumban: Essays on Kanban Systems for Lean Software Development by Cory Ladas<br />Scaling Lean &amp; Agile Development by Craig Larman &amp; Bas Vodde<br />Kanban and Scrum: making the best of both by HenrikKniberg &amp; MattiasSkarin,<br />http://www.infoq.com/minibooks/kanbanscrum-minibook<br />Leading Lean Software Development: Results Are not the Point by Mary and Tom Poppendieck<br />Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Jim Trott and Guy Beaver<br />Kanban: Successful Evolutionary Change for Technology Organizations by David Anderson<br />Executive Control of Cognitive Processes in Task Switching (http://tinyurl.com/223723) by Joshua S. Rubinstein, David E. Meyer and Jeffrey E. Evans<br />Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results by Mike Rother<br />Copyright (c) Norbert Winklareth<br />38<br />
  • 41. Additional References continued<br />http://www.limitedwipsociety.org/<br />This site for trying to build up the value of the underlying principles and have it separate from the brand Kanban<br />http://www.kanban101.com/<br />A site to make it easy to get started with Kanban<br />http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html<br />Very good and broad introduction to Kanban and the rational for it from an agile product design specialist<br />http://availagility.co.uk/2008/10/28/kanban-flow-and-cadence/<br />Very good overview on these three points<br />http://www.infoq.com/presentations/kanban-at-sep<br />Good presentation on how Kanban is tool for team based process change<br />http://leanandkanban.wordpress.com/<br />David Joyce’s blog about his experiences at BBC<br />http://www.agilemanagement.net/index.html<br />David Anderson’s site, unfortunately he is not blogging much these days<br />http://miami2009.leanssc.org/speaker-presentations/<br />Videos and presentation from First Kanban conference<br />Copyright (c) Norbert Winklareth<br />39<br />
  • 42. Copyright © 2007-8, Norbert Winklareth<br />40<br />Additional References continued<br />Agile Estimating and Planning by Mike Cohn<br />Agile Management for Software Engineering by David Anderson<br />Agile Software Development: 2nd edition by Alistair Cockburn<br />Are iterations hazardous to your project? by Alistair Cockburn (http://alistair.cockburn.us/index.php/Are_iterations_hazardous_to_your_project%3F)<br />Balancing Agility and Discipline: A Guide for the Perplexed by Barry Boehm, Richard Turner<br />Critical Chain Project Management by Lawrence P. Leach<br />Developing Products in Half the Time: 2nd Edition by Preston G. Smith, Donald G. Reinertsen<br />
  • 43. Copyright © 2007-8, Norbert Winklareth<br />41<br />Additional References continued<br />Effective Risk Management: Some Keys to Success by Edmund H. Conrow<br />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<br />Fast Innovation by Michael George<br />HP gets 3.4x productivity gain from Agile Management techniques (http://www.agilemanagement.net/Articles/Weblog/HPgets3.4xproductivitygai.html) by David Anderson<br />Implementing Lean Software Development by Mary and Tom Poppendieck<br />Fit for Developing Software: Framework for Integrating Tests, Rick Mugridge and Ward Cunningham<br />Bridging the Communication Gap: Specification by example and agile acceptance testing by GojkoAdzic<br />Teamwork is an Individual Skill: Getting Your Work Done When Sharing Responsibility by Christopher M. Avery<br />
  • 44. Copyright © 2007-8, Norbert Winklareth<br />42<br />Additional References continued<br />Kanban in Action (http://www.agilemanagement.net/Articles/Weblog/KanbaninAction.html) by David Anderson<br />Lean Software Development by Mary and Tom Poppendieck<br />Software By Numbers by Mark Denne, Jane Cleland-Huang<br />The Elegant Solution by Matthew E. May<br />The ROI from Software Quality by Khaled El Eman<br />The Toyota Product Development System by James M. Morgan, Jeffrey K. Lisker<br />Wideband delphi (http://en.wikipedia.org/wiki/Wideband_delphi)<br />
  • 45. Additional References continued<br />Agile Estimating and Planning by Mike Cohn<br />Agile Management for Software Engineering by David Anderson<br />Agile Software Development: 2nd edition, Alistair Cockburn<br />Agile Retrospectives: Making Good Teams Great, Esther Derby and Diana Larsen<br />Agile Testing: A Practical Guide for Testers and Agile Teams, Lisa Crispin and Janet Gregory<br />Balancing Agility and Discipline: A Guide for the Perplexed by Barry Boehm, Richard Turner<br />Critical Chain Project Management by Lawrence P. Leach<br />Developing Products in Half the Time: 2nd Edition by Preston G. Smith, Donald G. Reinertsen<br />Effective Risk Management: Some Keys to Success by Edmund H. Conrow<br />Copyright (c) Norbert Winklareth<br />43<br />
  • 46. Additional References continued<br />Agile_BA_Requirements.yahoogroups.co.uk<br />mailing list, haven&apos;t seen much traffic on this but Chris Matts is a member and that is a very good thing<br />http://decision-coach.com/<br />Chris Matts and OLavMaassen blog, although they do not blog much, their existing articles are very good<br />http://www.infoq.com/articles/real-options-enhance-agility<br />an article on Real Options by the above two, I recommend reading the comments as well. Understanding and using this greatly benefits prioritization.<br />http://www.infoq.com/presentations/software-with-real-options<br />ice presentation by those two and yes I am a big fan ;-)<br />http://www.limitedwipsociety.org/2009/05/27/feature-injection/<br />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<br />http://www.agileproductdesign.com/blog/ <br />This is Jeff Patton&apos;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:<br />http://www.agilemodeling.com/essays/businessAnalysts.htm<br />Scott Ambler&apos;s view on integrating BA into Agile Development Teams<br />Copyright (c) Norbert Winklareth<br />44<br />
  • 47. Additional References continued<br />Good Boss, Bad Boss by Robert I. Sutton<br />Hard Facts, Dangerous Half-Truths, and Total Nonsense: Profiting from Evidence-based Management by Jeffrey Pfeffer &amp; Robert I. Sutton<br />The Halo Effect: ... and the Eight Other Business Delusions That Deceive Managers by PhillRozenzweig<br />Herding Cats blog, http://herdingcats.typepad.com/my_weblog/<br />Organizational Patterns of Software Development by James O. Coplien &amp; Neil B. Harrison<br />Succeeding with Agile: Software Development Using Scrum by Mike Cohen<br />Freedom from Command &amp; Control: Rethinking Management for Lean Service by John Seddon<br />Copyright (c) Norbert Winklareth<br />45<br />
  • 48. Additional References continued<br />&quot;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<br />Requires free login<br />Stop Blaming Your Culture by Jon Katzenbach and Ashley Harshak, http://www.strategy-business.com/article/11108<br />Requires free login<br />The Art of Software Development by James Shore &amp; Shane Warden<br />Thinking in Systems: A Primer by Donella H. Meadows<br />The Design of Business by Roger Martin<br />The Opposable Mind by Roger Martin<br />Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise by Dean Leffinger<br />Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects by Johanna Rothman<br />this is very good introduction on how to manage multiple projects, the portfolio, it is important for BA&apos;s, in fact everyone, to understand the larger processes they are working in and her advice on doing Portfolio Management is very good<br />Copyright (c) Norbert Winklareth<br />46<br />
  • 49. Additional References continued<br />http://searchsoftwarequality.techtarget.com/news/2240033170/Get-to-know-your-business-analysts - survey on what business analyst do<br />http://cdn.pols.co.uk/papers/cutterbusinessvaluearticle.pdf - nice little article on business value.<br />User Stories Applied by Mike Cohen - excellent and helpful book<br />Agile Product Management with Scrum - Roman Pichler<br />Scrum Product Ownership - Robert Galen<br />Agile Excellence for Product Owners - Greg Cohen<br />http://ebgconsulting.com/articles.php#agile - articles from a company that specializes in Agile Analysis and Requrements<br />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<br />Copyright (c) Norbert Winklareth<br />47<br />
  • 50. Additional References continued<br /><ul><li>http://www.agiledad.com/Documents/BAWhitepaperJune.pdf - another similar view</li></ul>Scaling Lean &amp; Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, Craig Larman and Bas Vodde<br />The new user story backlog is a map (http://tinyurl.com/3mpuot), Jeff Patton<br />The product owner and the product-shaped hole (http://tinyurl.com/dyyn33), Jeff Patton<br />The Toyota Product Development System by James M. Morgan, Jeffrey K. Lisker<br />Wideband Delphi (http://tinyurl.com/2wclrp)<br />xUnit Test Patterns: Refactoring Test Code, Gerard Meszaros<br />The Three Pillars of Executive Support for Agile Adoption (http://tinyurl.com/cteab5), Esther Derby<br />Lean Software Development by Mary and Tom Poppendieck<br />Refactoring Databases: Evolutionary Database Design, Scott W. Ambler and Pramod J. Sadalage<br />Copyright (c) Norbert Winklareth<br />48<br />
  • 51. Additional References continued<br /><ul><li>HP gets 3.4x productivity gain from Agile Management techniques (http://tinyurl.com/dfyswo) by David Anderson
  • 52. Action Learning by Chris Argyris
  • 53. The Shibumi Strategy by Matthew E. May
  • 54. Getting Results the Agile Way by J. D. Meier</li></ul>Copyright (c) Norbert Winklareth<br />49<br />

×