Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Agile Myths and Pitfalls - 2020 (ver 0.8)

Agile Myths and Pitfalls - talk at COCDE GARDEN

  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Agile Myths and Pitfalls - 2020 (ver 0.8)

  1. 1. Agile Myths & Pitfalls openware Code Garden 09.2020
  2. 2. AGILE IS MAINSTREAM Reasons
  3. 3. Agile is Mainstream a g il e
  4. 4. Agile is Mainstream • One of the key features of agile methods is that they are PeopleOriented. They recognize that people and how they work together is the primary factor in software development, and that processes are a secondary factor. This is reflected in the first value of the agile manifesto "Individuals and interactions over processes and tools" and is reinforced by two principles of the manifesto: • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. • The best architectures, requirements, and designs emerge from self-organizing teams.
  5. 5. AGILE PITFALLS
  6. 6. AGILE MEANS ‘NO DOCUMENTATION' • The adaptive and iterative nature of agile places less emphasis on the need for documentation compared to waterfall, but that does not mean that no documentation is required.
  7. 7. AGILE MEANS ‘NO DOCUMENTATION' • Elements of the project continuously evolve as additional information becomes available and user needs are defined. • A traditional approach results in detailed documentation at the end of each phase. • Agile Approach: less documentation • In agile, an appropriate level of documentation will be an output of each iteration.
  8. 8. AGILE MEANS ‘NO DOCUMENTATION' Developing adequately detailed documentation for agile is a necessity to: • Meet the needs of project stakeholders. • Document decisions made. • Support communication with external groups, including stakeholders outside the project team or for team members that cannot collocate. • Support the use, operation and maintenance of the system. • Capture lessons learned for continuous improvement and to benefit future projects. • Report project status and performance metrics.
  9. 9. AGILE MEANS ‘NO DOCUMENTATION' • The effective management of a project should have value-driven documentation that supports the project team’s communication with stakeholders, and enables the business to use the product effectively, and the technical team to support and maintain it. • When considering what documentation looks like in your project, think about the value of the document or if it is needed, what information needs to be captured, when it needs to be captured, with whom it needs to be shared, and how that documentation might help the team improve.
  10. 10. AGILE MEANS ‘NO DOCUMENTATION' • Agile Means Documentation that is Actually Read • User Stories are in a form that is meaningful to all parties, expresses business objectives. • Acceptance Tests removes ambiguity from requirements. • Unit Tests describe the behaviour of methods.
  11. 11. AGILE MEANS ‘NO DOCUMENTATION'
  12. 12. AGILE MEANS ‘NO DOCUMENTATION'
  13. 13. AGILE IS UNDISCIPLINED • Agile project management and system development practices are not only demanding of the project team, but they also require the support and a shared commitment for success by the leaders of the organization. • The continuous integration and test-driven development of agile requires skill, coordination, collaboration, and discipline from the entire project team.
  14. 14. AGILE IS UNDISCIPLINED • Successful agile teams consistently deliver quality product increments that demonstrate working functionality in short time frames to provide value and benefit to the organization. • To achieve this level of delivery, the leaders of the organization must delegate authority to the team to enable them to make decisions rapidly; this requires a high degree of developer and team discipline.
  15. 15. AGILE IS DISCIPLINED ;)
  16. 16. MYTH: AGILE MEANS 'NO PLANNING' Agile Myths and Misconceptions
  17. 17. AGILE MEANS 'NO PLANNING' • As with any approach, planning is a vital aspect that, if not adequately carried out, greatly diminishes the effectiveness of a successful implementation.
  18. 18. AGILE MEANS 'NO PLANNING' No extensive planning upfront. Agile spread this activity. This continuous planning allows a project to start much quicker and to be more nimble to make ongoing adjustments in strategy as new information becomes available. Changes in business needs or priorities; project issues, risks, or resources; and even changes in available technology.
  19. 19. AGILE MEANS 'NO PLANNING' It also provides the project team with the ability to more easily and efficiently adapt to changes and optimize plans as new information emerges.
  20. 20. MYTH: AGILE IS SHORT MILESTONES Agile Myths and Misconceptions
  21. 21. Waterfall with many short Milestones • Iterations 1 – 4: • Iterations 5 – 8: • Iterations 9 – 16: • Iterations 17 – 20: • Iterations 21 – 24: Requirements Gathering Design Implementation SIT/UAT Production Support
  22. 22. MODULE MILESTONES (Multiple Short Waterfalls) • Phase 1: Ordering Module • Phase 2: Prder Processing Module • Phase 3: Billing Module • Phase 4: User Management
  23. 23. ITERATIVE DEVELOPMENT • It's not just about frequent deliveries.
  24. 24. SOFTWARE IS EVOLVED
  25. 25. Working software produced at each iteration • Progress measured by working features – No such thing as “X% complete”, only done and not done at the end of a sprint • Done means tested, ready to deploy
  26. 26. AGILE = SCRUM • Scrum is a popular development methodology that is iterative and adaptive; however, Scrum and agile are not the same thing. • Scrum is a framework for developing and managing work, while agile is an approach that follows a common set of values and principles that many methodologies fall under.
  27. 27. AGILE = SCRUM Agile projects/products do not have to adopt any particular development methodology
  28. 28. AGILE = SCRUM • Organizations must assess each development methodology to identify which is best suited for the environment. • It is important to understand that the different development methodologies all focus on understanding and meeting the users’ needs in a flexible and iterative way.
  29. 29. AGILE = SCRUM • Some agile practices can and should be leveraged to complement a waterfall approach also in organizations not ready toi a full agile adoption. • This includes those that pertain to the culture and environment of an organization (e.g., collocating teams, having access to business owners), or to project planning (e.g., deploying the project over several releases instead of one release at the end).
  30. 30. AGILE = SCRUM • Agile development methodologies have a greater chance of successfully achieving the desired outcomes when adopted in its entirety; this incremental adoption of agile organizational and planning practices can help lay the foundation for a later adoption of an agile development methodology.
  31. 31. AGILE = SCRUM • Scrum is just one of many methodologies that come under the umbrella of agile values and principles. • Other methodologies include Scaled Agile (in many formats), Extreme Programming and Kanban.
  32. 32. principi e valori pratiche
  33. 33. Agile Pratiche Agili Principi Agili Valori Agili Necessità di rispondere al cambiamento continuo
  34. 34. Agile Pratiche Agili Principi Agili Valori Agili Necessità di rispondere al cambiamento continuo
  35. 35. Agile Pratiche Agili Principi Agili Valori Agili Necessità di rispondere al cambiamento continuo
  36. 36. Agile Pratiche Agili Principi Agili Valori Agili Necessità di rispondere al cambiamento continuo
  37. 37. Agile Agile Practices Agile Principles Agile Values Need to respond to continuous change
  38. 38. Learning Organization Lean Thinking Agile Approaches Scrum, XP, … Morevalue/philosophical Moreprescriptive Applicability Advancing / Deepening / Improving
  39. 39. Scrum eXtreme Programming Crystal Clear Feature Driven Development DSDM AgileUP Lean Development Kanban
  40. 40. Agile Has Equal (or greater) Focus on Engineering • Early Agile methodologies were heavy on engineering – Test-Driven Development, Coding Practices, Design Patterns, etc. • Scrum originally focused on just project management, but lately is reemphasizing engineering
  41. 41. Agile Has Equal (or greater) Focus on Engineering
  42. 42. Sustainable pace
  43. 43. MYTH: AGILE MEANS NO MANAGERS Agile Myths and Misconceptions
  44. 44. «SELF ORGANIZING TEAMS» • “There’s a reason we use the term 'self- organizing' rather than 'self-organized' or 'self- managed.' • “That’s because it’s a process and a characteristic, not something that is done once and for all.” - Esther Derby
  45. 45. Self-Organizing Team: Mature, responsible, self- directed courageous people. – Aligned with company objectives – Solicits and provides feedback – Productivity visible to the organization – Works within financial and regulatory boundaries. To get there: Different people/teams need different management approaches. – Maturity, culture, motivation, discipline, awareness, etc.
  46. 46. AGILE MYTHS
  47. 47. Agile Myths • Il termine mito deriva dal greco mythos, ovvero parola, discorso, racconto. • Il mito è una narrazione fantastica rivestita di sacralità, che descrive l’origine di culture, di popoli, di fenomeni, di realtà esistenti e del mondo stesso, e che ne racconta inoltre le caratteristiche attuali.
  48. 48. MYTH 2: AGILE MEANS “NO GOVERNANCE” Agile Myths and Misconceptions
  49. 49. AGILE MEANS ‘NO GOVERNANCE' • Within an agile approach, the team members working on the project have autonomy over decisions about how to meet the needs of the user.
  50. 50. AGILE MEANS ‘NO GOVERNANCE' • Most state organizations will find it difficult to allow project teams complete autonomy. • Transitioning to agile may need to modify governance practices. • To create an environment that supports team autonomy, the organization should establish a governance process that meets regularly.
  51. 51. AGILE MEANS ‘NO GOVERNANCE' • Defining lightweight, fast moving, and effective project governance is incredibly important for agile project success. • The key is to establish a process that is appropriately specific, but not overly prescriptive.
  52. 52. MYTH 4: AGILE PRACTICES ARE NEW Agile Myths and Misconceptions
  53. 53. AGILE PRACTICES ARE NEW • The practices of agile have been around for the greater part of the last century.
  54. 54. AGILE PRACTICES ARE NEW • In the 1930s, physicist Walter Shewhart began improving products and processes through iterative cycles. • This practice was later modified by W. Edwards Deming to become the Plan-Do-Study-Act (PDSA), also known as Plan-Do-Check-Act (PDCA), cycle for continuous improvement and quality management.
  55. 55. AGILE PRACTICES ARE NEW • Up through the 1980s, the United States military, NASA, IBM, Honda, Toyota, Canon and others continued to experiment with and evolve concepts and practices we recognize as agile. • These ideas led to the publication of the Agile Manifesto in 2001 and identification of the common values and principles for improving the approach to system development projects.
  56. 56. AGILE PRACTICES ARE NEW • Currently, several varieties of agile-based methodologies are used in these efforts, including Scrum, Extreme Programming (XP), and in some cases, Kanban.
  57. 57. MYTH 5: AGILE ONLY WORKS WITH SMALL PROJECTS Agile Myths and Misconceptions
  58. 58. AGILE ONLY WORKS WITH SMALL PROJECTS • An agile development team consists of small, cross-functional groups that collaborate throughout the development process.
  59. 59. AGILE ONLY WORKS WITH SMALL PROJECTS • Equally effective on small projects and larger efforts to develop complex systems, since agile teams typically “divide and conquer.” • For larger projects, this means that multiple teams can be organized and focus on separate components of system functionality and/or technical architecture. • Feature Teams vs Component Teams • Especially for the large and complex, continuous integration of developed components on a daily if not more frequent basis is a critical success factor.
  60. 60. AGILE ONLY WORKS WITH SMALL PROJECTS • In an agile project with typically short development iterations, parallel development efforts, and frequent delivery of functionality, project teams must integrate their work often to detect and resolve errors as quickly as possible, with the ultimate goal of being able to deploy at any time. • DevOps practices and philosophy of Continuous Integration and Continuous Delivery.
  61. 61. AGILE ONLY WORKS WITH SMALL PROJECTS • If project teams delay the integration to just-prior-to- release, they will likely run out of time to adequately perform testing, address defects, and prepare the infrastructure. • Agile teams should ensure that they have the right automated build and test tools, and the appropriate processes in place to support continuous integration.
  62. 62. MYTH 7: IMPLEMENTING AGILE IS EASY Agile Myths and Misconceptions
  63. 63. Change is hard
  64. 64. IMPLEMENTING AGILE IS EASY • Change is hard. • Transitioning an organization that is more accustomed to a traditional waterfall approach to an agile approach is not an exception to this rule. • A significant number of organizations will not have practices and procedures that are geared towards those of an adaptive approach and will likely need to focus on adapting the project team’s project management and system development processes to the unique characteristics of the organization, project, and people.
  65. 65. IMPLEMENTING AGILE IS EASY • To achieve the full benefits, project teams must not only learn the best practices of agile; it is also important to understand the specific circumstances of the organization’s culture and the project/product. • To start, the project team should assess the organization’s readiness and whether the selected project is the right fit for agile.
  66. 66. IMPLEMENTING AGILE IS EASY • Import areas of evaluation: – organization’s existing governance structure – project management processes – level of management buy-in to both support and be an agent for change
  67. 67. IMPLEMENTING AGILE IS EASY • It is important to invest the time, resources, and effort to establish the culture, expectations, and infrastructure to support the implementation of an adaptive methodology. • Learning how to work in an agile way requires practice, commitment, clear and timely governance, and learning by doing. • For those with little or no experience, consider leveraging an agile approach for a smaller effort to demonstrate success and the team’s proficiency before moving on to something bigger.
  68. 68. Business Agility
  69. 69. MYTH 8: PURE AGILE IS THE ANSWER Agile Myths and Misconceptions
  70. 70. PURE AGILE IS THE ASWER • Employing agile practices will not be the solution to all project management and IT development issues encountered with a traditional approach, as agile may not meet the varying needs of the organization. • Doing anything new within an organization often introduces elements of additional project risk.
  71. 71. PURE AGILE IS THE ASWER • In this kind of environment, the implementation of agile practices and principles should be done pragmatically and take into consideration the real-world environment in which the project is managed and the system is developed.
  72. 72. PURE AGILE IS THE ASWER • To realize benefits associated with an adaptive methodology without an overhaul of the current environment, organizations can moderate the degree of change. • A project that takes place in a government context will likely be more successful if it integrates adaptive and user centered practices into its traditional waterfall approach. • This could be due to rules, regulations, or the organizational structures and cultural expectations that are heavily based on traditional waterfall processes.
  73. 73. PURE AGILE IS THE ASWER • For small changes, organizations can consider incorporating the following practices to be more adaptive: – Conduct and communicate lessons learned frequently and not just at the end of the project. – Have short (15 minute) daily stand-up meetings to provide a venue for project team members to communicate roadblocks they are experiencing, and for management to help resolve. – Manage each project team member’s work-in-progress. Set clear and realistic expectations for what work can be accomplished in a given period to not over-allocate resources.
  74. 74. MYTH 12: AGILE IS UNPREDICTABLE Agile Myths and Misconceptions
  75. 75. Agile is Evidence-Based Decision- Making • Requirements of future iterations based on user feedback from previous iterations. • Schedules are based on experience from previous iterations. • Architecture based on Spikes, not literature.
  76. 76. MYTH 14: AGILE CANNOT WORK WITH FIXED BUDGETS Agile Myths and Misconceptions
  77. 77. Fixed-Budget, Fixed-Scope • Typical Scenario: 1. Project budget and detailed requirements are set in beginning. 2. Requirements are achieved, with plenty of overtime, and usually delays. 3. System is unusable because of mismatch to business needs and bugs. 4. Additional project phases needed to accommodate actual business needs and fix bugs. 5. Repeat X times. 6. So what happened to the fixed budget?
  78. 78. In Agile … • Budgets are fixed. – Based on team composition and duration. • Business objectives are defined. – First to market? Win customers from competition? Reduce cost? Integrity • of financial transactions? Reduce human error? Reduce process time? Scope is variable. • Deliver something early that meets business needs. – Early ROI • Base succeeding iterations on feedback. – Customer uptake, stakeholder feedback, etc. • When project ends, organization is left with a valuable, useful product, within a fixed budget.
  79. 79. MYTH 15: AGILE WILL PREVENT PROBLEMS Agile Myths and Misconceptions
  80. 80. Agile will make problems visible, early and often • … so that they are easier to fix. – Expect to initially experience more problems, not less. • Waterfall reveals problems only later, when they are hard to fix.
  81. 81. MYTH 16: AGILE WILL PREVENT PROBLEMS Agile Myths and Misconceptions
  82. 82. Agile will make problems visible, early and often • … so that they are easier to fix. – Expect to initially experience more problems, not less. • Waterfall reveals problems only later, when they are hard to fix.
  83. 83. MYTH 17: AGILE MEANS NO MANAGERS Agile Myths and Misconceptions
  84. 84. «SELF ORGANIZING TEAMS» • “There’s a reason we use the term 'self- organizing' rather than 'self-organized' or 'self- managed.' • “That’s because it’s a process and a characteristic, not something that is done once and for all.” - Esther Derby
  85. 85. Self-Organizing Team: Mature, responsible, self- directed courageous people. – Aligned with company objectives – Solicits and provides feedback – Productivity visible to the organization – Works within financial and regulatory boundaries. To get there: Different people/teams need different management approaches. – Maturity, culture, motivation, discipline, awareness, etc.
  86. 86. MYTH 18: AGILE MEANS WEAK CONTROL Agile Myths and Misconceptions
  87. 87. TRADITIONAL CONTROL Status Reports • “We are 90% done.” – Based on what?
  88. 88. AGILE CONTROL
  89. 89. AGILE FEEDBACK • Working Features • Customer Satisfaction! • Test Coverage • Performance Tests • Velocity / Burndown Charts • Fine-grained commits, commit logs • Continuous Integration • Static Analysis – Cyclomatic Complexity – Coding Standards – Common Bugs – Technical Debt • Web Analytics
  90. 90. MYTH 19: YOU’RE AGILE OR YOU’RE NOT AGILE Agile Myths and Misconceptions
  91. 91. AGILE IS A CONTINUUM • No such thing as a “perfectly Agile” team. – Constraints – other departments, maturity of team members, clients, schedules, regulation, etc. – Continuous improvement – always something that can be done better • Be iterative in your Agile adoption. – Take small steps that will achieve quick wins. – What one value or practice can you adopt this week/month that will show visible gains?
  92. 92. falsedicotomie
  93. 93. falsedicotomie
  94. 94. 142 agilità
  95. 95. 143 disciplina
  96. 96. 144 disciplina
  97. 97. 145 agilità
  98. 98. 146 • Puoi essere disciplinato o agile. • Abbiamo bisogno di documentazione dettagliata di tutti i requisiti nel fase uno, oppure non possiamo conoscere obiettivi o sforzo. • Tutto sarà completato entro il 1 di maggio? • Le stime sono corrette oppure no? • Tutti i passi devono essere predeterminati, o non possiamo fare previsioni. • I gruppi auto-organizzati sono anarchia. • Dobbiamo assegnare tutte le attività alle risorse, oppure non pianifichiamo. • Facciamo TDD, quindi non facciamo nessuna modellazione.
  99. 99. dettaglio investimento modellazione documentazione continuum
  100. 100. Pitfall #1 Introducing agile without a clearly understood, agreed to, and articulated need. • Most organizations have plenty of room for improvement in their software development process.
  101. 101. Pitfall #1 • Who to Change? – When planning the introduction of agile approaches, we have far more than just the development team to consider. In fact, the successful adoption depends on a variety of stakeholders. • Executives – We need to win their support for the change. They are our enablers and obstacle removers.
  102. 102. Pitfall #1 • Project Sponsors – These people hold the budget and are powerful project influencers. If we want to get approval to try new approaches, we need to convince sponsors, too. • Managers – Managers are typically the resource controllers, so we really need them on board. They can be useful allies or roadblocks to adopting a new process.
  103. 103. Pitfall #2 Not engaging all the necessary stakeholders. • You don’t need to get formal written approval from each of these groups before introducing agile, but be aware the success of an agile introduction goes much beyond the development team. • Plan to interact and communicate often to win over as wide an audience as you can.
  104. 104. Pitfall #2 • What to Change? – What may require changing is likely to be wider ranging than you might think. • New methods of decision-making – Dictatorial, command-and-control decision-making does not fit agile approaches. When the team does more of their own local planning, we should have better ways of gaining consensus and resolving conflicts.
  105. 105. Pitfall #2 • Empowered teams – Are the project managers ready and willing to turn over iteration planning to the team? Is the team ready? – While iterative projects can be run as short waterfall projects, the real benefits of agile are only realized when we learn how to tap into the ownership, power, and accountability of empowered teams.
  106. 106. Pitfall #3 Not considering the full scope of changes required. • Agile change processes welcome late-breaking changes while many traditional change management processes are really “change prevention” processes. • However, some people will feel uncomfortable without the two-inch-thick binder of (out of date) requirements on their desk.
  107. 107. Pitfall #3 • Relating to superiors and/or staff members differently – The role of a project leader on an agile team is more a servant leadership role than command- and-control directing. Most good project managers already know their role is to make the project team successful. Project managers do not add a lot of business value to software products, so they need to support the team.
  108. 108. Pitfall #4 Not considering the social factor impacts of the change. . • However, for some traditional project managers, this downward-serving model and increased levels of team planning and decision-making can feel threatening.
  109. 109. Pitfall #4 • When to Change? – We must also consider the timing of the change to agile. Below are some potential scenarios to consider. • When there are problems with current processes – The current process consistently delivers late, over budget, or poorly accepted software.
  110. 110. Pitfall #4 • When new projects have unknown requirements – A project requirement like, “We need a customer self-service portal,” is likely to have a high rate of requirements evolution as the details become clear.
  111. 111. Pitfall #4 • When new projects occur with high technical risk – Examples include using new languages, unprecedented technology, and untested interfaces. Whenever there is high technology risk, the iterative nature of agile projects is great for reducing risks early in the lifecycle. • Time critical projects – Timeboxed iterations and feature prioritization are effective ways of ensuring the best possible delivery for a fixed deadline.
  112. 112. Pitfall #5 Assuming it is always best to use an agile approach. • We can also look to suitability filters to help guide us.
  113. 113. Pitfall #5 • What to consider – If, for example, our project has characteristics close to the inside of the chart, then an agile approach is suitable. – However, if our project scores toward the middle of the chart, a hybrid may be best. Scores around the plan-driven periphery indicate an agile approach may not be the best approach for the project.
  114. 114. CLEAN AGILE The Core of Agile
  115. 115. Craftmanship openware 28.09.2020
  116. 116. Craftmanship Manifesto
  117. 117. ModernAgile
  118. 118. Make People Awesome
  119. 119. Make People Awesome • Steve Jobs used to ask his colleagues, “What incredible benefits can we give to the customer? Where can we take the customer?” • In modern agile we ask how we can make people in our ecosystem awesome.
  120. 120. Make Safety a Prerequisite
  121. 121. Make Safety a Prerequisite • Safety is a basic human need and a key to unlocking high performance. • Modern Agile elevates it to a prerequisite, a foundational ingredient for success.
  122. 122. Experiment & Learn Rapidly
  123. 123. Experiment & Learn Rapidly • You can’t make people awesome or make safety a prerequisite if you aren’t learning. • We learn rapidly by experimenting frequently.
  124. 124. Deliver Value Continuously
  125. 125. Deliver Value Continuously • Anything that isn’t delivered isn’t helping anyone become more awesome or safe.
  126. 126. THANKS

    Sé el primero en comentar

Agile Myths and Pitfalls - talk at COCDE GARDEN

Vistas

Total de vistas

155

En Slideshare

0

De embebidos

0

Número de embebidos

1

Acciones

Descargas

4

Compartidos

0

Comentarios

0

Me gusta

0

×