Agile: Setting the Scene. February 7, 2017

Transcription

1 Agile: Setting the Scene February 7, 2017

2 Agile: Setting the Scene Robert Percival, Partner, Head of Technology Canada Riccardo D Angelo, Managing Director, Director of Legal Services, Accenture February 7, 2017

3 Agenda 1. Overview of Agile 2. Contracting for Agile projects 3. When to use Agile 4. Digital Case Study 5. Appendix: Agile Terminology 3

4 Overview of Agile

5 5 What Is It?

6 Agile Manifesto Working software over documentation Responding to change over following a plan 6

7 7 Traditional waterfall development model

8 8 Going sideways with a waterfall approach

9 Because.. REQUIREMENTS Changes over time DESIGN Takes too long You don t realize any value until the end of the project You leave the testing until the end You don t seek approval from the stakeholders until late in the day DEVELOPMENT TESTING Skipped MAINTENANCE 9

10 Agile development Concept Close 10

11 FDD (Feature Driven Development Agile development AGILE 11 Kanban SCRUM extreme Programming DSDM

12 12 Scrum - Key Roles

13 13 Scrum Summary

14 Scrum Methodology Product Owner Daily Sprint Meeting Product Backlog Sprint Planning Meeting Sprint Backlog 1-4 week Sprint Sprint Review Meeting Finished Product Legend: Scrum Master Product Owner Development Team 14

15 Waterfall vs. Agile Waterfall Strong dependency between phases. Changing requirements are difficult to address Progress is measured in deliverable artifacts (e.g. requirement specifications, design documents, test plans) Critical design flaws may be discovered too late during development Value is delivered at the end of the project and may not meet expectations Longer project timeframes Fixed Price Agile Change inherent to the process. Frequent insight on measurable progress aiming at continuous improvement Progress is demonstrated through tangible results working software Risks can be identified and remediated early on Customers are involved throughout the product development lifecycle Requirements are prioritized based on value Breaks a complex problem in manageable units of work T&M and other Price constructs 15

16 Contracting for Agile projects

17 Why traditional contracts do not work for Agile Traditional / waterfall contracts are flawed when applied to Agile projects because: X The requirements are fixed at the start of the project They mandate sequential development Scope, resources and schedule are fixed at the start of the project Testing is used as a contractual tool Beware hybrid methodologies 17

18 New concepts: contracting considerations for Agile Project / Product Vision Focuses attention on the desired outcome, and acts as a reference point Product Backlog Evolving statement of the customer s requirements based on the product vision Key roles and Personnel Issues Product Owner, Development Team, Scrum Master The Sprint Process Duration, Sprint planning meeting, daily meetings, Sprint review meetings, starting the next Sprint Velocity Ensuring the Product Backlog is being cleared as the project progresses Tracking progress against projected timeframes 18

19 Key Contracting Considerations Requirements & Scope View high level requirements not as fixed scope, but as roadmap. Typically requirements are recorded in the form of User Stories by adding them to the Product Backlog. Sample of User Story: As a <role>, I want <a feature>, so that I can <accomplish something> As a customer, I want to be able to browse books by genre, so that I can find the type of books I like. As a customer, I want to put a book into a shooping cart, so that I can buy it. As a product manager, I want to be able to track a customer s purchases, so that I can market specific books to her based on past purchases. Clearly document assumptions that underpin effort estimates. Avoid changes to User Stories during Sprint. 19

20 Key Contracting Considerations Deliverables Lack of scoping upfront means that it is difficult to make detailed contractual commitments around the deliverables to be produced. Deliverables, if any, should be defined within the Sprints and should conform to the User Stories. Contract should allow for throw-away development (in order to allow for changes). 20

21 Key Contracting Considerations Acceptance Agree to acceptance criteria prior to the start of a Sprint (i.e. sign-off criteria, Definition of Done). Deemed acceptance for any deliverable put into productive use or for lack of timely acceptance. Client should not be able to reject previously agreed and accepted Sprints. Defects should be dealt with in the next Sprint. Final sign-off at the overall end of any agile development in order to evidence agreement that service delivery has been completed. 21

22 Key Contracting Considerations Warranty In an iterative development, Agile methodology poses a particualr problem for the incorporation of warranty support. Often a warranty is limited to clearly defined product nonconformity (i.e. the deliverable is not in line with what was requested to be built). It is reasonable to give / request a warranty as to performance of services (i.e. professional and workmanlike manner) (vs. the deliverable). Possible approach: limit warranty period support to pre-defined # of days of support assistance after final sign-off (if provided). 22

23 Key Contracting Considerations Pricing Most common models: T&M or pre-agreed # of workdays effort. Hurdles with fixed price contracts: Work not capable of being completely defined up-front; Project success significantly reliant upon client involvement; and Nature of Agile - work is expected to change as it progresses. Hybrid approaches: T&M for project scoping (requirements gathering, user story creation, backlog creation, user story complexity estimation,) SOW fixed fee and T&M mix Fixed fee for fixed time & resource commitment to complete each sprint T&M for project management 23

24 When to use Agile

25 Requirements for Agile success Customer engagement, commitment and knowledge of Agile Executive level buy-in and organisational acceptance Challenges in overcoming waterfall / traditional concepts in Agile Clarity around priorities and time to market to capture market opportunities Service Provider experience Strong project management Empowerment of team members for rapid decision making Trust Recognition of different contracting framework and risk allocations Early and collaborative engagement with legal, contracts and procurement teams who have familiarity with Agile contracting 25

26 When to use Waterfall vs. Agile Waterfall Works well in an environment with: Fixed scope Defined set of requirements Defined set of technology Agile Works well in an environment with: Uncertain level of requirements An aligned goal High level of agreed user involvement Customer targets time-to-market and an ability to react quickly to market changes Customer needs to see how development progresses before fully committing Where there is a continual need to respond to Change 26

27 27 When to use Waterfall vs. Agile Bimodal IT

28 Wrapping it all up Agile development methodologies are a substantial departure from the more traditional waterfall model In the same way that Agile methodologies challenge the more traditional concepts of waterfall model software developments, contracting for Agile projects require new ways of thinking and different approaches to common contractual issues Agile projects have the potential to deliver faster and more flexible projects, with potentially shippable software iterations or features. Agile projects can spot and address problems early in the development cycle Organisations could consider: the use of Bi-Modal IT to retain waterfall development methodologies for core or substantial IT projects; or using hybrid agile development processes wrapped within a more formal waterfall process 28

29 Case Study

30 Case Study Digital Solution for Online Bookstore Client s Objectives: Client needs Service Provider to develop a digital platform for consumers to purchase books online Clients wants to pay Service Provider a fixed fee based on each digital order processed by the platform Client wants Service Provider to be responsible for the End to End solution, including hosting services Client also requires Service Provider s environment to be PCI compliant in order to process credit card transactions from consumers Challenges: The client does not have a good understanding of its own requirements Service Provider wants to leverage Agile development methodology, but Client has never used Agile Accenture will have to rely on a lot of third party providers to build and maintain the platform What are Key Success Factors and Contracting Considerations? 30

31 Case Study Digital Solution for Online Bookstore What are Key Success Factors and Contracting Considerations? Education process client needs to fully understand and commit to using the Agile methodology. Strong collaboration with the client and face to face communication Strong governance and project management Empowerment of team members to make decisions Clear definition of the roles and responsibilities (i.e. Scrum master, Product Owner, etc..) Robust documentation of the actual Agile process (i.e. sprints, sprint planning meetings, daily meetings, checkpoints, retrospectives, etc..) Checkpoints Inspect and Adapt mindset and process Pricing considerations t&m model or t&m for the design and build, with fixed fee for the run component. Proper documentation of high level requirements and of project assumptions Documentation of acceptance criteria (and definition of done) at the start of each Sprint. Description of how to deal with any defects. 31

32 Case Study Digital Solution for Online Bookstore Other Considerations relating to EaaS Model of this Engagement Understanding of the flow-up terms from third party providers, including the cloud provider Understanding of the applicability of the flow-down terms to third party providers Considerations around processing of credit card data, including PCI requirements Intellectual property and non-compete considerations Data Security considerations (especially in light of cloud services) 32

33 Appendix

34 Agile terminology how to speak the Agile language Key Concepts User Stories High level functional requirements provided by Client (e.g. system features/functions) written as short descriptions of the system behaviour in terms of user needs Product Backlog Prioritized list of functional and non-functional requirements (i.e. compilation of user stories) and issues controlled by the Product Owner Sprint Backlog List of tasks the team will work on in a Sprint, as defined in the Sprint Planning Meeting Sprint A set of time-boxed sprints of 2-4 weeks duration in which design, build and test activities occur iteratively Release 2 or more combined Sprints. Each Release will produce a potentially shippable (usable) product

35 Agile terminology how to speak the Agile language Key Concepts Project Initiation Initial phase of project which combines the Plan and Analyze phases of standard ADM Sprint 0 Sprint Planning Meeting Scrum Meetings Sprint Review Meeting Leads every Release and contains the plan and analyze tasks for the associated Release (i.e. determining the scope, schedule and number of spring in the release, their lengths and how they will be tested). Meeting held at the start of the Sprint to define and prioritize list of tasks the team will work on in the Sprint Daily stand up meetings held by team to coordinate activities, report on progress and plan the next 24 hours Conducted at the end of each Sprint and provides an opportunity to identify issues, demonstrate to the client the features that have been built in that Sprint, and to obtain sign-off of the deliverables.

36 Agile in Practice

37 Agile Contracting Models Agile Contracting Models Fixed Price T&M Variable Scope Fixed Capacity Apart from T&M, There are two fixed price models recommended based on our fixed price agile projects experience. Fixed Price Variable scope Fixed Price Fixed Capacity Copyright 2015 Accenture All rights reserved.

38 Option 1 Fixed Price Variable scope While the price of the project is fixed based on the planned velocity, the developed functionality would vary based on product backlog prioritization on the fly. Fixed price projects have defined and fixed requirements but agile projects have defined scope with flexible requirements which are implemented based on customer s priority and technical feasibility. Initiation and Sprint 0 duration would be longer in fixed price agile projects. These phases can follow T&M. Product vision, Release road map, Raw Epics and stories form the variable scope at the stage of contract writing. Acceptance criteria is must for each user story and the customer involvement is very much required throughout the project stages on 3Cs(Card, Conversation and Confirmation). Estimate the planned velocity using comparison of user stories through Triangulation. Existing Relationship New Relationship Include Team will a ceremony already have for check point meeting on scope control, hence Workshops change required management before is the mandatory. estimation Relevant domain and industry knowledge Understanding product vision Clear idea on the product vision and road map Discussing Release road map Application knowledge and required technical skills Application portfolio Knowledge Transition Copyright 2015 Accenture All rights reserved.

39 How Fixed Price Variable Scope Scrum Development Works Work ( Story Points) Time and Material Fixed Price Variable Scope Time and Material Initiation Sprint 0 Sprint 1 Sprint 2 Sprint 3.. Sprint N Deploy Release Check Point Meeting Product backlog creation with Epics and User stories. Business workshops to expand Epics High level architecture/desi gn/nfrs/pocs Finalize The Estimate to fix the price of the backlog to be delivered Product Backlog Priorities Release Burn Up 2000 Rating epics re-estimated Summary Reports Added 2 new Billing epics added Final regression and performance testing with user training. Release burn up with scope volatility. Story points completed Vs Pending Next Release Sprint # Must-Have Scope Story points to be delivered is fixed Scope Control and Change Management Copyright 2015 Accenture All rights reserved.

40 Option 2 Fixed Price Fixed Capacity While the price of the project is fixed based on the team s capacity to delivery n story points for every sprint, the developed functionality would vary based on product backlog prioritization on the fly. Initiation and Sprint 0 duration would be longer in fixed price agile projects. These phases can follow T&M. Product vision, Release road map, Raw Epics and Stories form the variable scope at the stage of contract writing Acceptance criteria is must for each user story and the customer involvement is very much required throughout the project stages on 3Cs(Card, Conversation and Confirmation). Estimate the planned velocity using comparison of user stories through Triangulation. Decide the number of story points to be delivered in every sprint/release with the fixed team capacity. Estimation of effort and cost can be arrived based on the available capacity and release dates. Customer will generally drive the scope control and change management tasks Copyright 2015 Accenture All rights reserved.

41 How Fixed Price Fixed Capacity Scrum Development Works Work ( Story Points) Time and Material Fixed Price Fixed Capacity Time and Material Initiation Sprint 0 Sprint 1 Sprint 2 Sprint 3.. Sprint N Deploy Release Check Point Meeting Product backlog creation with Epics and User stories. Business workshops to expand Epics High level architecture/desi gn/nfrs/pocs. Finalize estimate to fix the velocity of the team to deliver X Story Points in a sprint Product Backlog Priorities Release Burn Up 2000 Rating epics re-estimated Summary Reports Added 2 new Billing epics added Final regression and performance testing with user training. Release burn up with scope volatility. Story points completed Vs Pending Next Release Sprint # Must-Have Scope Capacity to deliver is fixed Scope Control and Change Management Copyright 2015 Accenture All rights reserved.

42 Fixed price models considerations Initiation and Sprint 0 estimation are completed by the client and the vendor. Terms and conditions for Agile contract on functional scope is not applicable. Change Management is strictly required to monitor varying scope and to advise on the coarse correction. Instead of milestone review, payment is scheduled based on Story Points Delivered Expectations on the customer and their Business users/smes are as below Prioritize user stories by business value and track them to be implemented in the order of priority. Participate in each sprint planning meeting to discuss/decide the features to be developed. Provide clarifications to the development team as and when required Participate in each sprint review meeting and provide timely feedback Attend check point meetings To advise the required functionality for the upcoming releases in order to deliver the high critical business features within the story points limited. To suggest on change request creation and approval for additional story points inclusion. Copyright 2015 Accenture All rights reserved.

43 Fixed price variations Fixed price SOW for each release is an alternate approach as we have the requirements ready for the estimation for the current release during the release planning. Fixed price SOW for each Release in case of 4-6 sprints (2 weeks) per release.. T&M will be used out of the Sprint for documentation such as Project Plan to cover one-time activities and expenses Shared Service Team will be T&M based while scrum team is part of Fixed Fee contract. Copyright 2015 Accenture All rights reserved.

44 How Fixed Price Variable Scope Scrum Development Works Work ( Story Points) Time and Material Fixed Price Variable Scope Time and Material Initiation Sprint 0 Sprint 1 Sprint 2 Sprint 3.. Sprint N Deploy Release Check Point Meeting Product backlog creation with Epics and User stories. Business workshops to expand Epics High level architecture/desi gn/nfrs/pocs Finalize The Estimate to fix the price of the backlog to be delivered Product Backlog Priorities Release Burn Up 2000 Rating epics re-estimated Summary Reports Added 2 new Billing epics added Final regression and performance testing with user training. Release burn up with scope volatility. Story points completed Vs Pending Next Release Sprint # Must-Have Scope Story points to be delivered is fixed Scope Control and Change Management Copyright 2015 Accenture All rights reserved.

45 Accenture Agile Framework at a glance Initiation: Create Product Backlog Project Road Map Sprint 0.. N: High level architecture and design Proof of concept as required Product Backlog refinement Release Plan Build and Test of the selected features Deploy Release: Additional testing Release retrospective

46 Product Backlog Integrated Release Backlog 1 Independent Release Backlog 1 Integrated Release Backlog N Independent Release Backlog N During Initiation : Requirements Hierarchy Business Users Product Owners Business Analysts Widgets Repository (Business objectives as inputs to PB) ) Joint Business Applications Session Release Roadmap Scrum Masters Test Leads Business workshops to create the product backlog till we get the list of user stories for a release or two. High level break up of each widget functionality Epics End to End Test Criteria Expanded epics to break further into feature sets and features Features Integration Test Criteria A piece of functionality that can be planned for a release or scrum User Stories Assembly Test Criteria A piece of functionality that can be delivered in a single scrum Child Stories Component Test Criteria Copyright 2015 Accenture All rights reserved.

47 During Sprint 0 : Estimate the Release Backlog Widgets PBIs Complexity Story Points Authenticate User Sign In UI Small 5 Widget Development Team Service Delivery Team Testing Services Team Sign In Process Medium 8 Forgot Password Medium 13 Sign Up 8 Display Details Bank Account Medium 13 Loans Complex 20 Deposits - FD Complex 20 Deposits - RD Complex 20 Product Backlog Grooming to refine and estimate the PBIs. Triangulation or Planning Poker techniques to estimate the story points. Release Backlog Adjustment based on number of story points planned to deliver in each release Shared Service Team Architect, Designer, BA, PM etc. 1) List the PBIs for each widget along with complexity based on the ranking or MoSCoW prioritization. 2) Features and User Stories can be estimated directly. 3) Epics and Feature sets with some unknowns to be referenced with the similar PBIs to come up with the estimates 4) Extrapolate the whole release backlog to arrive the total planned velocity for the release scope. 5) Repeat the process for every release backlog. 6) Sum up the story points to get the planned velocity for the overall contractual scope. 7) Add more story points based on additional testing and deployment cycles. 8) Use ADM for DA Estimators for the actual effort Copyright 2015 Accenture All rights reserved.

48 Feature Team 1 (Plan, Analyze, Design, Build, QA) Feature Team 2 (Plan, Analyze, Design, Build, QA) Feature Team 3 (Plan, Analyze, Design, Build, QA) Feature Team 4 (Plan, Analyze, Design, Build, QA) Features Delivered Vs Features Pending / Planned Velocity minus Delivered Velocity During Sprints 1 N : Feature Driven Development Release Widgets Features Team Integrated R1 Authenticate User Sign In Feature Team 1 Project Management Customer Involvement Integrated R1 Password Management Feature Team 1 Release Alignment Shared Services Integrated R1 Sign Up Feature Team 1 Integrated R1 Login NFRs Feature Team 1 Integrated R1 Display Details Bank Account Feature Team 2 Integrated R1 Loans Feature Team 2 Scrum of Scrums Integrated R1 Copyright 2015 Accenture All rights reserved. Deposits Feature Team 2

49 During Sprints 1 N : Scope Control in 2 Week Sprints Mon Tues Wed Thurs Fri Sprint Start Build Starts Sprint 0 or Previous Release in progress Sprint End Sprint Planning Product Backlog Refinement for Next Sprint Story Point Estimation for Next Sprint Sprint QA Test, Regression Test Execution Daily Stand-Up Release Planning Scope Control Additional check on Release backlog to maintain the required velocity. This can be achieved by removing equal points from the product backlog wherever change is accommodated. Copyright 2015 Accenture All rights reserved. Sprint Demo Sprint Retrospective Sprint Planning for Next Sprint User Story Tasks breakdown User Story Tasks effort estimation Sprint Low Level Design, Build and UT Sprint QA Test, Regression Test Execution Daily Stand-Up Sprint Low Level Design, DB Setup and Build Sprint QA Test Planning and Test Scripts Daily Stand-Up Build Ends Change Requests In case of additional story points in a sprint or release, change request needs to be created and approved. Change Management Change control board to monitor and track the changes and change requests. Maintain contractual scope of story points. Release burn up with the scope volatility is the key metric to be maintained and reported. Scope Control During sprint demo, the stakeholders to review from the scope volatility perspective and decide the subsequent release scoping accordingly

50 Coexistence of Legacy and Liquid Development teams Liquid Applications Development Legacy Applications Development Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint PSI PSI PSI Analyze Note: PSI and release timing are illustrative Design Build Test Deploy Release Integrated Release Independent Team Interactions Scenario Independent Team Interactions Low Dependency Team Interactions High Dependency Team Interactions Description Low Dependency Team Interactions High Dependency Team Interactions Mostly independent teams with few dependencies may come together at the end before a common release or release independently depending on end user impacts. Teams with low dependencies should synchronize at key milestones to ensure the proper integration of components, in addition to the interactions in scenario 1. Teams with high dependencies should synchronize at the team level on every sprint boundary at a minimum, in addition to the interactions in scenario 1 and 2. Copyright 2015 Accenture All rights reserved.

51 We believe business and leadership alignment, a strong governance framework and a robust change management approach to be the key pillars to a successful development Success Factors Implementation Considerations Common Pitfalls Leadership Alignment and Ownership Vision/ Definition of Success Establish and maintain sponsorship with committed leaders Emphasize the importance of the transformation and provide support Ensure executive participation to align work based on business priorities Develop a clear and defined target state for the transformation Define value-added metrics in addition to adoption metrics Be realistic about the transformation Lack of Executive Sponsorship and Participation Unclear measure of success Agile introduced in pilots only Resources / Cross Functional Skillsets Business Engagement/ Stakeholdering Dedicate business and IT resources Ensure critical teams are co-located to encourage communication Source diverse and cross-functional skill sets Ensure business partners are engaged and committed to meet the needed resource requirements Implement frequent feedback loops with business stakeholders Not selecting the right leaders Resources not dedicated to transformation Insufficient business involvement Collaborative Development and Dependency Management Change Management / Adoption, Comms, Training Maintain persistent teams to enhance and mature team performance Align teams (Agile and/or Waterfall) dependencies Create collaborative, cross-functional teams across business and IT Detailed readiness and change impact assessment Frequent enterprise wide communications to promote awareness & adoption Consistently evaluate and enhance workforce skillset Dissipating synergy due to nonpersistent teams Identify and Align Dependencies Limited employee awareness Lack of continuous improvement High-Quality Governance for a Lean Organization Revise traditional schedule and budget controls to manage dependencies Establish a de-centralized governance structure Set a common release cadence across the enterprise Overlaying traditional project management control over Agile

52 Agile Transformation: Expected Outcomes Experience and industry feedback show SW development transformation can have a dramatic impact on key ROI value drivers Improved time to market by 40-50% (Accenture Client) 30% - 75% Improved speed to market by 15-20% (Accenture Client) 37-50% faster time to market (QSM Research) Reduced time to market 20% (John Deere) Cut development lifecycle in half and tripled releases per year (Accenture ) 150% increase in YTD revenue from platform; added 5 new marketing channels in 1 year (digital, mobile, tablet, in-store, public APIs) More responsive to market changes and customer demands Improved assortments by streamlining development of new and differentiated products 15% - 40% ROI Value Drivers 20% - 50% 30% Improvement in R&D productivity (Accenture client) Reduced test and deployment costs by more than half (Accenture Client) $20M in savings (Accenture client) 300% increase in story points delivered per sprint (Accenture Client) 53% decrease in cost per point delivered (Accenture client) 50% reduction in coded defects per developer hour (Accenture Telco client) 25% reduction in customer reported defects Warranty Expense decrease of 50% (John Deere) 20 30% fewer defects found in FDAregulated devices (Abbot Labs) Production issues fell by 75% per release (Accenture client) 20% - 50%

53 Case Study: Digital Project Global Financial Organization Project Size of Effort Scope Results and Measurements Credit Card Portal 3 teams 3 locations (Dallas, Mexico City, Madrid) 2 years projects Created an Agile Execution and Delivery Approach for the organization Coordinated Solution Design and Elaboration sessions to get agreement on Story Points Feature Driven Delivery Coached/trained scrum team and leadership through the Agile Transformation Enable rapid deployment of new services into market using an Agile Framework. 42% increase in team velocity 20% defects rate reduction Released End-to-End Features in production environment Created the release planning approach and successfully managed Front & Backend (external/waterfall) dependencies Conducted Agile Change Management and increased Agile awareness in the organization Provided role based training

54 < / > Thank you!

55

56 Disclaimer Norton Rose Fulbright US LLP, Norton Rose Fulbright LLP, Norton Rose Fulbright Australia, Norton Rose Fulbright Canada LLP and Norton Rose Fulbright South Africa Inc are separate legal entities and all of them are members of Norton Rose Fulbright Verein, a Swiss verein. Norton Rose Fulbright Verein helps coordinate the activities of the members but does not itself provide legal services to clients. References to Norton Rose Fulbright, the law firm and legal practice are to one or more of the Norton Rose Fulbright members or to one of their respective affiliates (together Norton Rose Fulbright entity/entities ). No individual who is a member, partner, shareholder, director, employee or consultant of, in or to any Norton Rose Fulbright entity (whether or not such individual is described as a partner ) accepts or assumes responsibility, or has any liability, to any person in respect of this communication. Any reference to a partner or director is to a member, employee or consultant with equivalent standing and qualifications of the relevant Norton Rose Fulbright entity. The purpose of this communication is to provide general information of a legal nature. It does not contain a full analysis of the law nor does it constitute an opinion of any Norton Rose Fulbright entity on the points of law discussed. You must take specific legal advice on any particular matter which concerns you. If you require any advice or further information, please speak to your usual contact at Norton Rose Fulbright. 56