how agile can we go? lessons learned moving from waterfall
TRANSCRIPT
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
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
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
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
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/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
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
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
6/2/15
9
Delivering Value
Validation
6/2/15
10
Stakeholder Involvement
Self Organization
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
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
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
6/2/15
14
Planning: Story Maps
MVP Line
Time
More -‐ Im
portance -‐ 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
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
2 1 1
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?
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
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
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
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
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
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
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
6/2/15
23
Other Scrum Stuff
What Else?
Scrum of Scrums
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
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
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
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/
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