Agile Principles, Agile People


Published on

A presentation given to introduce Agile to an audience that did not know too much about it. Comparing Lean & Agile was a secondary goal of the talk.

Published in: Business, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Tom DeMarco: “In big companies, it’s often more acceptable to be wrong than it is to be uncertain.”
  • JIM HIGHSMITH (Agile Objections) BMW uses simulations in its design process to improve car crashworthiness — 91 simulations, two real crashes, 30% improvement in design, 2.5 days per simulated crash versus 3.8 months (for simple tests) — and the 91 simulations cost less than the two real crashes. BMW engineers found that these low-cost iterations changed design processes. In fact, they found that when experiments can be done in 2.5 days rather than 3.8 months, it drastically changes how their engineers approach design. Engineers begin to practice design by experimentation rather than design by anticipation (up-front design). The BMW designers often found that the experiments taught them very quickly that their anticipatory designs were wrong.
  • Light-Touch Leadership means that decision making is delegated to the lowest level possible and as many decisions as possible are delegated to the team-Poppendieck summarized this history into three styles of leadership: 1) Old “Dictator” Style: “Do it my way…”; 2) 1980s “Empowerment” Style: “Do it your way... ”; 3) Lean Style: “Follow me…and let’s figure this out together.” Within the Toyota Production System, the role of the leader is: act as a teacher; get each person to take the initiative to solve problems and improve his or her job; and ensure that each person’s job is aligned to provide value for the customer and prosperity for the company
  • Remove queues and delays. Buffers.Balance demand against throughput
  • Kanban process: a set of policiesKanban enable incremental changes, with reduced political risks and minimal resistance.Cadence: delivery, prioritizaton, retrospective can each have their own cadence
  • Pull without input from a manager
  • it isn’t easy to ignore a blocked and work on something else
  • it isn’t easy to ignore a blocked and work on something else
  • Agile Principles, Agile People

    1. 1. AgilePrinciplesAgilePeople<br />Gaetano Mazzanti<br />Gama-Tech<br />
    2. 2. > “Hello, I’m Agile”<br />
    3. 3. “and I’m not alone”<br />
    4. 4. project<br />product<br />Agile is aboutchange<br />culture<br />people<br />organization<br />
    5. 5. Processes<br />and Tools<br />Comprehensive<br />Documentation<br />a recipe for success?<br />Following<br />a Plan<br />Contract<br />Negotiation<br />
    6. 6. “all you need is a good process and good tools”<br />“even monkeys could write good software”<br />
    7. 7. requirements<br />design<br />implementation<br />testing<br />do you spot any problem?<br />
    8. 8. ODYSSEY<br />SOFTWARE<br />A<br />Processes and Tools<br />Contract Negotiation<br />Comprehensive Documentation<br />Following a Plan<br />
    9. 9. 31% <br />ofprojectscancelled<br />53% challenged<br />1994 Chaos Report(Standish Group)<br />
    10. 10. why projects fail:<br />lack ofuserinput<br />incomplete requirements<br />changing requirements<br />1994 Chaos Report(Standish Group)<br />
    11. 11. 45%<br />offeatures are neverused<br />2002 Chaos Report(Standish Group)<br />
    12. 12. software is about learning, continuously<br />planning is guessing<br />estimating is not<br />committing<br />
    13. 13. MANIFESTO<br />AGILE<br />2OOI<br />:<br />Individuals and Interactions<br />Working Software<br />Customer Collaboration<br />Responding to Change<br />over Processes and Tools<br />over Comprehensive Documentation<br />over Contract Negotiation<br />over Following a Plan<br />
    14. 14. Agile timeline<br />Edward<br />Deming<br />theory of<br />constraints<br />crystal<br />new new product development<br />1993<br />DSDM<br />lean<br />thinking<br />complex<br />adaptive<br />systems<br />1996<br />Agile manifesto<br />2001<br />lean<br />development<br />2004<br />queueing<br />theory<br />
    15. 15. “I don’t know what I want,but I know how to get it”<br />Johnny Rotten<br />Sex Pistols<br />
    16. 16. delivervalue in small evolutionarysteps<br />delay commitment, makedecisionsat the last responsible moment<br />build in qualityonlywhatisneeded andonlywhenisneeded<br />makeproject statustransparent and visible,highlightissues and impediments<br />
    17. 17. XP<br />rebellious and prescriptive (!)<br />on site customer<br />frequent small releases<br />small colocated teams<br />pair programming<br />unit tests / TDD<br />refactoring<br />...<br />
    18. 18. flattening the cost of change<br />traditional<br />cost of change<br />Agile<br />time<br />
    19. 19. Scrum<br />used by 58% of Agile adopters<br />2010 State of Agile Development Survey<br />cross-functional team<br />timeboxed iterations<br />(sprints)<br />split & prioritize<br />
    20. 20. Scrum<br />product<br />owner<br />standup<br />meeting<br />scrum<br />master<br />product<br />backlog<br />sprint<br />backlog<br />team<br />sprint<br />deliverable<br />demo & retrospective<br />
    21. 21. frequent and repeated success builds trust and motivation<br />manager<br />coach<br />servant<br /> guidance <br /> provides<br /> feedback<br />enable excellence<br />connects the team to the business<br />team<br />trusted<br />respected<br />supported<br />work autonomously<br />makes allday-to-day decisions<br />{<br />
    22. 22. burndown chart<br />instantfeedback<br />story points<br />delay<br />days<br />
    23. 23. lean & agile<br />value<br />waste<br />pull<br />flow<br />cadence<br />kaizen<br />respectfor people<br />
    24. 24. Kanban inproduct development<br />visualize<br />measure<br />optimize<br />}<br />flow<br />pull<br />limit WIP (work in process)<br />
    25. 25.
    26. 26. visualize flow<br />backlog<br />to do<br />in progress<br />done<br />
    27. 27. visualizeflow<br />limit WIP (work in process)<br />measure and optimizeflow<br />explicit policies(limit WIP, pull, definition of ”done”, etc) -><br />project and process trasparency<br />WIP<br />throughput<br />cycle time =<br />backlog<br />to do<br />in progress<br />test<br />done<br />2<br />3<br />2<br />cycle time<br />lead time<br />slide credit:<br />
    28. 28. pull<br />in progress<br />ready<br />backlog<br />to do<br />done<br />2<br />3<br />1<br />
    29. 29. WIP excess<br />slide inspired by Claudio Perrone<br />
    30. 30. WIP limit <br />slide inspired by Claudio Perrone<br />
    31. 31. no WIP limit -> queue!<br />in progress<br />ready<br />backlog<br />to do<br />done<br />2<br />3<br />
    32. 32. stuck!<br />in progress<br />ready<br />backlog<br />to do<br />done<br />2<br />3<br />1<br />
    33. 33. up to the team<br />in progress<br />ready<br />backlog<br />to do<br />done<br />2<br />3<br />1<br />
    34. 34. on teams, again<br />performing<br />collaborative<br />supporting<br />group<br />a highly<br />helps<br />learning from<br />everyone<br />each other<br />the commitment<br />the process<br />the delivery<br />everyone<br />owns<br />
    35. 35. cumulative flow diagram<br />backlog<br />WIP<br />to do<br />cycle time<br />in progress<br />WIP<br />story points<br />cycle time<br />throughput<br />WIP<br />done<br />days<br />
    36. 36. Chaos Report 2009<br />cancelled<br />projects<br />were<br />31%<br />24%<br />were<br />53%<br />challenged<br />projects<br />44%<br />
    37. 37. concerns about Agile adoption<br />36%<br />loss of management control<br />barriers to further<br />Agile adoption<br />ability to change organizational culture<br />51%<br />2010 State of Agile Development Survey Results<br />
    38. 38. benefits from Agile implementation<br />87%<br />manage changing priorities<br />74%<br />increase productivity<br />70%<br />accelerate time to market<br />66%<br />enhance product quality<br />77%<br />improve project visibility<br />2010 State of Agile Development Survey Results<br />
    39. 39. Agile encourages/favors<br />change<br />any other methodology<br />supporting this?<br />
    40. 40. change<br />is the only constant<br />
    41. 41.
    42. 42. Gaetano Mazzanti<br />Gama-Tech<br /><br />photo credits:<br />Flickr, iPhotostock,<br />