Agile Development
An Executive Overview

Professional Background
Benjamin Scherrey – Proteus Technologies, Ltd.
• 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!
Twitter @proteusguy scherrey@proteus-tech.com

Professional Background
Sinaporn Suebvisai – Proteus Technologies, Ltd.
• 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
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.

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
5

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.

How is Agile Unique?
• Completely Value Driven
8

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.
9

Agile Fixes Costs & Schedule to
Drive Features
© www.StickyMinds.com
10

How is Agile Unique?
• Completely Value Driven
• Time Boxed Iterations
11

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!

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
13

How is Agile Unique?
• Completely Value Driven
• Time Boxed Iterations
• Test Driven Development
14

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!
15

How is Agile Unique?
• Completely Value Driven
• Time Boxed Iterations
• Test Driven Development
• User Stories describe Features
16

What is a User Story?
• User Story is a Brief statement of
Functionality but told from the User’s
perspective.
As a <stakeholder>, I want to <goal> so that <reason>.
• INVEST in User Stories
– Independent
– Negotiable
– Valuable
– Estimable
– Small
– Testable

User Story
Description
Story Card Story ID
Notes from
Discussion
Exit
Criteria
Story
Points

The Story Board
19

The Story Board
20

How is Agile Unique?
• Completely Value Driven
• Time Boxed Iterations
• Test Driven Development
• User Stories describe Features
• Planning & Estimating with
Story Points
21

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

Estimating the Agile Way
Estimating the Real World
Each building is a task
whose complexity is
determined by its height.
23

Absolute Estimation
Hard to get good numbers.
Perspective’s may
radically impact results.
Humans just not good at
this.
24

Absolute Estimation
Humans good at making
relative judgments.
Consensus can be
reached quickly.
Assessment accuracy is
“close enough”.
25

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.
26

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.
27

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!

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
29

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

Thank you for your kind attention.
33

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