Using Agile methodology, the speaker aims to transform doubting customers into raving fans by demonstrating how Agile can help deliver projects that meet expectations. Agile practices like iterative development, collaboration, and transparency can help improve delivery track records, build confidence through demonstrable working software, and actively engage customers for feedback. The speaker outlines their company's Agile practices for planning, management, delivery, and team roles to provide a model for others to deploy on their own Agile teams.
Cracking the ‘Business Process Outsourcing’ Code Main.pptx
Using Agile Methodology to Deliver Projects That Transform Customers from Doubters into Raving Fans
1. Using Agile Methodology to
Deliver Projects that Transform
Customers from Doubters into
Raving Fans
Michael Harris
VP of Information Technology, Ecommerce Inc.
2. Goals
• Demonstrate How Agile Can Help to
Transform Customer Perception
• Share Insight Into The Ecommerce Agile
Approach
• Provide You With a Set of Practices That
Can Be Deployed on Your Own Agile Teams
3. Who is the Customer?
From Dictionary.com
1. a
person who purchases goods or services from
another;buyer; patron.
2.Informal . a person one has to deal with: a tough
customer;a cool customer.
For the purpose of this talk a customer can be any
internal or external project sponsor or decision maker.
4. What Do Customers Expect?
• To Get What They Asked or Paid For
• To Have Predictable Costs
• To Get Timely Results
• To Be Kept in the Loop (i.e. No Surprises)
• To Focus On The Business While We Deliver
the Technology
5. What Do Customers Often Get?
• Experience Tells Them...
IT Project = Confusion + Frustration (#FAIL)
• From Their Perspective We...
- Have a Poor Project Delivery Track Record
- Fail to Hold Our Commitments
- Have Fluid, Out of Control Costs
- Misinterpret/Misunderstand What They
Want
6. Why Do We Need Change?
• Because We Do In Fact Have a
Poor Project Delivery Track Record
• As an Industry IT Misses
Approximately 7 Out of 10 Times
(Cost, Features, Time)
- Standish Group - Chaos Summary 2009
- University of Missouri, St. Louis (December 2003)
• This is Performance Only a Baseball
Player Could Appreciate
7. How Do We Improve Our Batting
Average and Get More Fans?
• Hold Our Commitments
• Build Confidence Through
Transparency & Shared
Success
• Actively Engage the
Customer
• Communicate & Adjust
9. So What is Agile?
• Agile Provides a Set of Practices and Processes
Based on Iterative and Incremental
Development With a Focus on Collaboration
and Feedback
• Agile Manifesto (http://agilemanifesto.org/)
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
13. But Agile Will...
• Enable Us To (Grow Fans):
1. Hold Our Commitments
2. Build Confidence
3. Engage The Customer
4. Communicate and Adjust
14. How Does Agile Helps Us To
Hold Our Commitments?
• We Break Down Work Into
Manageable Chunks Called Stories
• We Employ “Manage a Day” Theory
• We Plan for Change and Change
the Plan
• We Use Fact Based, Collaborative
Planning
15. How Does Agile Help Us To
Build Confidence?
• Demonstrate Working
Code Early and Often
• Do the Most Valuable and/
or Hardest Things First
• Maintain a “Change” Buffer
in the Plan
• When We Don’t Know...
We Prototype
16. How Does Agile Helps Us To
Engage The Customer?
• Customers Actively Participate
in Story Building
• Customers Define Success &
Failure Criteria
• Customers Help to Plan
Iterations
• Customers Provide Feedback
on Working Code
17. How Does Agile Helps Us To
Communicate and Adjust?
• Agile is All About
Communication and Feedback
• Continuous Improvement is
Built Into the Process via
Retrospectives
• “Do More of What Works
and Less of What Doesn’t”
• We Clearly Define Done
18. Next Lets Examine Our Approach to
Solving this Challenge at Ecommerce
19. How We Practice Agile
• We Will Cover
- Planning
- Managing
- Delivery
- Team Makeup
20. Agile Planning
• Key Practices
- Story Building (Requirements
Gathering)
- Planning Poker (Estimation)
- Iteration Planning (Slotting and
Prioritization)
21. Agile Story Building
Anatomy of a Story
As a <actor/role> I want to <action> so
that <reason>.
Acceptance Criteria Failure Conditions
• What does success • What exceptions do
look like? we handle and how?
22. Example Story
As a presenter, I want to determine the
background of the audience so I can cater
the presentation to their needs.
Success Failure Conditions
• The majority of the audience self • If no one raises their hands make
identifies as (customer or IT) and sure you are in the right room!
as (agile novice or agile expert) • If less than the majority raise their
hand then keep trying until you
get a majority
23. Another Example
As a presenter, I want to teach the audience
how to use agile to win over customers so
that they can be more successful with their
future projects.
Success Failure Conditions
• Members of the audience learn about • If the audience is bored tell a joke
important aspects of agile
• If the audience glassy eyed then re-
• Members of the audience leverage agile on query background information
their future projects
• If the audience fails to applaud at the
• The audience applauds at the end of the end apologize and hand out candy
presentation
24. Planning Poker
• We Estimate Each Story Point Scale
Story Using Story - 0 is <= 2 hours
Points - 1 is <= 8 hours
-
• Members Use
2 is <= 16 hours
- 3 is <= 40 hours
Playing Cards To - 5 is > 40 hours
Cast Their Vote
• Capture Tasks * Stories scored a 5 need to be
broken down
25. Iteration Planning
Backlog
• An Iteration Contains
2 Weeks Worth of 3 3 00 Stories
Stories Minus a 20% 3 1 1
Change Buffer (Plan Change
for Change)
Prioritize
Buffer
• Collaborative Effort
Between Development
and the Customer
Velocity
• We Package 2-3
Iteration
Iterations in Advance
26. Agile Planning Toolbox
• Tools We Use
- Pivotal Tracker for managing
backlog, iteration planning and work
tracking. www.pivotaltracker.com
- www.planningpoker.com for story
estimation.
- Redmine for project documentation
www.redmine.org.
28. Daily Stand Ups
• Must Be Prepared To Answer The
Following:
- Yesterday I Committed To And
Completed... (verify)
- Today I Commit To Completing...
(commit)
- My Roadblocks Are... (escalate)
• And Yes We Stand The Entire Time :)
29. Retrospectives Not
Honest!
• Requires “Brutal Honesty”
• Answers Two Simple Questions
- What Worked
- What Did Not Work
• Turn the WDNW’s Into Stories
or Chores and Incorporate
Into Future Iterations
31. Demonstrations
• Gives Customer a Chance to
Interact With Working Code
• Demos Verify Customer
Acceptance of Stories
• Demos Should Be Engaging
• Capture Failures as Bug
Stories
32. Agile Delivery
• Key Practices
- Clear Definition Of Done
- Automated Testing Is Critical To Success
- Continuous Integration
- Agile Coaching
33. Definition Of Done
• Working, Demonstratable Code
• All Tests Pass
- Tests Prove Acceptance Criteria &
Failure Handling
• Story Accepted By Customer
34. Automated Testing
• Test First, Test After... Just Test!
• Tests are as Much for the
Developer as the Customer
• Regression Testing Prevents
Indirect Feature Breakage
• Integration Testing Ensures
That Units Function
Correctly Together
35. Continuous Integration
• Instant Feedback For Build & Test
Validity Upon Code Check In
• Broken Build = Fire Alarm
• Provides Metrics for Code
Coverage
• We Use Hudson (hudson-ci.org)
But There Are Many Good Ones
Available
36. Agile Coaching
• Continuous Coaching is Critical
for New Agile Teams
• Developers Pair as Needed
• Peer Code Reviews Required
- Ensures Consistency
- Spreads Knowledge
• Team is Self Organizing
37. Building an Agile Team
• A Typical Project Will Have
- 1 Project Manager
- 1 Business Analyst
- 3-6 Developers
- 1-2 Designers/Web Developers
- 1-2 QA
• We Use a 1-3-1 Ratio for Designers
to Developers to QA
38. Our Agile Team
• Customer/Sponsor/ • Communicate Project Goals/
Background
SME’s
• Write Stories
• Business Analyst
• Write Success/Failure
• PM/Dev Manager Criteria
• Provide Reference
(Scrum Master)
Information
• Designers/UX • Help Plan/Prioritize Iterations
• Developers • Provide Feedback in Demos
• Participate in Daily Stand Up
• QA (Optional)
39. Our Agile Team
• Customer/Sponsor/ • Facilitate Story Building
SME’s • Challenge Customer to Dig
• Business Analyst
Deeper & Work Through
Scenarios
• PM/Dev Manager • Story Clarification
(Scrum Master) • Participate in Planning Poker
• Liaison Between IT & Customer
• Designers/UX
• Demo Presenter
• Developers • Participate in Daily Standup
• QA • Participate in Retrospectives
40. Our Agile Team
• Customer/Sponsor/ • Lead Iteration Planning
SME’s
• Lead Planning Poker
• Business Analyst
• Lead Daily Stand Up
• PM/Dev Manager • Lead Retrospectives
(Scrum Master)
• Assign Work
• Designers/UX • Eliminate Roadblocks
• Developers • Review Code
• QA • Lead Release Planning
41. Our Agile Team
• Customer/Sponsor/ • Create Wireframes
SME’s
• Create Screen Mocks
• Business Analyst • Define Interaction
Characteristics
• PM/Dev Manager
• Define Application Graphic
(Scrum Master) Standards
• Designers/UX • Demo Designs
• Developers • Participate in Daily Stand Up
• QA • Participate in Retrospectives
42. Our Agile Team
• Customer/Sponsor/ • Break Stories into Tasks
SME’s • Deliver Stories (Code & Unit
• Business Analyst
Test)
• Pair & Mentor
• PM/Dev Manager • Participate in Planning Poker
(Scrum Master)
• Participate in Demos
• Designers/UX • Manage Continuous
Integration Server
• Developers
• Participate in Daily Stand Up
• QA • Participate in Retrospectives
43. Our Agile Team
• Customer/Sponsor/ • Participate in Story Building
SME’s • Develop Integration Test
• Business Analyst
Plans
• Execute Integration Tests
• PM/Dev Manager • Record/Prioritize Defects
(Scrum Master)
• Certify Release for
• Designers/UX Production
• Participate in Demos
• Developers
• Participate in Daily Stand Up
• QA • Participate in Retrospectives
44. In Summary
• To Win Fans
- Do What We Say and Say What We Do
- Customers Want To Be Heard
- Demonstrate Consistency and
Transparency Using Agile
• Like Anything Else, Agile Takes Practice
and Coaching But Everyone Can Do IT
Taught agile to hosting, airline, financial services, insurance and transportation\n\n\n
Won&#x2019;t use the words cloud or ecosystem\n
Need a common understanding of Customer before discussing their perspective\n
I think we all have these expectations as a customer\n
\n
300 batting average\n
Sounds Simple. Next slide.\nAgile can help.\n
\n
Poll the audience on Agile Manifesto - software industry leaders were tired of failing \nAgile manifesto 10 year anniversary this past February\nBefore we talk about what agile will do to help, lets look at what agile won&#x2019;t do.\n
\n
\n
\n
\n
Plan based on what we know (velocity) and the customer helps us prioritize\n
Remove Uncertainty and Plan for Change\n
What to work on\nWhen to work on it\nTell us how we did once done\n
My agile epiphany was that most of what we do in agile is to get feedback\nNot properly defining done plagues many teams. %&#x2019;s don&#x2019;t matter. You are done or you are not.\n
\n
Next Look at the Key Practices we use\n
\n
\n
\n
\n
Estimation in the dark\nOutliers argue their case\n
\n\n
\n
\n
15 minutes or less in duration\n Entire Team Participates (Skype for remotes)\n Fosters Accountability & Shared Responsibility Amongst Team Members\n
A Look Back At Each Iteration Prior To The Start Of The Next\n
Left axis is Work in Hours, Right axis is completed work in Hours\n X axis is days in the iteration\n
Did we deliver what you asked us to deliver?\n
\n
\n
Suite of Automated Unit Tests Provides Regression Testing\n We Leverage Integration Tests For Functional UI Testing\n
\n
\n
That is an actual picture of our team doing a standup :)\n
\n
\n
\n
\n
\n
\n
This should be a summary or take aways\n\nTakes Practice, Bring in a coach, Customers may resist at first but they will love you later\n