Your SlideShare is downloading. ×
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Agile Technology Delivery Process   Mr
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Agile Technology Delivery Process Mr

3,319

Published on

An Agile Technology Delivery Process for large projects and organisations

An Agile Technology Delivery Process for large projects and organisations

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,319
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
120
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

    ×