How Agile Can We Go? Lessons Learned Moving from Waterfall
- 1. 6/2/15 1 How Agile Can We Go? Lessons Learned Moving from Waterfall Max McGregor -‐ 2 June 2015 What Are You Today? SW Development Methodology Waterfall Scrummerfall Scrum Lean Agile Kanban Other
- 2. 6/2/15 2 The Way We Were Analysis Requirements Design Implementation Testing Maintenance Planning: Agile vs. Plan-‐Driven Agile Plan-‐Driven Adaptive Planning Predictive Planning People-‐first Process-‐first • Success = delivering working software frequently, at a sustainable pace that gives our customers value and competitive advantage • Success = on time & on budget, according to the plan • Dependency on exact requirements knowledge and requirements stability http://martinflowler.com/articles/newMethodology.html
- 3. 6/2/15 3 Predictive vs. Iterative Analysis Design Development Testing Deployment Handoffs Lack of Commitment Compromised Quality Analysis Design Dev Test Deploy Lack of Ownership Task Switching Delays Less Productive Shared Commitment Shared Ownership Shared Focus More Productive Quality Built In Finds Risk Early Easily Allows for Change Scrum Framework 4-‐6 Iterations 2 Week Sprint Daily Standup Product Owner (PO) creates, organizes, prioritizes and manages a backlog of epics, feature requests, etc. Prioritized Release Backlog Prioritized Sprint Backlog Deliverable Working Increments Mid-‐Sprint Planning
- 4. 6/2/15 4 Release Cycle Meetings What When Who Time Box Backlog grooming & prioritization Pre-‐cycle Product Owners Ongoing Release Planning/Kickoff Pre-‐cycle All team members & managers (Dev & QA) 1-‐2 Days Backlog grooming & prioritization Pre-‐cycle Each scrum team & managers 60-‐90 Min Sprint planning First Day of each Sprint Each scrum team & managers 60-‐90 Min Sprint standup Daily Each scrum team & managers 15 Min Scrum of Scrums Tue & Wed One member from each scrum team & managers 15 Min Sprint review Last Day of each Sprint Each scrum team, dept. managers & stakeholders 30-‐60 Min Sprint retrospective Last Day of each Sprint Each scrum team (no managers) 30-‐60 Min Bug reviews Weekly or as needed Managers, architects, POs, CS, SMs 30-‐60 Min Product release status Weekly Managers, Scrum Masters, Product Owners 30-‐60 Min Mid-‐sprint planning/grooming Middle of each Sprint All team members – managers optional 30-‐60 Min Got Agile? How Much? Agile Fluency
- 5. 6/2/15 5 A Team’s Path Through Agile Fluency We write code We focus on value We deliver value We optimize value We optimize for systems Team Culture Shift Team Skills Shift Org Structure Shift Org Culture Shift Note: Not a maturity model. Based on Agile Fluency by James Shore and Diana Larsen © 2012 A Team’s Path Through Agile Fluency § How a team develops software when it’s under pressure § Team fluency, not individual or organization § Depends on management structures, relationships, and organizational culture © 2012 Agile Fluency by James Shore and Diana Larsen
- 6. 6/2/15 6 A Team’s Path Through Agile Fluency Benefit Investment Core Metric Time to achieve Achievement Rate ★ Greater visibility into teams’ work; ability to redirect. Team development and work process design. Team regularly reports progress from a business value perspective. 2-‐6 months 45% ★★ Low defects and high productivity. Lowered productivity during technical skill development. Team ships on market cadence. 3-‐24 months 35% ★★★ Higher value deliveries and better product decisions. Social capital expended on incorporating business expertise into team. Team provides concrete business metrics. 1-‐5 years 5% ★★★★ Alignment with organizational goals; synergistic effects. Significant effort in establishing organizational culture; inventing new practices. Team reports how its actions impact the overall organization. unknown very few Note: Not a maturity model. © 2012 James Shore and Diana Larsen What can hold you back? Impediments to Agile
- 7. 6/2/15 7 The Release Delivery Time Frame Deliverables Resources Something Has To Give Agility Impediments: SW Complexity § Enterprise Software § Fat Client or On Premise Installation § Many Architectural Dependencies § Many Remote Team Members § 3rd Party Integrations § Security & Compliance Requirements § Legacy/Multiple Version Support § High Liability § Large Databases (that begin with “O”) § Legacy Browser Support § Web Apps § Light Consumer § Low Risk § Low Liability § Limited Platforms § Co-‐located Teams § SAAS/Cloud Based Agility Impediments
- 8. 6/2/15 8 Agility Impediments § Lack of Management Support § Lack of Trust § Poor communications § Lack of Transparency § Managers hold team members accountable instead of teams holding each other accountable § The teams and organization do not adhere to or believe in the Agile Principles § Attrition Stuck in a rut? Kick some butt! Where Are We? (Survey Examples) Soliciting Feedback
- 9. 6/2/15 9 Delivering Value Validation
- 10. 6/2/15 10 Stakeholder Involvement Self Organization
- 11. 6/2/15 11 Continuous Improvement Lowest Rated Areas 4.2 We utilize non-‐solo development techniques, such as peer programming 4.4 We have a demo sandbox where stakeholders can get hands on experience with our completed solutions 4.7 We incorporate static code analysis in our builds 5.0 We utilize test automation 5.0 We have regular communication with our personas to understand their business problems and workflow 5.4 Our Epics and Stories clearly describes the business problem and acceptance criteria 5.5 We actively work on blockers identified in retrospectives 5.5 We track our progress of adopting improvements to our process 5.6 We demo completed increments of work to stakeholders to get their feedback 5.6 My team knows its velocity
- 12. 6/2/15 12 What We Learned § Planning was too long § Stories were too big or not adequately defined § Not allowing enough time for research, learning and technical debt § Estimates were off, velocity was unknown § Quarterly releases are a challenge § Points of friction between product owners and the teams § Work in progress is an issue – non iterative § Product complexity makes it difficult at times Areas We Want To Improve § Better clarification on Epics and Stories § Calculate Team Velocities based sprint histories § Better understanding of and communication with our personas § Actively work on blockers identified in retrospectives § Continue to work on test automation
- 13. 6/2/15 13 Putting Your Feedback Into Action Continuous Improvement Release Planning: How Much? § Too many stories and too much detail at the beginning of release planning could result in wasted work and reduced learning through experience § Learn as you go by completing the MVP stories that are highest risk / value then get rapid feedback that can be fed back into the next Sprint § Iterative and emergent design: learning and designing by doing can avoid the waist caused by over planning Bob Fischer, Big Visible Agile Coach
- 14. 6/2/15 14 Planning: Story Maps MVP Line Time More -‐ Importance -‐ Less MVP: Minimum Viable Product as determined by the Product Owner Planning: UX Mockups EPIC STORY MOCKUP STORIES TASKS Custom Fields “As a system user I need custom fields for device objects that allow me to keep track of their related meta data.” Create Object wMockup wMenu wCreate Controller wCreate View wCreate Model wTest Case wCode Review wUnit Test wQuality Testing w Documentation Object Class Association wCreate New Class wUnit Test wTest Case wCode Review wQuality Testing String Input Validation wCreate Validation Logic wUnit Test wTest Case wCode Review wQuality Testing Fields Preview wMockup wMenu wCreate Controller wCreate View wCreate Model wUnit Test wTest Case wCode Review wQuality Testing w Documentation Data Entry for Devices wMockup wMenu wCreate Controller wCreate View wCreate Model wUnit Test wTest Case wCode Review wQuality Testing w Documentation
- 15. 6/2/15 15 Story Structure Example Title User Portal Work Object Types Description As Bill I want a way to configure the Self-‐Service Portal from the main console that allows me to control the features and behaviors of how the portal behaves and it’s role based restrictions Size 13 Points Notes The work object will contain all fields and values for each label, including instructions for configuration Acceptance Criteria 1. Portal will establish an HTTPS connection 2. UI provides…. 3. UI text associated with the labels… 4. Portal text…. 5. Session timeout is configurable in seconds 6. Etc. 21 13 8 5 3 Sprint Planning § Prioritized backlog stories are defined and sized by the team § Stories are assigned to the 2 week Sprint to the amount of work the team agrees to commit to (average team velocity and other impediments should be considered, like PTO, holidays, etc.) § Task and task hours are defined for each story § Large stories should be scrutinized for redefinition into smaller ones § Consideration made for QA involvement early in the iterative process § Consideration for documentation team – when can they capture screens?
- 16. 6/2/15 16 Story Sub Task Examples Dev: Configuration Schema 3 Hrs Dev: New API Calls 2 Hrs Dev: Object Tasks 2 Hr QA: Write Test Cases – for Work Objects 12 Hrs QA: Execute Test Cases for Work Objects 8 Hrs UX: Mockup for Certificate Task Object 14 Hrs User Assistance: Tool Tip text for Download function 10 Hrs Measuring, Assessing, Training, Improving Velocity
- 17. 6/2/15 17 Scrum Team Metrics -‐ Burndown § Story task hours burn down -‐ Current target goal -‐ Original target -‐ Current actual § Story points burn up -‐ Current target points -‐ Actual points § Team Velocity = average points per sprint Scrum Team Metrics -‐ Velocity § Amount of completed work increments (features/ stories that are done) in a Sprint § i.e. the number of story points completed § Average velocity over multiple sprints § Represents the team’s ability to turn ideas into completed stories/new functionality © 2015 Mountain Goat Software
- 18. 6/2/15 18 Should Points Include Bugs? § Velocity points may or may not include: -‐ Bug Fixing -‐ Refactoring -‐ Research and other activities not directly related to delivering new features § Just keep it consistent § Most teams only assess points on new features – those stories that deliver new value to the customer Team Velocities Team A Team B • Bill and Ted on PTO • Stan Moved to CA • Penny Resignation • Stacy on PTO for two weeks • Holidays in Europe IMPEDIMENTS Average Sprint 1 Sprint 2 Sprint 3 Points Bugs Average Sprint 1 Sprint 2 Sprint 3
- 19. 6/2/15 19 Continually Remind Everyone § Agile is an ideology not a methodology § Adaptive approach to doing work § There are many ways to do Agile § Putting the principles and values into practice is Agile § Frameworks such as Scrum are “agile” as long as they support the Agile principles § First step to Agile is to understand the values and principles Note: They Are Principles Not Methods 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software 2. We welcome changing requirements, even late in the development cycle, if it gives our customers value and competitive advantage 3. Our goal is to deliver working software frequently 4. We work daily with product owners throughout the project 5. We trust our talented and motivated teams to get the job done 6. We strive for sustainable development by maintaining a constant pace indefinitely 7. Working software is our primary measure of progress and success 8. Whenever possible we convey information face-‐to-‐face 9. We continually commit attention to technical excellence and good design 10. We strive for simplicity by perfecting the art of maximizing work not done 11. We believe the best architectures, requirements and designs come from self-‐ organized teams 12. We regularly review our process, reflect on how to become more effective and adjust our behavior and process accordingly
- 20. 6/2/15 20 MVP: Minimum Viable Product/Feature § Historically: 50% of everything we build rarely or never gets used by the customer § “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” § “Our goal is to deliver working software frequently.” § Ask hard questions: what is the minimum amount of work/code/testing we need to do in order to deliver a minimum viable product in the shortest time possible that provides value § Meets all quality gates (Definition of Done) WIP: Work in Progress § Focus on business value, rather than figuring out the optimal plan to get to done § Everything added to WIP creates potential dependencies that can keep us from shipping § Too much WIP = lots of work with nothing to show for it but a death march of missed ship dates, late nights, weekends, energy drinks and pizza § Make sure the highest value items work first using a single stream flow, completing one thing at a time § Mind the WIP to Become Effective, Not Merely Efficient Howard Deiner, Big Visible Agile Coach
- 21. 6/2/15 21 Team Release Cycle Calendars For each team track: § PTO § Holidays § Sprint Iterations § Meetings § Release Activities & Deadlines Communication Effectiveness § Face-‐to-‐face wins! § Add 2x effort to support remote members § Use video conference where possible to help § If you can reach out right away, do it! § Don’t rely on the bug notifications or email to always get the job done
- 22. 6/2/15 22 Daily Standup § What did you finish yesterday? § What will you complete today? § Any blockers? § Update the Story/Task board § Review the burn-‐down charts § Identify any risks and dependencies § Be strict on the time box! 15 Minutes Affective Standups § Help teams stay focused on the work and what they are doing to complete the story at the top of the list § If a topic seems to be taking over the time, stop the conversation to complete the standup then finish the topic after or schedule another meeting § The team should walk away from standup knowing what was completed yesterday and what everyone is working today day
- 23. 6/2/15 23 Other Scrum Stuff What Else? Scrum of Scrums
- 24. 6/2/15 24 Scrum of Scrums § Multiple team consolidation of story cards § Shows cross-‐team dependencies § Shows progress and status for each team Statu n Not Started l In Progress «Completed § Once or twice a week for 15 minutes or less § One representative from each team + Managers § Out in an open space for company transparency Sprint Reviews § Demo and review completed stories (deliverable work increments) § Invite stake holders (PS, SE, CS, PM, managers) § Solicit feedback § Product owner helps the team incorporate the feedback based on current or new priorities § Demo is typically presented by the product owner
- 25. 6/2/15 25 Sprint Retro § Includes just the team and no managers § Using an activity to draw feedback, the team identifies what went right and what held them back or inhibited them from being more effective § Team picks the top 2-‐3 things they want to improve § Team makes a plan for how those things will be implemented in the next sprint or release This Sprint Was… J L Bug Reviews § Issues found in one or more currently released versions are qualified by and logged by engineers or customer service reps § Customer reported bugs are tracked as their own issue type and are usually prioritized over bugs found internally based on severity § Product Owner continually reviews and prioritizes bugs for their team(s) § Product Owners, Managers and a Representative from CS review unassigned bugs to determine severity and team assignment § Bug Review is held once per week for 1 hour or less, more often if needed
- 26. 6/2/15 26 Definition of Done for Sprints Task/Action Quality Checks Code Complete ü Written ü Peer reviewed ü Unit tested ü Version control ü Meets coding standards ü Runs on all platforms Acceptance Test Passed ü Definition of tests exists ü Quality Assurance Complete ü Automated functional tests User Assistance Materials Complete ü Help, UI/Tool Tips text completed ü Guides completed ü Readme completed ü Error Messages completed ü Doc reviewed ü PDFs printed UX Accepted ü Design specifications met ü Functionality validated Product Owner Accepted ü MVP features demoed, validated and accepted ü Other features demoed, validated and accepted Integration Tested as Specified ü Acceptance criteria met ü Installation validated ü Upgrades validated System Tested as Specified ü Acceptance criteria met Configuration Managed Definition of Done for the Release ü Regression tested ü Integration tested ü System tested ü Configuration managed ü Archive & escrow completed ü Release readme file completed ü Technical handoff to the Venafi field completed (PS, SE, CS) ü Customer webinar scheduled ü Training, marketing & text collateral completed
- 27. 6/2/15 27 Resources § http://www.plans-‐for-‐retrospectives.com § http://tastycupcakes.org/ § http://www.seenowdo.com/ § http://martinfowler.com/articles/agileFluency.html § https://weisbart.com/ § http://research.microsoft.com/pubs/56015/ AgileDevatMS-‐ESEM07.pdf § http://www.ambysoft.com/surveys/ howAgileAreYou2013.html § http://store.mountaingoatsoftware.com/
- 28. 6/2/15 28 General Disclaimer This document is not to be construed as a promise by any participating company to develop, deliver, or market a product. Venafi, Inc. makes no representations or warranties with respect to the contents of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Venafi, Inc. reserves the right to revise this document and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. All Venafi marks referenced in this presentation are trademarks or registered trademarks of Venafi, Inc. in the United States and other countries. All third-‐party trademarks are the property of their respective owners. © 2015 Venafi