Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Integrating agile into sdlc presentation pmi v2


Published on


Published in: Technology, Business
  • Be the first to comment

Integrating agile into sdlc presentation pmi v2

  1. 1. Integrating Agile into Your Company’s SDLC Frank Valerius February 1, 2012
  2. 2. Perception vs Desired State <ul><li>Business perceives IS to be … </li></ul><ul><li>Rigid / inflexible </li></ul><ul><li>Disconnected from business </li></ul><ul><li>Slow to respond to change </li></ul><ul><li>Slow to deliver software </li></ul><ul><li>Weighed down by process </li></ul><ul><li>Lacking innovation and improvement </li></ul><ul><li>Ideally IS … </li></ul><ul><li>Is quick to react to new business opportunities </li></ul><ul><li>Delivers more focused solutions; therefore, providing more value to the business </li></ul><ul><li>Delivers higher quality </li></ul><ul><li>Enables us to align with our business partners throughout development </li></ul><ul><li>Provides greater visibility to progress and feedback </li></ul>
  3. 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. 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. 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
  6. 6.
  7. 7. Managing the Triple Constraint <ul><li>Schedule and Cost are fixed based on approved product backlog from Requirements and Conceptual Design Phase </li></ul><ul><li>Scope is delivered in small iterations, allowing the most important work to be developed first </li></ul><ul><li>When the budget and/or time run out, the project is either funded for additional work or the project is completed </li></ul><ul><li>Change Request is issued when there is a change to Schedule and/or Cost </li></ul>
  8. 8. Agile Process Overview <ul><li>4 key concepts to iterative development: </li></ul>2. Sprint Backlog <ul><li>Sprint (iteration goals) </li></ul><ul><ul><li>Top priorities </li></ul></ul><ul><ul><li>List of tasks </li></ul></ul><ul><ul><li>Prioritized by team </li></ul></ul><ul><ul><li>Detailed estimate </li></ul></ul>Sprint A A A A B B B C C C C 1. Product Backlog <ul><li>List of functionality </li></ul><ul><li>Prioritized by business </li></ul><ul><li>High level estimate </li></ul><ul><li>User stories </li></ul>A A A A 4. Sprint Review / Retrospective <ul><li>Demonstrates completed Sprint Goals </li></ul><ul><li>Attended by team, Stakeholders and interested parties </li></ul><ul><li>Retrospective - Team reflects on good and bad -> adjusts </li></ul>3. <ul><li>Time-boxed iterations </li></ul><ul><li>Daily standups for communication </li></ul><ul><li>Burndown to measure progress </li></ul><ul><li>Working towards Sprint Goals </li></ul>
  9. 9. Agile Concepts <ul><li>Co-location </li></ul><ul><li>Time boxed deliverables (sprints) </li></ul><ul><li>Daily 15 minutes standup </li></ul><ul><li>Daily automated builds </li></ul><ul><li>Customer demonstrations (sprint reviews) </li></ul><ul><li>Team retrospective </li></ul><ul><li>Embrace change </li></ul><ul><li>Product Backlog </li></ul><ul><li>User Stories </li></ul>
  10. 10. Product Backlog <ul><li>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 </li></ul><ul><li>Prioritized by the business partner/owner based on greatest business value (must have, should have, could have) </li></ul><ul><li>Reviewed during every Sprint Planning session by team and business partner </li></ul><ul><li>Living document – continuously updated through life of project </li></ul>
  11. 11. Agile Development Goals <ul><li>Deliver greatest value to the business sooner </li></ul><ul><li>Deliver working software that meets the users business needs </li></ul><ul><li>Eliminate gaps between what is delivered and what is expected </li></ul><ul><li>Improve quality (build/design/test in quality during each sprint, not test in quality at the end) </li></ul><ul><li>Improve time to deliver </li></ul><ul><li>Improve IS/Business partnership </li></ul>
  12. 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. 13. Sprint 0 <ul><li>Identify Business Objectives </li></ul><ul><li>Identify Stakeholders </li></ul><ul><li>Project Kickoff meeting </li></ul><ul><li>Develop & Publish Communication Plan </li></ul><ul><li>Develop Project Management Plan </li></ul>
  14. 14. Sprint 1 <ul><li>Develop project backlog </li></ul><ul><ul><li>List functional requirements </li></ul></ul><ul><ul><li>Develop high level estimates (Planning Poker) </li></ul></ul><ul><ul><li>Prioritize backlog with business partner(s) </li></ul></ul><ul><li>Conceptual Design </li></ul><ul><ul><li>Develop and review with relevant partners </li></ul></ul><ul><li>Develop release plan </li></ul><ul><li>Develop Sprint 2 detail plan </li></ul><ul><li>Develop functional design for next sprint </li></ul>
  15. 15. Sprint 2 through N-1 <ul><li>Develop functional designs for next sprint </li></ul><ul><li>Develop functionality for current sprint </li></ul><ul><li>QA new functionality, regression test previously built functions </li></ul><ul><li>Sprint Review </li></ul><ul><li>Sprint Retrospective </li></ul><ul><li>Product Backlog Review with Business Owner </li></ul>
  16. 16. Sprint N (Final Sprint) <ul><li>User Acceptance Test </li></ul><ul><li>Performance Test </li></ul><ul><li>Prepare and Deploy Release </li></ul><ul><li>Sprint Retrospective </li></ul>
  17. 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. 18. Critical Success Factors <ul><li>Team co-location – preferably IS team and business. At a minimum, the IS team is co-located. </li></ul><ul><li>Visible evidence of goals, progress (burn-down chart) </li></ul><ul><li>Daily stand-up with team to review progress, ownership of deliverables and identify barriers </li></ul><ul><li>Daily business participation </li></ul><ul><ul><li>Business Team and IS Team must work together daily throughout the project. </li></ul></ul><ul><li>Executive Management Commitment </li></ul><ul><li>PMO support </li></ul><ul><li>Agile Mentor (consider utilizing an outside consultant) </li></ul><ul><li>Demonstrations of Sprint Deliverables must mimic production “look and feel”. Not acceptable to ask business to “imagine” what it will look like in production. </li></ul>
  19. 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. 20. Agile Process Success Criteria Business Involvement <ul><li>Business owner attends daily standup and is accountable for their sprint deliverables. </li></ul><ul><li>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. </li></ul><ul><li>Business owner and stakeholders attend and actively participate in Sprint Reviews. </li></ul>Perception of IS <ul><li>Business perceives that they are the owner of the solution. </li></ul><ul><li>Business perceives IS as being responsive to changes and feedback. </li></ul><ul><li>Business feels better informed of the project’s progress. </li></ul><ul><li>Business feedback on solution fit aligns with project objectives </li></ul>Delivered Solution <ul><li>The delivered solution is high quality and meets or exceeds the intended business value. </li></ul><ul><li>Requirements with the highest business value are delivered first. </li></ul>SDLC Deliverables <ul><li>All required SDLC deliverables are completed during the sprint for the business functions developed. </li></ul>Team <ul><li>Team has real ownership of the outcome (self organizing team) </li></ul><ul><li>The project team is able to maintain an acceptable work/life balance. </li></ul>Risk & Issue Mitigation <ul><li>Risks and issues are mitigated in the sprint in which they are identified. </li></ul>PMO <ul><li>Project metrics (variance to budget, quality test scores, etc) adhere to acceptable standards. </li></ul>
  21. 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 <ul><li>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. </li></ul><ul><li>Measurement: </li></ul><ul><li>No significant functional changes identified during UAT </li></ul><ul><li>No critical or severe defects identified during UAT </li></ul>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. 22. Pros and Cons of Using Agile <ul><li>Pros </li></ul><ul><ul><li>Deliver business value (working software/prototypes) early (first development iteration is demonstrable (typically sprint 2 or 3) </li></ul></ul><ul><ul><li>More flexibility to absorb change than traditional waterfall methods </li></ul></ul><ul><ul><li>Avoid significant rework by only doing just-in-time detailed design </li></ul></ul><ul><ul><li>Raise quality by moving testing forward in the process (test based design) </li></ul></ul><ul><ul><li>Testing is integrated with development, daily builds…. </li></ul></ul><ul><ul><li>Become responsive by supporting scope adjustments every iteration </li></ul></ul><ul><ul><li>Increase estimating accuracy by working in small chunks </li></ul></ul><ul><ul><li>Decrease risk by always having working software </li></ul></ul><ul><ul><li>Increase team moral by dropping the “death marches” </li></ul></ul><ul><ul><li>Small successes build momentum with the business and project team </li></ul></ul><ul><ul><li>Short-interval control project management. identify problems early </li></ul></ul><ul><li>Cons </li></ul><ul><ul><li>Agile can be hard on the product owner who has a lot of responsibility. </li></ul></ul><ul><ul><li>Misunderstanding of the agile practices may lead to team burnout due to an irrational culture of urgency. </li></ul></ul><ul><ul><li>Agile is misunderstood…it is not a license to skip documentation, design and testing. </li></ul></ul>
  23. 23. Roles & Responsibilities Role Description Product Visionary <ul><li>The Product Visionary is the champion of the product and its long-term strategy and business value. </li></ul><ul><li>Assigns Product Owner </li></ul><ul><li>Serves as escalation point on the business side, above the Product Owner </li></ul><ul><li>Interacts with the Executive Sponsors </li></ul><ul><li>Monitors product milestones to ensure deliverables match overall intent </li></ul>Product Owner (Business Partner) <ul><li>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. </li></ul><ul><li>Defines the features of the product, decides on release date and content </li></ul><ul><li>Aggregates input from users, stakeholders and other interested parties to form a single view of the prioritized requirements for the system. </li></ul><ul><li>Is responsible for the profitability of the product (ROI) </li></ul><ul><li>Prioritizes features according to business value </li></ul><ul><li>Can change features and priority at the end of every Sprint </li></ul><ul><li>Accepts or rejects work results </li></ul>Project Manager <ul><li>The Project Manager is responsible for the overall project delivery. They are responsible for: </li></ul><ul><li>Ensuring the SCRUM Master, Product Owner and Team Members are working together effectively </li></ul><ul><li>Managing the financial requirements of the project to include budget, overall estimates, resource plans, etc. </li></ul><ul><li>Managing delivery against major milestones and objectives </li></ul><ul><li>Obtaining resources and ensuring they’re being properly managed </li></ul><ul><li>Removing all project barriers </li></ul><ul><li>Inviting appropriate people to the daily scrum, iteration review and planning meetings </li></ul><ul><li>Communicating with all relevant parties; including the Stakeholders, Steering Committee, upper management </li></ul>Scrum Master (Project Lead) <ul><li>The ScrumMaster above and beyond anything has to enforce the rules. A ScrumMaster is a Leader and Facilitator and is responsible for: </li></ul><ul><li>Improving the lives and productivity of the development team by facilitating creativity and empowerment </li></ul><ul><li>Enabling close cooperation across all roles and functions and removing barriers </li></ul><ul><li>Shielding the team from external interferences and removing &quot;Impediments&quot; </li></ul><ul><li>Ensuring that the process is followed </li></ul><ul><li>Removing the barriers between development and the customer so that the customer directly drives the functionality developed </li></ul><ul><li>Teaching the customer how to maximize ROI and meet their objectives through Scrum </li></ul><ul><li>Improving the engineering practices and tools so each increment of functionality is potentially shippable </li></ul><ul><li>Driving accountability from Team Leads and Team Members </li></ul>