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