Lean & agile 101 for Astute Entrepreneurs


Published on

Performed at the LeanStartup meetup in Dublin

Published in: Technology, Business
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Research (anarchy)Simple (maintenance)Scrum is appropriate for problems in the complex space
  • Scrum didn't really become a development concept until 1995, when Jeff Sutherland and Ken Schwaber teamed up to codify the method (and the term) that is so ably documented in the book Schwaber wrote with Mike Beedle in 2001, entitled Agile Software Development with SCRUM (Prentice Hall, ISBN: 0130576349).
  • In Scrum and Kanban you are supposed to add stuff.In RUP, you are supposed to remove stuff.Scrum + XPKanban + daily standupScrum team using use cases or limiting WIPDon’t call it Scrum if it isn’t.
  • Research (anarchy)Simple (maintenance)Scrum is appropriate for problems in the complex space
  • Role, feature, benefit
  • Lean & agile 101 for Astute Entrepreneurs

    1. 1. @agilesensei After reading this, introduce yourself to a person you don’t know yet. Tell this person why you are here and what you hope to learn. written, illustrated and performed by Claudio Perrone
    2. 2. “Pair Customer Developmentwith Agile DevelopmentCustomer development is useless unless theproduct development organization caniterate the product with speed and agility. --- Steve Blank & Bob Dorf
    3. 3. If we keep acting like most entrepreneurs…
    4. 4. … Only 3 people in this room will Createsuccessful companies*“(*) The only statistics you can trust are those you falsified yourself --(often falsely attributed to) Winston Churchill
    5. 5. Most startups fail will Yours?
    6. 6. “July 2009 was the wettest Julyon record in Ireland”
    7. 7. “that month, a new life rocked my world…”
    8. 8. “that month, I left an exceptional companyI helped create from scratch”
    9. 9. “From the very beginning, I had embracedAgile development to grow aworld-class software organization”
    10. 10. Agile1 Software Development
    11. 11. Until then, I was mostly familiar withthe traditional “waterfall” approach Weeks  
    12. 12. …which was fundamentally inadequatein my domainFixed-Price/ New SequentialFixed Scope opportunities/ process ReleaseContracts + Change (waterfall)BDUF requests- Stringent - Big handoffs - Late changes are - Late Releases,contracts (transaction unwelcomed - poor quality- Fixed scope costs) - Scope creep -  poor staff morale- Fixed date based - Last phases - Unbalanced demand -  low customeron early estimate compressed - -no time for process satisfactionor cost of delay -  lots of Work In improvement⇒ All features are Process (WIP) - - quality suffersequally - -Unknownimportant, integration phase⇒ Big cushion to lengthcontain risk - - poor progress(contingency) visibility⇒ All or nothing
    13. 13. A business strategy lesson confirmedwhat I had realized“build cheap, fail fast (i.e. the faster you find your flaws, the faster you move on to what works)
    14. 14. How can Agility Help?
    15. 15. “What can we observe here?”
    16. 16. “can you spot any difference?”
    17. 17. “How do you see the world?”from predictive... ...to adaptive
    18. 18. Manifesto  for  Agile  So2ware  Development   We  are  uncovering  be;er  ways  of  developing   so2ware  by  doing  it  and  helping  others  do  it.   Through  this  work  we  have  come  to  value:    Individuals  and  interacCons  over  processes  and  tools  Working  so2ware  over  comprehensive  documentaCon   Customer  collaboraCon  over  contract  negoCaCon   Responding  to  change  over  following  a  plan     That  is,  while  there  is  value  in  the  items  on   the  right,  we  value  the  items  on  the  le2  more.     h;p://agilemanifesto.org/iso/it/  
    19. 19. Under the umbrella of agile (values & principles),THERE ARE several methodologies (implementations) Crystal   Clear   Scrum   …  eXtreme  Programming   DSDM   Lean   Feature  Driven   So2ware   Development  
    20. 20. I’ve embraced XP’s technical practicessince 2001 Whole  team   Coding  standard   Test-­‐Driven  Development  (TDD)   CollecCve  ownership   Customer  tests   Pair  programming   Refactoring   Planning  game   ConCnuous  integraCon   Simple  design   Sustainable  pace   Metaphor   Small  releases  
    21. 21. I then integrated XP with Scrum, the mostpopular agile framework to date
    22. 22. Compare for understanding, not judgmentMore prescriptive More adaptive RUP XP Scrum Kanban Do Whatever (120+) (13) (9) (5) (0) •  Architecture  Reviewer   •  Business  use  case  realizaCon   •  Business  Designer   •  Business  use-­‐case  model   •  Business-­‐Model  Reviewer   •  Business  vision   •  Whole  team   •  Scrum  Master   •  Visualize  the   •  Business-­‐Process  Analyst   •  Change  request   •  Coding   •  Product   •  Capsule  Designer   •  ConfiguraCon  audit  findings   workflow   •  •  Change  Control  Manager   Code  Reviewer   •  •  ConfiguraCon  management  plan   Data  model   standard   Owner   •  •  ConfiguraCon  Manager   Course  Developer   •  •  Deployment  model   Deployment  plan   •  TDD   •  Team   •  Limit  WIP   •  •  Database  Designer   Deployment  Manager   •  •  Design  guidelines   Design  model   •  CollecCve   •  Sprint   •  Measure  and   •  Design  Reviewer   •  Development  case   •  Designer   •  Development-­‐organizaCon  assessment   ownership   planning   opCmize  flow   •  Graphic  ArCst   •  End-­‐user  support  mateirla   •  Customer   meeCng   •  Implementer   •  Glossary   •  Write  explict   •  •  Integrator   Process  Engineer   •  •  ImplementaCon  model   InstallaCon  arCfacts   tests   •  Daily  Scrum   •  •  Project  Manager   Project  Reviewer   •  •  IntegraCon  build  plan   Issues  list   •  Pair   •  Sprint  review   policies   •  •  Requirements  Reviewer   Requirements  Specifier   •  •  IteraCon  assessment   IteraCon  plan   programming   •  Product   •  Improve   •  •  So2ware  Architect   Stakeholder   •  •  Manual  styleguide   Programming  guidelines   •  Refactoring   backlogt   collaboraCvely   •  •  System  Administrator   System  Analyst   •  •  Quality  assurance  plan   Reference  architecture   •  Planning   •  Sprint  backlog   •  •  Technical  Writer   Test  Analyst   •  •  Release  notes   Requirements  a;ributes   game   •  BUrndown   •  •  Test  Designer   Test  Manager   •  Requirements   management  plan   •  ConCnuous   chart   •  •  Tester   Tool  Specialist   •  •  Review  record   Risk  list   integraCon   •  User-­‐Interface  Designer   •  Risk  management  plan   •  Architectural  analysis   •  So2ware  architecture   •  Simple  design   •  Assess  Viability  of  architectural  proof-­‐ of-­‐concept   •  document   So2ware  development   •  Sustainable   •  •  Capsule  design   Class  design   •  plan   So2ware  requirements  specificaCon   pace   •  Construct  architectural  proof-­‐of-­‐ concept   •  •  Stakeholder  requests   Status  assessment   •  Metaphor   •  •  Database  design   Describe  distribuCon   •  •  Supplementary  business  specificaCon   Supplementary  specificaCon   •  Small  releases   •  Describe  the  run-­‐Cme  architecture   •  Target  organizaCon  assessment   •  Design  test  packages  and  classes   •  Test  automaCon  architecture   •  Develop  design  guidelines   •  Test  cases   •  Develop  programming  guidelines   •  Test  environment  configuraCon   •  IdenCfy  design  elements   •  Test  evaluaCon  summary   •  IdenCfy  design  mechanisms   •  Test  guidelines   •  Incorporate  design  elements   •  Test  ideas  list   •  PrioriCze  use  cases   •  Test  interface  specificaCon   •  Review  the  architecture   •  Test  plan   •  Review  the  design   •  Test  suite   •  Structure  the  implementaCon  model   •  Tool  guidelines   •  Subsystem  design   •  Training  materials   •  Use-­‐case  analysis   •  Use  case  model   •  Use-­‐case  design   •  Use  case  package   •  Analysis  model   •  Use-­‐case  modeling  guidelines   •  Architectural  proof-­‐of-­‐concept   •  Use-­‐case  realizaCon   •  •  Bill  of  materials   Business  architecture  document   •  •  Use-­‐case  storyboard   User-­‐interface  guidelines   Henrik Kniberg •  Business  case   •  User-­‐interface  prototype   •  Business  glossary   •  Vision   •  Business  modeling  guidelines   •  Work  order   •  Business  object  model   •  Workload  analysis  model   •  Business  rules   •  Business  use  case   Henrik  Kniberg  
    23. 23. iterative development enabled us tocontinuously deliver value Weeks  
    24. 24. User stories were our “placeholdersfor conversations” Customer withdraws cash As a customer, I want to withdraw cash from an ATM, so that I don’t have to wait in line at the bank.Ref:  h;p://dannorth.net/introducing-­‐bdd  
    25. 25. Every day, we held a quick standupmeeting to synchronize our efforts To DO Doing Done Burndown Family 1 Work Left Days Unplanned Next
    26. 26. Every 2 weeks, we demonstrated whatwe built and held a team retrospective Good Bad Next Do more Do Less Start Stop Doing Doing Keep Doing
    27. 27. Product owners, scrum masters, teamsand management worked together tocreate value & remove impediments
    28. 28. what can you expect from an agile team/organization? Visibility Adaptability Business  Value Risk Agile  Development Traditional  Development
    29. 29. We crafted opinionated software“The best softwarehas a vision.The best softwaretakes sides.…Decide whatyour vision is and run with it.”-- 37 signals
    30. 30. We won awardsand respect…
    31. 31. we could almosttouch the sky…
    32. 32. Almost
    33. 33. “July 2009 was the wettest Julyon record in Ireland”
    34. 34. I’ll remember it as the monthmatteo was born
    35. 35. But it is also the monthI had to let go of a dream
    36. 36. …Like sand through my fingers
    37. 37. … so I became a Lean & Agile consultant!
    38. 38. On my first mission, a cio asked me aquestion that haunts me to this day…
    39. 39. “If you were so smart, why did you fail?”
    40. 40. Lean2 Software Development
    41. 41. I became increasingly intrigued by the riseof Lean and its influence in the agile circles
    42. 42. There are 7 principles of lean thinking whichare most relevant to software development Eliminate Waste Build quality in Create knowledge Defer commitment Deliver fast Respect for people Optimize the whole
    43. 43. Lean is heavily inspired by Toyota’sbreakthroughs in operational excellence
    44. 44. “ All we are doing is looking at the timeline from the moment the customer gives us an order to the point we can collect the cash. And we are reducing that timeline by removing the non-value-added wastes. --- Taiichi Ohno, Founder of TPS
    45. 45. What do Youknow about Kanban?
    46. 46. Kanban EnablesJust-in-time
    47. 47. Kanban has 5 rules:1.  Visualize your workflow2.  Limit your “Work in process” (WIP)3.  Measure and optimize flow4.  Write Explicit policies5.  Improve collaboratively
    48. 48. Kanban starts from whereveryour are already! (Kanban + SDLC)
    49. 49. One  day  in  Kanban  land  (1/6)   Courtesy  of  Henrik  Kniberg  (www.crisp.se)  Ref:  h;p://is.gd/3gAIO  
    50. 50. One  day  in  Kanban  land  (2/6)   Courtesy  of  Henrik  Kniberg  (www.crisp.se)  Ref:  h;p://is.gd/3gAIO  
    51. 51. One  day  in  Kanban  land  (3/6)   Courtesy  of  Henrik  Kniberg  (www.crisp.se)  Ref:  h;p://is.gd/3gAIO  
    52. 52. One  day  in  Kanban  land  (4/6)   Courtesy  of  Henrik  Kniberg  (www.crisp.se)  Ref:  h;p://is.gd/3gAIO  
    53. 53. Have you noticed? Explicit limits enable a collaborative game
    54. 54. One  day  in  Kanban  land  (5/6)   Courtesy  of  Henrik  Kniberg  (www.crisp.se)  Ref:  h;p://is.gd/3gAIO  
    55. 55. One  day  in  Kanban  land  (6/6)   Courtesy  of  Henrik  Kniberg  (www.crisp.se)  Ref:  h;p://is.gd/3gAIO  
    56. 56. Kanban is a great enabler, but it representsonly the tip of the iceberg…
    57. 57. As a consequence, there are many possibledefinitions of Lean, all somewhat limited 1.  What Toyota does 2.  Identifying and removing waste 3.  A problem-identifying and problem- solving system
    58. 58. During my extensive work on “a3 thinking”*,a Toyota management process to systematicallysolve problems, improve and mentor… (*) I’m writing a book about it!
    59. 59. I discovered that a3 thinking = Lean thinking, avivid expression of the scientific method!
    60. 60. “Hence, I offer you my own definition”“Lean is a business strategy to make money* THROUGH the development of people (*) replace with “create customer value” or “reach results”, if you prefer
    61. 61. Using Lean and agile, I brought success tomany clients, from large enterprises tofast-growing companies around Europe
    62. 62. But that oldquestion still remainedunanswered…
    63. 63. … Until one day
    64. 64. 3 Lean Startup
    65. 65. … I entered a new world Learn idea Build data Product Measure
    66. 66. Today I have opinions assumptions
    67. 67. … which I validate through experiments
    68. 68. … that force me to “get out of the building”
    69. 69. … iterate my solutions with low fidelity MVPs
    70. 70. … and Activate enthusiastic earlyvangelists with aglimpse of a future that will come
    71. 71. So, where is the sweet spot? Strategy vs. Execution
    72. 72. Final Thoughts
    73. 73. “ Smart entrepreneurs don’t dream of success. They create the conditions to inevitably converge to it. --- Me (1967 - )
    74. 74. Thank  you!   Claudio  Perrone  claudio@agilesensei.com  www.agilesensei.com  www.twi;er.com/agilesensei  
    75. 75. Evaluate your own learning!Write down… What did you learn? How will you apply it? How will it benefit your venture? Suggestions or questions you still have? claudio@agilesensei.com www.agilesensei.com www.twitter.com/agilesensei
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.