Agile Technology Delivery Process Mr

  • 3,051 views
Uploaded on

An Agile Technology Delivery Process for large projects and organisations

An Agile Technology Delivery Process for large projects and organisations

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
3,051
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
108
Comments
0
Likes
3

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
  • System Components grow each iteration until all the priority requirements are deliveredThe core enabling requirements are built first then the critical high priority requirements, then the medium priority requirements etc.It is important not to over engineer the component to meet all possible needs as the medium and low priority requirements may never be delivered.
  • You can rank the requirements in a software project in order of priority. Often a project does not know all the requirements or their business value at the start of a projectIf a high value requirement is discovered during a project it can be quite hard to fit in.Sequential projects deliver all the requirements in one big bangAgile projects deliver the high value requirements in order of priority each release until the business decides to stop the project or funds run out.Scope is flexible in Agile projects.
  • Initially teams may over or underestimate the amount of work they can do in an iteration but over time they become accurate.
  • A sequential process requires us to define the solution in detail, up front, when our knowledge of the requirements and solution is poorest. In reality many requirements change during the course of the project as the business discovers what they really want.This same is true for the architectural solution. While it may seem that we can define the full technical solution up front typically many major technical issues arise during the project which must be solved at the time. This is also true if you are deploying a software package. Often the team software package is a much poorer fit to the requirements than expected at purchase leading to a much larger amount of customization than expected. Also the vendor team often has much less experience with the software package than expected leading to a lot of problems later on.We would be much better off if we defined a guiding architecture and deferred detailed solution decisions until the last possible, responsible moment.Because of all these unknowns software development is more like designing a new car model than like building one in a factory. Software development is a product design and engineering process not a manufacturing process.
  • A component team is a group of up to 5 to 10 people who analyze, design, build and test a whole group of related requirements that are delivered. This leads to a high performance team that can focus on and resolve issues quickly.Team members wear multiple hats. For instance the team lead may be the system designer and lead developer and the onsite rep may be the lead tester and system analyst. One of the developers may focus on automating tests. Another developer may specialize in developing or using common components. Testing should be separate to development to provide greater accountability and rigor and to allow for a different point of view on the requirements.Each team provides representatives to cross functional teams that are responsible for developing and integrating cross functional plans, requirements, designs, components and tests.This is the vendor development team.Circulate offshore team members into onsite rep to increase knowledge sharing.
  • Analysis and design is done one iteration before build and testThe design team pulls the top priority unplanned requirements from the requirements back log and designs them in the one month planning release.The build team pulls the top priority designed requirements from the requirements back log and builds them in the one month build release.Each team agrees at the start of the month what scope they can commit to deliver next month with the fixed resource pool available.Management cannot extend the duration or cost of the monthly release If towards the end of the month the team finds that it cannot deliver all the requirements it committed to then they remove the incomplete requirements from the iteration release and park them for completion in a later iteration. If the team finds that they have completed all the requirements early then they can add the next priority requirements to the iteration.A requirements is only done when it has been accepted by the users and is part of a build packaged for release. requirements that have been built but not passed acceptance testing are not done.
  • Requirements are broken down into things that can be developed and deployed during an iteration. They can include non functional requirements and enabling tasks like set up test environment and deploy build or user guide or operations manual. Each requirements goes through the following statuses:NewAnalysisDesignBuildTestAcceptanceDeployCompleted
  • Each component team runs the daily SCRUM process defined here.In a scrum meeting the team lead goes through the requirements / task list and asks each person how they are going, when they will finish, what issues they are facing and what they will do next.The issues are left until the end of the meeting for further discussion by all interested parties.Developers are expected to take turns managing the daily build. Whoever breaks the daily build becomes the new build manager with responsibility for fixing it.Each cross functional team will run a similar meeting every couple of days with one representative from each component team.The business team could also run a similar process and report back through one representative to the design team.
  • Changes are easy to manage. They are simply identified, added to the requirements list and analyzed and designed in the next planning iterationIf a change is a top priority it can be analyzed next month and delivered the month after.All changes are prioritized according to business value.
  • Each component team contributes specialist members to cross functional teams to co-ordinate and develop common plans, requirements, designs, tests and components.For large projects the cross functional team lead is a full time role. For medium or small projects the cross functional team lead is a member of a function team
  • Larger agile teams are formed by structuring the teams into cross functional component teams. Each team contributes specialist members to cross functional teams to co-ordinate and develop common plans, requirements, designs, tests and components.Each team members primary reporting relationship is to their component team lead with a secondary reporting line to the cross functional team leads.For outsourced projects the component teams report to the vendor development manager and the functional leads report to the project manager. Would be good to have Agile coach and training to help teams transition to this approach.
  • Management and planning overhead is reduced by reducing effort wasted developing long detailed documents which quickly become outdated and arguing about changes.A stable resource model provides greater predictability for the vendor and for the customer.It allows knowledge retention, continuity of resources and enhanced learning over time.This provides faster response through greater knowledge.
  • Each offshore component team has an onsite representative who forms part of the onsite design team. The onsite rep is responsible for communicating with the offshore team. The offshore team members will take turns being the onsite rep to improve communication and knowledge transfer.
  • A fixed release calendar makes it much easier to synchronize interdependent projects
  • Analysis and design is done one iteration before build and testThe design team pulls the top priority unplanned requirements from the requirements back log and designs them in the one month planning release.The build team pulls the top priority designed requirements from the requirements back log and builds them in the one month build release.Each team agrees at the start of the month what scope they can commit to deliver next month with the fixed resource pool available.Management cannot extend the duration or cost of the monthly release If towards the end of the month the team finds that it cannot deliver all the requirements it committed to then they remove the incomplete requirements from the iteration release and park them for completion in a later iteration. If the team finds that they have completed all the requirements early then they can add the next priority requirements to the iteration.A requirements is only done when it has been accepted by the users and is part of a build packaged for release. requirements that have been built but not passed acceptance testing are not done.
  • Analysis and design is done one iteration before build and testThe design team pulls the top priority unplanned requirements from the requirements back log and designs them in the one month planning release.The build team pulls the top priority designed requirements from the requirements back log and builds them in the one month build release.Each team agrees at the start of the month what scope they can commit to deliver next month with the fixed resource pool available.Management cannot extend the duration or cost of the monthly release If towards the end of the month the team finds that it cannot deliver all the requirements it committed to then they remove the incomplete requirements from the iteration release and park them for completion in a later iteration. If the team finds that they have completed all the requirements early then they can add the next priority requirements to the iteration.A requirements is only done when it has been accepted by the users and is part of a build packaged for release. requirements that have been built but not passed acceptance testing are not done.
  • Analysis and design is done one iteration before build and testThe design team pulls the top priority unplanned requirements from the requirements back log and designs them in the one month planning release.The build team pulls the top priority designed requirements from the requirements back log and builds them in the one month build release.Each team agrees at the start of the month what scope they can commit to deliver next month with the fixed resource pool available.Management cannot extend the duration or cost of the monthly release If towards the end of the month the team finds that it cannot deliver all the requirements it committed to then they remove the incomplete requirements from the iteration release and park them for completion in a later iteration. If the team finds that they have completed all the requirements early then they can add the next priority requirements to the iteration.A requirements is only done when it has been accepted by the users and is part of a build packaged for release. requirements that have been built but not passed acceptance testing are not done.

Transcript

  • 1. Agile Development
    By Murray Robinsonwww.linkedin.com/in/murrayrobinson
    Copyright and Intellectual Property retained by Murray Robinson.
    1
  • 2. Copyright and Intellectual Property retained by Murray Robinson.
    2
    What is Agile Development?
    Agile development is a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between cross-functional teams
    Agile development is a well defined delivery process that has been proven to reduce time to market, delivery risk and costs for many organisations and projects.
    Agile development applies “Lean Production” principles and techniques to software development
    Agile development can give us a sustainable competitive advantage by allowing us to deliver quality IT systems faster than our competitors at a lower cost
    2
  • 3. Copyright and Intellectual Property retained by Murray Robinson.
    3
    Agile Development is a family of lean, iterative software development methodologies
    Lean Production
    RUP
    Scrum
    FDD
    Iterative
    OOD
    TDD
    Design
    Patterns
    Continuous Integration
    XP
  • 4. Copyright and Intellectual Property retained by Murray Robinson.
    4
    In Agile projects requirements are delivered in priority order in a series of small fixed iterations
    Iteration 4
    Iteration 3
    Iteration 2
    Iteration 1
    System Component A
    4
  • 5. Copyright and Intellectual Property retained by Murray Robinson.
    5
    Agile projects deliver high value features early!
    75%
    Business Value
    Release
    Iteration
    5
  • 6. Copyright and Intellectual Property retained by Murray Robinson.
    6
    Agile project progress is clear and predictable
    Velocity
    Iteration
    6
  • 7. Copyright and Intellectual Property retained by Murray Robinson.
    7
    Agile implementation plan
    Seek Executive support and funding for an Agile change Management Project
    Define Agile processes and deliverables in detail
    Apply Agile in a trial project
    Seek Quality Group endorsement for Agile
    Develop an Agile training program
    Launch Agile
    7
  • 8. Problems with a traditional sequential system engineering process
  • 9. Copyright and Intellectual Property retained by Murray Robinson.
    9
    The problem from the business point of view
    IT projects take much longer than the business want
    IT projects cost much more than the business expect
    IT can’t commit to budgets and delivery dates until the start of build
    IT don’t understand the user experience
    The business are expected to sign off requirements and design when they’re not sure their completely right
    IT make it very hard to make changes during the project
    Fixed price, time and cost projects are anything but
    IT Projects often have major cost and schedule blow outs which require major scope reductions or budget and time increases to bring them back on track
    IT infrastructure seems to be a major source of project delays and problems
    9
  • 10. Copyright and Intellectual Property retained by Murray Robinson.
    10
    10
    The problem from the IT point of view
    Business set unrealistic budget and schedule targets up front before IT know how long things will take and how much they will cost
    Funding approval is a very slow process
    Business take a long time to sign off requirements and design
    Business constantly change requirements
    Business wont prioritise requirements unless project goes off track
    Business don’t understand that IT projects are complex and high risk
    Vendors and infrastructure groups need very close management to ensure delivery
    Major IT project blowouts are often caused by infrastructure delays
    IT projects are dependent on infrastructure and other projects which may run very late
  • 11. Copyright and Intellectual Property retained by Murray Robinson.
    11
    A sequential system development process has many handoff’s
    11
  • 12. Copyright and Intellectual Property retained by Murray Robinson.
    12
    Handoff’s between groups cause a lot of wasted time and effort
    12
  • 13. Copyright and Intellectual Property retained by Murray Robinson.
    13
    A sequential project wrongly assumes that the business knows all the requirements in detail up front
    13
  • 14. Copyright and Intellectual Property retained by Murray Robinson.
    14
    14
    A traditional sequential project can take a long time to deliver business benefit
  • 15. Copyright and Intellectual Property retained by Murray Robinson.
    15
    Sequential Projects deliver value at the end.Agile projects deliver value earlier
  • 16. Copyright and Intellectual Property retained by Murray Robinson.
    16
    Waterfall project assumptions are not realistic
  • 17. The Agile Development Process in More Detail
  • 18. Copyright and Intellectual Property retained by Murray Robinson.
    18
    Agile Assumptions
    Systems grow and evolve over time
    Stakeholders can’t fully define what they want until they see it
    Business requirements change as the market changes
    All IT projects have to trade off scope against time, budget and quality
    The risk of project failure increases linearly as the size of the project increases
    There are always a lot of unexpected business and technical issues that must be resolved as you go along
    Most delays and waste are caused by handoffs from one group to another
    There are substantial communication delays and costs when teams are separated by organization, location and culture
    Co-located, Cross functional project teams resolve issues much faster than specialized functional teams in separate locations
    The best way to reduce delivery risk is to integrate and deliver as often as possible
    18
  • 19. Copyright and Intellectual Property retained by Murray Robinson.
    19
    The Agile Manifesto
    In Agile projects we value
    Individuals and interactions over processes and tools
    Working software over comprehensive documentation
    Customer collaboration over contract negotiation
    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 left more.
    19
  • 20. Copyright and Intellectual Property retained by Murray Robinson.
    20
    Agile Principles
    Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
    We welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
    We deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
    Business people and developers must work together daily throughout the project.
    We build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    Working software is the primary measure of progress.
  • 21. Copyright and Intellectual Property retained by Murray Robinson.
    21
    Agile Principles
    The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
    Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    Continuous attention to technical excellence and good design enhances agility.
    Simplicity--the art of maximizing the amount of work not done--is essential.
    The best architectures, requirements, and designs emerge from self-organizing teams.
    At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
  • 22. Copyright and Intellectual Property retained by Murray Robinson.
    22
    Agile Development applies the principles of Lean Production to software development
    Eliminate waste
    Amplify learning
    Keep your options open
    Deliver as fast as possible
    Empower the team
    Build integrity in
    Optimize the Whole
    Put the customer first
    Continually Improve the Process
    22
  • 23. Copyright and Intellectual Property retained by Murray Robinson.
    23
    Agile uses the Plan, Do, Check, Act cycle in every iteration
  • 24. Copyright and Intellectual Property retained by Murray Robinson.
    24
    Agile uses Object Oriented Design to reduce the cost of change
    User Class
    User Products Class
    View User Process
    View User UI
    Product Class
    24
  • 62. Copyright and Intellectual Property retained by Murray Robinson.
    25
    Agile Projects use co-located cross functional teams to minimize handoff delays
    Team Lead / Scrum Master
    SME / Business Analyst
    Architect / System Designer
    Team members play multiple roles
    Test Analyst
    UI / Component Developer
    DBA / Sys Admin / Network Eng
    25
  • 63. Copyright and Intellectual Property retained by Murray Robinson.
    26
    Overall Agile Funding Process
    Fund Solution Delivery
    Fund Solution Vision
    26
  • 64. Copyright and Intellectual Property retained by Murray Robinson.
    27
    Solution Vision
    Solution Vision Plan
    Initial Use Case Model
    Initial Object Model
    Initial System Model
    Initial UI Design Concepts
    Product Roadmap
    Initial Prioritised Feature List
    Project Estimate
    Business Case
    Initial Project Plan
    Solution Vision Lessons Learned
    Solution Vision Process Changes
  • 65. Copyright and Intellectual Property retained by Murray Robinson.
    28
    Solution Delivery
    Iteration 1
    Iteration 2
    Iteration 3
    Iteration 4
    Analysis &
    Design
    Analysis &
    Design
    Analysis &
    Design
    Analysis &
    Design
    Design,
    Build &
    Test
    Design,
    Build &
    Test
    Design,
    Build &
    Test
    Design,
    Build &
    Test
    UAT &
    Deploy
    UAT
    UAT &
    Deploy
    UAT
    Release 1
    Release 2
    Agile projects deliver batches of features in short, regular iterations
    28
  • 66. Copyright and Intellectual Property retained by Murray Robinson.
    29
    Iteration Analysis & Design
    Iteration Plan
    Iteration Use Cases
    Iteration Activity Diagrams
    Detailed Feature List
    Iteration Graphic Design
    Iteration Class Diagrams
    Iteration System Model
    Iteration Wireframes
    Iteration System and Acceptance Test Cases
    Iteration Test Plan
    Iteration Lessons Learned
    Iteration Process Changes
  • 67. Copyright and Intellectual Property retained by Murray Robinson.
    30
    Iteration Design & Build
    Updated Iteration Plan
    Updated Feature List
    Automated Xunit Tests
    Automated Regression Tests
    UML Sequence Diagrams
    UI Code
    Object Oriented Code
    Technical Proof of Concept
    Test Results
    Progress Charts
    Iteration Lessons Learned
    Iteration Process Changes
  • 68. Copyright and Intellectual Property retained by Murray Robinson.
    31
    Each iteration each agile team pulls the top priority items off the feature list
    High level features
    Detailed features
    Built & tested features
    Deployed features
    Component team 1
    Deployment team
    Analysis &
    Design team
    Component team 2
    31
  • 69. Copyright and Intellectual Property retained by Murray Robinson.
    32
    The Feature list
    32
  • 70. Copyright and Intellectual Property retained by Murray Robinson.
    33
    Agile Teams have a Daily Cycle
    33
  • 71. Copyright and Intellectual Property retained by Murray Robinson.
    34
    Agile Change management is fast and efficient
    If a change is a top priority it can be analyzed in one iteration and delivered the one after.
    34
  • 72. Copyright and Intellectual Property retained by Murray Robinson.
    35
    Agile deliverables are lean, visual and iterative
    Project Management
    Business Analysis
    Product Management
    Design and Build
    UI Design
    Testing
    Use Case Model
    UML Object Model
    UML System Model
    Product Roadmap
    Release Plan
    UI Concepts
    Test Plan
    Prioritised Feature List
    Project Budget
    Business Case
    Graphic Design
    UML Class Diagrams
    List of Test Cases
    Technical Proof of Concept
    Use Cases
    UML Sequence Diagrams
    Project Plan
    System and Acceptance Test Cases
    Automated Xunit Tests
    Comm’s Plan
    Wireframes
    Automated Regression Tests
    UI Code
    Object Oriented Code
    Technical Proof of Concept
    UML Activity Diagrams
    Progress Charts
    Training Package
    Test Results
    Deployment Package
    Comm’s Package
    35
  • 73. Copyright and Intellectual Property retained by Murray Robinson.
    36
    Senior Management play a critical role
    A fast moving agile project will reveal many blockages in the organisation that are slowing progress for all teams
    Senior management need to ask their agile teams everyday “what blockers are you having that you can’t resolve yourself”
    Management should focus on removing these blockers as soon as possible at the root cause level
    Often the best way to solve these problems is to move specialists from different groups and organizations into co-located, cross functional project teams
    And to streamline business processes to minimize queues of work
  • 74. Copyright and Intellectual Property retained by Murray Robinson.
    37
    Business Benefits of Agile
    Delivers high priority requirements to market in months
    Removes a lot of delays and overhead from the process
    Allows us to commit to a fixed budget and schedule early
    Projects can get to a funded business case sooner
    Allows lots of early feedback from users
    Doesn't require the business to sign off everything up front
    Easy to make high priority changes during the project
    Provides a predictable delivery speed and cost
    37
  • 75. Copyright and Intellectual Property retained by Murray Robinson.
    38
    IT Benefits of Agile
    Allows IT to commit to a fixed budget and schedule early
    Funding is quicker and easier to manage
    Ensures signoffs are done quickly and regularly
    Handles requirement changes quickly and easily
    Ensures requirements are prioritized properly every month
    Ensures that issues are found and resolved early
    Cross functional teams bring the different groups much closer together
    Reduces project dependency issues
    38
  • 76. Copyright and Intellectual Property retained by Murray Robinson.
    39
    Criteria for Agile projects
    Use an Agile scorecard to determine if projects are suitable for Agile development
    Implement strategies to address issues that might block Agile development.
    For example if the team has no Agile experience, the vendors methods are hostile to agile processes and the customer is largely unavailable then it would not be a good candidate for Agile development
    We can address these issues by bringing on an experienced Agile coach, changing to a vendor whose methods support agile development and getting the customer to appoint a full time product manager/ BA
    39
  • 77. Copyright and Intellectual Property retained by Murray Robinson.
    40
    Agile Scorecard
  • 78. Copyright and Intellectual Property retained by Murray Robinson.
    41
    A Documented Agile Process can be Methodology compliant
    Compliant with PMBOK v4
    Compliant with TQM processes
    Compliant with ITIL 3.0
    Compliant with CMMI
    41
  • 79. Copyright and Intellectual Property retained by Murray Robinson.
    42
    Agile Definitions
  • 80. Copyright and Intellectual Property retained by Murray Robinson.
    43
    Agile Definitions
  • 81. Copyright and Intellectual Property retained by Murray Robinson.
    44
    Scrum Process Summary
  • 82. Copyright and Intellectual Property retained by Murray Robinson.
    45
    Acceptance Test Driven Design & Development
    Automated Unit Tests
    Add a unit test
    Run test
    Pass
    Fail
    Refactor code
    Change code
    Automated UI Tests
    Automated Acceptance Tests
    User Story
    Acceptance Criteria
    Automated Performance Tests
    Exploratory Testing
  • 83. Agile Structure for Large Projects with Offshore Vendors
  • 84. Copyright and Intellectual Property retained by Murray Robinson.
    47
    Large projects are divided up into components which are delivered by small agile teams of 7 people
    Component team 1
    Component team 7
    Component team 2
    Management team
    Analysis team
    Onsite team
    Product team
    Testing team
    Design team
    Component team 3
    Component team 6
    Common Component team
    Infrastructure team
    Component team 5
    Component team 4
    Agile component teams synchronize by contributing members to cross functional project teams.
  • 85. Copyright and Intellectual Property retained by Murray Robinson.
    48
    A large project team is organized by feature set and function
    48
  • 86. Copyright and Intellectual Property retained by Murray Robinson.
    49
    Agile projects have a stable resource profile
    Vendor Build & Test Team
    Vendor design team
    IT project team
    Business project team
    49
  • 87. Copyright and Intellectual Property retained by Murray Robinson.
    50
    Offshore teams have onshore representatives who liaise with other onshore teams on their behalf
    50
  • 88. Copyright and Intellectual Property retained by Murray Robinson.
    51
    Vendors are engaged on a capped T&M with a constant resource plan and fixed price per month
    51
    51
  • 89. Copyright and Intellectual Property retained by Murray Robinson.
    52
    Related Agile projects are synchronized by a fixed release calendar
    Project 1
    Project 2
    Project 3
    Synchronized release
    52
  • 90. Appendix
  • 91. Copyright and Intellectual Property retained by Murray Robinson.
    54
    Strengths and weaknesses of a well defined systems engineering process
    Strengths
    Weaknesses
    Well defined process
    Enforces that a consistent system development process is followed
    Can be tailored
    Provides deliverable templates
    Provides a training program
    Has a Quality Governance framework
    Regular quality audits
    Agreed and understood by most users
    Most projects that use the standard process deliver something
    Sequential process that takes much longer and costs far more than the business want
    Heavy documentation overhead
    Very resistant to change
    Lots of delays for reviews and approvals
    Requires a big up front design effort when our knowledge is poorest
    Many projects have major cost or schedule blow outs and have to reduce scope to get back on track
    Lot of wasted time and effort designing things that are changed or de-scoped
    The critical build process is often a black box
    54
  • 92. Copyright and Intellectual Property retained by Murray Robinson.
    55
    Agile development is based on an iterative development process.
    Iteration 1
    Iteration 2
    Iteration 3
    Iteration 4
    In an ideal process the agile team does all SDLC activities during one iteration
    Requires a very experienced, co-located, cross functional team onsite
    Analysis &
    Design
    Analysis &
    Design
    Analysis &
    Design
    Analysis &
    Design
    Build &
    Test
    Build &
    Test
    Build &
    Test
    Build &
    Test
    UAT &
    Deploy
    UAT
    UAT &
    Deploy
    UAT
    Release 1
    Release 2
    High priority scope changes can be implemented in 1 iteration
    55
  • 93. Copyright and Intellectual Property retained by Murray Robinson.
    56
    Solution Delivery
    Iteration 1
    Iteration 2
    Iteration 3
    Iteration 4
    Analysis &
    Design
    Analysis &
    Design
    Analysis &
    Design
    Analysis &
    Design
    Build &
    Test
    Build &
    Test
    Build &
    Test
    Build &
    Test
    UAT &
    Deploy
    UAT
    UAT &
    Deploy
    UAT
    Release 1
    Release 2
    Agile projects deliver batches of features in regular, short iterations
    56
  • 94. Copyright and Intellectual Property retained by Murray Robinson.
    57
    Sometimes the testing is done one iteration afterwards
    Iteration 1
    Iteration 2
    Iteration 3
    Iteration 4
    A slower more cautious approach
    Analysis &
    Design
    Analysis &
    Design
    Analysis &
    Design
    Analysis &
    Design
    Build &
    Test
    Build &
    Test
    Build &
    Test
    Build &
    Test
    UAT &
    Deploy
    UAT
    UAT &
    Deploy
    UAT
    Release 1
    Release 2
    High priority scope changes can be implemented in 3 iterations
    57