Post on 03-Sep-2014
description
transcript
Agile DevelopmentAn Executive Overview
Professional Background
• Accidentally started first company, Business Data Management, in 1989.
• Found out managing software development was very hard!!• Read Tom Gilb’s “Principles of Software Engineering Management”• Discovered iterative development, metrics & clear requirement
definitions!• Got involved with ISO-9001 – learned that processes can go wrong!• Early adopter of SEI’s Capability & Maturity Model• Started second company, Proteus Technologies, in 1994.• Finally became Agile in 2002 and enjoy software development once
again!
Benjamin Scherrey – Proteus Technologies, Ltd.
Twitter @proteusguy scherrey@proteus-tech.com
Professional Background
• Bachelor Degree in Computer Engineering from Chulalongkorn University in 2001
• Worked as Research Assistant at NECTEC for 1 year• Master Degree from Computer Science School, Carnegie
Mellon University, in 2004• Joined Thomson Reuters in 2004 as Software Engineer• Became Development Group Leader in 2007• Led the effort to adopt Agile process into the team, and
kept making improvements• Joined Proteus Technologies Co. Ltd. as Thailand's first ever
Agile Evangelist in 2008
Sinaporn Suebvisai – Proteus Technologies, Ltd.
sinapam@proteus-tech.com
Another Process?
• Software Development :
Art or Science?
The Art of Managing Complexity• Unfulfilled Promises• False Belief that we know more about a project than we
possibly can.
• Hiding from Risk is NOT Managing Risk!• …quit pretending and get to the real value.
5
What is Agile?
The Agile Manifesto – Utah 2001
Individuals and interactions
over processes and tools
Working software
over comprehensive documentation
Customer collaboration
over contract negotiation
Responding to change over following a plan
Agile Utilizes Best Practices
• Evolutionary Delivery vs. All at Once– Barry Boehm’s Spiral Model
• User Stories
– Kent Beck’s Xtreme Programming• Short, Focused, Meetings of Cross Functional
Teams– Jeff Sutherland, et al, SCRUM
Culture Over Process
• Agile is a CULTURE not a PROCESS.• A culture is the set of beliefs & goals that drive
ALL of your organization.• All successful processes must be driven by your
culture.• An Agile Culture will help you determine what
aspects of any particular process are right for you.
8
How is Agile Unique?
• Completely Value Driven
9
Mayo-Smith Pyramid
Grandiose Designs Incur Grandiose Risks Scope fixed, budget & schedule may suffer.Focus on immediate, practical functionality maximizes value of each increment while reducing risk. Scope flexible, budget & schedule under control.
10
Agile Fixes Costs & Schedule to Drive Features
© www.StickyMinds.com
11
How is Agile Unique?
• Completely Value Driven• Time Boxed Iterations
Time Boxed Iterations
• Iterations are fixed length. – Typically 2 weeks, no more than a month.
• Every iteration ends with a demo and retrospective.
• Short Iterations allows for frequent directional corrections.
• Reduced Cycle time is Major competitive advantage!
13
What we do in Iteration Close-down
• Conclude the Iteration– Which stories have been closed
• Update the Progress in relation to the Release
• Demo– Customers are happy when they see
progress
– Early feedback from customers
14
How is Agile Unique?
• Completely Value Driven• Time Boxed Iterations• Test Driven Development
15
Test Driven Development
• Unit Testing– Integrated in the build environment.
• Continuous Integration– Always ready to ship. Allows you to embrace change!
• Automated Testing– Ensure constant quality and prevent regressions.
• Fully integrates the test group and developers love writing tests!
16
How is Agile Unique?
• Completely Value Driven• Time Boxed Iterations• Test Driven Development• User Stories describe Features
What is a User Story?
• User Story is a Brief statement of Functionality but told from the User’s perspective.
• INVEST in User Stories– Independent– Negotiable– Valuable– Estimable– Small– Testable
As a <stakeholder>, I want to <goal> so that <reason>.
Story Card Story IDStory ID
Story Story PointsPoints
Notes from Notes from DiscussionDiscussion
Exit Exit CriteriaCriteria
User Story User Story DescriptionDescription
19
The Story Board
20
The Story Board
21
How is Agile Unique?
• Completely Value Driven• Time Boxed Iterations• Test Driven Development• User Stories describe Features• Planning & Estimating with
Story Points
Why Traditional Planning Fails
• Planning is by Activity rather than Feature– Activities don’t finish earlier than planned– Lateness is passed down the schedule– Activities are not dependent
• Estimates become Commitments– This has to be done by this date and with all these
features.
• Features are not developed by Priority• Uncertainty is ignored
23
Estimating the Agile Way
Estimating the Real World
Each building is a task whose complexity is determined by its height.
24
Absolute Estimation
Hard to get good numbers.Perspective’s may radically impact results.Humans just not good at this.
25
Absolute Estimation
Humans good at making relative judgments.
Consensus can be reached quickly.
Assessment accuracy is “close enough”.
26
Story Points Support Relative Estimates
• Measure Relative Complexity of User Stories• Considers the Entire Efforts of Dev & Test• Use the Fibonacci Sequence in order to prevent
arguments over a 10% estimate difference.– 1, 2, 3, 5, 8, 13, 21, etc…
• Far less likely for management to successfully play “Time Math” with.
27
Velocity & Release Planning
• Velocity is the average number of story points achieved over the last several iterations.
• A Release is a set of User Stories (Features) that must be present in order to be worth shipping.
• Velocity allows you to estimate your release date while still being responsive to changing requirements by trading out User Stories.
Why Agile Planning Works
• Instead of creating the perfect plan, create a plan that is useful right now– But update plan often
• Effort Size and Duration are separated– Duration estimate is harder to match
• Plans are made at different levels• State Uncertainty in no Uncertain terms• Tracking is at the Team level, not Individual• Plans are by Features, not Tasks
– Team understands more of the product• Transparency Builds Trust and Credibility!
29
How to Better Utilize Agile
• Use an Agile Coach as a full team member, not process enforcer.
• Team-member Driven Process• Have Small Cross-Functional Teams that
work side by side.
• Automate Everything
So what do we get from being Agile?
• Happy customers– they get what they really want!
• Faster feedback• Quick response to changes• Trust from customers due to Transparency• Increase in Team Participation• Risk management built-in• Better software quality
30
Opportunities
• Best Case for Risk Management
• Lowest Overhead while being Effective
• Better Able to Capitalize on Opportunities • Integrate Kano Analysis to help drive
feature plan
• Involve business to achieve maximum ROI
31
Challenges
• Keeping User Stories Small• Exit Criteria for User Stories• Avoiding Over-specification
• Distributed Teams Incur Additional Overhead• Some Projects (medical devices, flight systems)
need more formal processes than Agile reasonably supports.
32
33
Thank you for your kind attention.
References
Agile Estimating and Planning
- Mike Cohn
Principles of Software Engineering Management
- Tom Gilb
Agile Retrospectives: Making Good Teams Great
- Esther Derby, Diana Larsen, Ken Schwaber
Email me: scherrey@proteus-tech.com
Web site: http://proteus-tech.com
Follow me on Twitter: @proteusguy
34