The document discusses integrating Agile practices into a company's software development lifecycle (SDLC). It outlines key Agile concepts like product backlogs, sprints, and daily standups. It provides examples of how sprints can align with the SDLC and what deliverables each sprint produces. Critical success factors and potential adoption risks are also covered.

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 Startup Initiation Concept Design Func Design Build / Test Tech Design Deploy Startup Initiation Concept Design Func Design Build / Test Tech Design Deploy Startup Initiation Concept Design Func Design Tech Design Build / Test Deploy Typical Project Plan: Option A: Cut Build / Test / Deploy Time and Decrease Quality Option B: Extend Project End Date and Increase Cost OR Typical Project Execution:

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

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

7. Managing the Triple Constraint Schedule and Cost are fixed based on approved product backlog from Requirements and Conceptual Design 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

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

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

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

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

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

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

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

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

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

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

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.

19. Agile Adoption Risks Adoption Risk Comment Viewed as a replacement for a company’s SDLC Employ Agile practices within the SDLC. SDLC remains in place. The timing of some of the deliverables changes. Lacks control 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. Business commitment The business must find the time to engage in the process and take ownership prioritizing the product backlog and making trade-offs. Ship jumpers (revert back to their old ways) It’s hard to break established habits, so it will be important to continually re-enforce the Agile process.

20. Agile Process Success Criteria Business Involvement 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. Perception of IS 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 Delivered Solution The delivered solution is high quality and meets or exceeds the intended business value. Requirements with the highest business value are delivered first. SDLC Deliverables All required SDLC deliverables are completed during the sprint for the business functions developed. Team Team has real ownership of the outcome (self organizing team) The project team is able to maintain an acceptable work/life balance. Risk & Issue Mitigation 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.

21. Project Success Criteria Budget The project will be completed within +/- ##% of approved budget Scope The project will deliver at a minimum all “must have” functionality as defined and prioritized by the business owner. Time 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. Quality 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 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.

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.

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) 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 Project Manager 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 Scrum Master (Project Lead) 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