Integrating Agile into Your Company s SDLC. Frank Valerius February 1, 2012

Transcription

1 Integrating Agile into Your Company s SDLC Frank Valerius February 1, 2012

2 Perception vs Desired State Business perceives IS to be Rigid / inflexible Disconnected from business Slow to respond to change Slow to deliver software Weighed down by process Lacking innovation and improvement Ideally IS Is quick to react to new business opportunities Delivers more focused solutions; therefore, providing more value to the business Delivers higher quality Enables us to align with our business partners throughout development Provides greater visibility to progress and feedback

3 Overview The Effect of Delays Typical Project Plan: Startup Initiation Concept Func Tech Build / Test Deploy Typical Project Execution: Option A: Cut Build / Test / Deploy Time and Decrease Quality Startup Initiation Concept Func Tech Build / Test Deploy OR Option B: Extend Project End Date and Increase Cost Startup Initiation Concept Func Tech Build / Test Deploy

4 Overview Perception of Slow Delivery 12 Month Project (originally a 9 month project) Startup Initiation Concept Func Tech Build / Test Deploy Months 1-9: No Visible Value Month 10: Value Is Visible (Client begins testing) Month 12: Value Is Achieved

5 Overview Lack of Flexibility 12 Month Project (originally a 9 month project) Startup Initiation Concept Functional Tech Build / Test Deploy Theory: All requirements should be defined More requirements discovered. Conceptual changes More requirements discovered. Functional changes More requirements / problems discovered during build. Functional / Technical changes

6 6

7 Managing the Triple Constraint Schedule and Cost are fixed based on approved product backlog from Requirements and Conceptual Phase Scope is delivered in small iterations, allowing the most important work to be developed first When the budget and/or time run out, the project is either funded for additional work or the project is completed Change Request is issued when there is a change to Schedule and/or Cost 7

8 Agile Process Overview 4 key concepts to iterative development: 1. A A A A B B B C C C C Product Backlog 2. A A A A Sprint Backlog Sprint (iteration goals) Top priorities List of tasks Prioritized by team Detailed estimate 3. Sprint Time-boxed iterations Daily standups for communication Burndown to measure progress Working towards Sprint Goals Sprint Review / Retrospective 4. List of functionality Prioritized by business High level estimate User stories Demonstrates completed Sprint Goals Attended by team, Stakeholders and interested parties Retrospective - Team reflects on good and bad -> adjusts 8

9 Agile Concepts Co-location Time boxed deliverables (sprints) Daily 15 minutes standup Daily automated builds Customer demonstrations (sprint reviews) Team retrospective Embrace change Product Backlog User Stories 9

10 Product Backlog Up front defines desired functionality for a product it s possible that the functionality defined may not be delivered by the current project due to resources, time constraint and/or budget Prioritized by the business partner/owner based on greatest business value (must have, should have, could have) Reviewed during every Sprint Planning session by team and business partner Living document continuously updated through life of project 10

11 Agile Development Goals Deliver greatest value to the business sooner Deliver working software that meets the users business needs Eliminate gaps between what is delivered and what is expected Improve quality (build/design/test in quality during each sprint, not test in quality at the end) Improve time to deliver Improve IS/Business partnership 11

12 SDLC / Sprint Alignment Startup Initiation Requirements Functional Technical Build & Test Deploy Sprint 0 Sprint 1 Sprint 2 to Sprint N - 1 Sprint N Complete all Startup and Initiation Artifacts Approved Product Backlog 1st set of Functional Specs for Sprint 2 Dev. Complete All Other Artifacts Product Backlog Review Sprint Backlog Settlement Develop Sprint Deliverables Complete Artifacts for Developed Functions Sprint demonstration & sprint retrospective UAT Deploy Solution Complete All Artifacts. 12

13 Sprint 0 Identify Business Objectives Identify Stakeholders Project Kickoff meeting Develop & Publish Communication Plan Develop Project Management Plan 13

14 Sprint 1 Develop project backlog List functional requirements Develop high level estimates (Planning Poker) Prioritize backlog with business partner(s) Conceptual Develop and review with relevant partners Develop release plan Develop Sprint 2 detail plan Develop functional design for next sprint 14

15 Sprint 2 through N-1 Develop functional designs for next sprint Develop functionality for current sprint QA new functionality, regression test previously built functions Sprint Review Sprint Retrospective Product Backlog Review with Business Owner 15

16 Sprint N (Final Sprint) User Acceptance Test Performance Test Prepare and Deploy Release Sprint Retrospective 16

17 Deliverables by Sprint Sprint 0 Project Initiation Doc Sprint 1 Functional & Use Cases Sprint 2 Functional & Use Cases Sprint 3 Functional & Use Cases Sprint 4 Functional & Use Cases Sprint N-1 Sprint N Deliverables Agreement UAT Test Strategy Approved Product Backlog Code Code Code Code Project Signoff Project Mgmt Control Doc Release Plan Test Test Test Test Sponsor/User Survey Training Strategy Sprint 2 Detail Plan Sprint Review & Retrospective Sprint Review & Retrospective Sprint Review & Retrospective Sprint Review & Retrospective Team Evaluations Traceability Matrix Update Relevant Documents Update Relevant Documents Update Relevant Documents Update Relevant Documents Deployment Plan Conceptual Update Product Backlog Update Product Backlog Update Product Backlog Performance Test Go Live Sprint 3 Detail Plan Sprint 4 Detail Plan Sprint N - 1 Detail Plan Sprint N Detail Plan Iterate 17

18 Critical Success Factors Team co-location preferably IS team and business. At a minimum, the IS team is co-located. Visible evidence of goals, progress (burn-down chart) Daily stand-up with team to review progress, ownership of deliverables and identify barriers Daily business participation Business Team and IS Team must work together daily throughout the project. Executive Management Commitment PMO support Agile Mentor (consider utilizing an outside consultant) Demonstrations of Sprint Deliverables must mimic production look and feel. Not acceptable to ask business to imagine what it will look like in production. 18

19 Agile Adoption Risks Adoption Risk Viewed as a replacement for a company s SDLC Lacks control Business commitment Ship jumpers (revert back to their old ways) Comment Employ Agile practices within the SDLC. SDLC remains in place. The timing of some of the deliverables changes. When combined with SDLC artifacts, provides additional level of control by reviewing deliverables after each sprint. Each sprint review acts as its own gate review. The business must find the time to engage in the process and take ownership prioritizing the product backlog and making trade-offs. It s hard to break established habits, so it will be important to continually re-enforce the Agile process. 19

20 Agile Process Success Criteria Business Involvement Perception of IS Delivered Solution SDLC Deliverables Team Risk & Issue Mitigation Business owner attends daily standup and is accountable for their sprint deliverables. Business owner prioritizes the Product Backlog based on business value; must be willing to concede that all business functions are not required for project success and be able to make trade-off decisions. Business owner and stakeholders attend and actively participate in Sprint Reviews. Business perceives that they are the owner of the solution. Business perceives IS as being responsive to changes and feedback. Business feels better informed of the project s progress. Business feedback on solution fit aligns with project objectives The delivered solution is high quality and meets or exceeds the intended business value. Requirements with the highest business value are delivered first. All required SDLC deliverables are completed during the sprint for the business functions developed. Team has real ownership of the outcome (self organizing team) The project team is able to maintain an acceptable work/life balance. Risks and issues are mitigated in the sprint in which they are identified. PMO Project metrics (variance to budget, quality test scores, etc) adhere to acceptable standards. 20

21 Project Success Criteria Budget Scope Time Quality Client Satisfaction The project will be completed within +/- ##% of approved budget The project will deliver at a minimum all must have functionality as defined and prioritized by the business owner. The project will complete within the time approved for the project. If all must have functionality is delivered early, additional backlog items prioritized by the business may be implemented filling the remaining time. Continuous User Acceptance Users and QA will be continuously testing the delivered application functionality and identifying issues, enhancements and functional errors. This shift in testing greatly enhances application quality and user adoption. UAT should be a formality, rather than the business first look at the solution. UAT is occurring throughout the project rather than at the end. Measurement: No significant functional changes identified during UAT No critical or severe defects identified during UAT Client satisfaction survey will indicate high satisfaction to scope, quality, timeliness and business value delivered. SDLC Deliverables All SDLC deliverables met as agreed upon with the PMO. 21

22 Pros and Cons of Using Agile Pros Deliver business value (working software/prototypes) early (first development iteration is demonstrable (typically sprint 2 or 3) More flexibility to absorb change than traditional waterfall methods Avoid significant rework by only doing just-in-time detailed design Raise quality by moving testing forward in the process (test based design) Testing is integrated with development, daily builds. Become responsive by supporting scope adjustments every iteration Increase estimating accuracy by working in small chunks Decrease risk by always having working software Increase team moral by dropping the death marches Small successes build momentum with the business and project team Short-interval control project management. identify problems early Cons Agile can be hard on the product owner who has a lot of responsibility. Misunderstanding of the agile practices may lead to team burnout due to an irrational culture of urgency. Agile is misunderstood it is not a license to skip documentation, design and testing. 22

23 Roles & Responsibilities Role Description Product Visionary The Product Visionary is the champion of the product and its long-term strategy and business value. Assigns Product Owner Serves as escalation point on the business side, above the Product Owner Interacts with the Executive Sponsors Monitors product milestones to ensure deliverables match overall intent Product Owner (Business Partner) Project Manager Scrum Master (Project Lead) The Product Owner is responsible for ensuring that the functionality that is prioritized, developed and implemented meets the needs of the business and derives business benefits particularly in terms of return on investment. Defines the features of the product, decides on release date and content Aggregates input from users, stakeholders and other interested parties to form a single view of the prioritized requirements for the system. Is responsible for the profitability of the product (ROI) Prioritizes features according to business value Can change features and priority at the end of every Sprint Accepts or rejects work results The Project Manager is responsible for the overall project delivery. They are responsible for: Ensuring the SCRUM Master, Product Owner and Team Members are working together effectively Managing the financial requirements of the project to include budget, overall estimates, resource plans, etc. Managing delivery against major milestones and objectives Obtaining resources and ensuring they re being properly managed Removing all project barriers Inviting appropriate people to the daily scrum, iteration review and planning meetings Communicating with all relevant parties; including the Stakeholders, Steering Committee, upper management The ScrumMaster above and beyond anything has to enforce the rules. A ScrumMaster is a Leader and Facilitator and is responsible for: Improving the lives and productivity of the development team by facilitating creativity and empowerment Enabling close cooperation across all roles and functions and removing barriers Shielding the team from external interferences and removing "Impediments" Ensuring that the process is followed Removing the barriers between development and the customer so that the customer directly drives the functionality developed Teaching the customer how to maximize ROI and meet their objectives through Scrum Improving the engineering practices and tools so each increment of functionality is potentially shippable Driving accountability from Team Leads and Team Members 23