Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

#Noprojects @Agile Venture Prato 2018

174 views

Published on

La quasi totalità degli sviluppi software è basata su un approccio per progetto. Un progetto, per definizione, è qualcosa di effimero. Ha un inizio, e soprattutto una fine, qualcosa di temporaneo. Il software non è temporaneo. Un software sopravvive fino a quando esiste almeno una persona che lo utilizza. A volte sopravvive anche più a lungo.
Perché continuiamo ad usare qualcosa di effimero per gestire qualcosa che effimero non è? Quali alternative abbiamo? Possiamo fare veramente a meno dei progetti?

Published in: Software
  • Be the first to comment

#Noprojects @Agile Venture Prato 2018

  1. 1. https://www.linkedin.com/in/dimitri-favre-088675/ @DimitriFavre Dimitri Favre #noprojects Modern software developement focus on teams and products
  2. 2. Are you going to talk about yet another #nosomething hashtag?
  3. 3. I’d actually loved to hold a symposium on «Ditemi perché se la mucca fa mu il merlo non fa me. Digressione sul grande vuoto dato dall'assenza del coach waterfall»
  4. 4. Inspired by the work of Allan Kelly, Shane Estie, Evan Leybourn and others. Images and illustrations from «Spongebob Squarepants», © Viacom
  5. 5. Inspired by the work of Allan Kelly, Shane Estie, Evan Leybourn and others. And my very own experience Images and illustrations from «Spongebob Squarepants», © Viacom
  6. 6. A few steps back
  7. 7. We are (still) uncovering better ways of developing software by doing it and helping others to do it Agile Manifesto, 2001
  8. 8. I want to stress is the importance of getting rid of software projects as a notion. Instead we want to switch to a product-oriented view of the world where instead of projects that you spin up, run for a while and then stop; you instead say, "Let's focus on things that are much more long-lasting and organize a product team around that.“ Martin Fowler, «The State of Agile», August 2018
  9. 9. It’s not the project It’s the project model
  10. 10. We are so used to the project model that we are not able to see we have a problem with the project model
  11. 11. My top 5 problems with the project model
  12. 12. The power of teams
  13. 13. Bruce Tuckman, 1965
  14. 14. Bruce Tuckman, 1965 End of project. Let’s dismantle the team. We’ll create a brand new team when and if a new project will start
  15. 15. And while you celebrate project success, you destroy all the team value by dismantling it
  16. 16. Products are forever (kind of) and continuously evolving
  17. 17. A project is a temporary endeavor undertaken to create a unique product, service or result. Source: What is Project Management, PMI - https://www.pmi.org/about/learn-about-pmi/what-is-project-management
  18. 18. It means that
  19. 19. Projects start
  20. 20. … and finish (well, not all of them)
  21. 21. At the end of a project success is typically (still) associated with the iron sulphite triplet: - On time (schedule) - On budget - On scope
  22. 22. Where’s value? What about quality?
  23. 23. Project success focus on the wrong things (what is measurable, not what is valuable)
  24. 24. What happens when the project ends?
  25. 25. Typically two choices: - The projects is extended - Handover to AMS
  26. 26. Praying for extra-budget
  27. 27. Here’s the budget
  28. 28. Handover to AMS Teams
  29. 29. AMS is the retirement home of products
  30. 30. Until they are declared officially dead phased off
  31. 31. Maintenance should be just a transient state before next evolutionary step Source: By Dzonatas - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=4376189
  32. 32. DEV-AMS Conflict of interest AMS and support contracts with any form of per incident fee has no interest in reducing technical debt during the development project
  33. 33. Major league teams VS Minor league teams
  34. 34. Project model enforce the view of the IT as a cost center and foster silos creation
  35. 35. Organizational silos represent one of the major barrier to agility
  36. 36. Projects (even agile ones) are actually built around silos
  37. 37. Instead of value the outcome is local optimizations, redundancy and increased complexity
  38. 38. Silos fight for budget allocation based on a cost perspective
  39. 39. And teams are created, split, changed, recombined or even terminated in order to match the project that justify their work
  40. 40. Bruce Tuckman, 1965 End of project. Let’s dismantle the team. We’ll create a brand new team when and if a new project will start
  41. 41. And this is so typical for outsourcers working for commissioned orders
  42. 42. Projects are typically based on a defined scope (with a long and detailed list of requirements)
  43. 43. The project model poisons the whole delivery even if you are an agile factory
  44. 44. Agile and Project in the same sentence is an oxymoron
  45. 45. Ooops
  46. 46. Forecasts and budgets are typically based on the defined set of requirements that will be then become a project
  47. 47. Here’s the budget (again)
  48. 48. Leading to scope based contracts
  49. 49. At the end of the day, Time&Material (with variations that take in account for value delivered) is the most common kind of agile contract
  50. 50. As a matter of fact, funding is based on capacity more than scope
  51. 51. 5. Disposable ad-hoc teams 4. Project Model focus on the wrong things 3. Projects have expiration date 2. Project foster silos 1. The Agile Project oxymoron
  52. 52. #noproject world
  53. 53. Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupéry
  54. 54. Everything is continuous nowadays
  55. 55. Continuous Improvement
  56. 56. Continuous Integration
  57. 57. Continuous Delivery
  58. 58. Continuous Release
  59. 59. But never heard of Continuous Project
  60. 60. Modern (and agile) software development should abandon the project model and its legacy
  61. 61. Business agility can be really achieved only by removing the project model (and jargon) wherever and whenever possible
  62. 62. Focus your efforts on the evolution of your product portfolio (including adding new products)
  63. 63. … bring the work to (existing) teams, with the right priorities
  64. 64. … and scale up when and if needed
  65. 65. Some suggestions on the top 5
  66. 66. 5. Disposable ad-hoc teams 4. Project Model focus on the wrong things 3. Projects have expiration date 2. Project foster silos 1. The Agile Project oxymoron
  67. 67. A team dealing with multiple products is far better than several little disposable ad hoc teams
  68. 68. Manage a team backlog (through a team Products Owner)
  69. 69. It’s not a matter of Happiness It’s just plain f***ing money (and money can’t buy happiness anyway)
  70. 70. Project success focus on the wrong things (what is measurable, not what is valuable)
  71. 71. Indeed, the goal is to create value, for the customer, for the organization and for society as a whole
  72. 72. Instead of asking “How much it costs?” ask “What is worth”
  73. 73. Why in the hell should we manage a long lasting thing with ephemeral stuff named projects?
  74. 74. Living products have long lists of requests waiting to be implemented (and new ones will arise continuously during their lifetime)
  75. 75. Don’t be afraid of having unallocated people and teams. They won’t
  76. 76. BTW There’s no better place for maintaining a software product than in the team that created it
  77. 77. You will probably not be able to shut down organizational silos, but at least try to remove them in the software you implement
  78. 78. Be lean
  79. 79. Be lean by adopting system thinking and global optimization
  80. 80. Be lean in portfolio management (you might think of stealing the probably best part of SAFe)
  81. 81. No real suggestions, just think twice before using agile and project in the same sentence ;)
  82. 82. Oh no, I’m a Project Manager
  83. 83. There is still room for projects and the project model
  84. 84. In some cases the project model is still the best fit
  85. 85. For everything else there are Products, Teams and #noprojects
  86. 86. References
  87. 87. Project Myopia: Why projects damage software #NoProjects Allan Kelly, 2018
  88. 88. Continuous Digital: An agile alternative to projects for digital business Allan Kelly, 2018
  89. 89. #noprojects: A Culture of Continuous Value Evan Leybourn, Shane Estie, 2018
  90. 90. Follow #noprojects on twitter and on Slack
  91. 91. Questions?
  92. 92. https://www.linkedin.com/in/dimitri-favre-088675/ @DimitriFavre Dimitri Favre Thank you

×