Butch Landingin, CTO of Orange & Bronze Software Labs, talks about the Agile Methodology for the Philippine Software Industry Association's Enablement Seminar on April 27 at the AIM. About O&B: Orange & Bronze is an offshore product and software development firm in the Philippines, is one of the first companies in Asia to use and advocate Agile Software Development, and has been using it since our inception in 2005, back when Agile was still an emerging movement. O&B offers training courses for Agile with Scrum and XP - these classes were developed and are taught by some of the Philippines' well-known and respected Agile / Scrum coaches and practitioners, and uses the format trusted by some of the best companies in the Philippines.

1. Agile Software Development
PSIA Enablement Seminar Series Cycle 13
April 26, 2012
Asian Institute of Management
A talk by Butch Landingin
CTO, Orange & Bronze Software Labs, Inc.
butch@orangeandbronze.com

2. Are you agile enough?

3. What I'll cover
• Chaos Theory
• The Agile Mindset
• Agile Practices
• How agile are you?

4. Chaos Theory
from Wikipedia:
– is a field of mathematics that studies the behavior of dynamical systems
that are highly sensitive to initial conditions, an effect which is popularly
referred to as the "butterfly effect".
– Small differences in initial conditions (such as those due to rounding
errors in numerical computation) yield widely diverging outcomes for
chaotic systems, rendering long-term prediction impossible in general.

5. Two Stories
• Installing Oracle 9i on HP-UX
• Fixing a bug
Software Development is
FUNDAMENTALLY a CHAOTIC process.

6. Islands of Stability

7. Detour: A Story about Agile
Adoption

8. Agile Adoption in the Philippines
(circa 2005)
• LOW Awareness, and even much less Acceptance,
in the LOCAL IT INDUSTRY
• Too new, untested, not trusted by the local IT
community
Most of local IT community was not even aware of
the AGILE METHODOLOGIES
• Very hard to convince local IT community to use
Time &Material (T&M) project models, very fixated
on FIXED BID contracts...

9. Hybrid Approach
• HALF-AGILE, HALF TRADITIONAL
PROJECT MANAGEMENT
• Agile team processes: iterative delivery,
agile development practices like unit tests,
pair programming, readiness to incorporate
changes, etc.
• Traditional for client facing aspects: Fixed
Bid, Fixed Scope (but not really), Milestone-
based delivery and payment schemes...

10. Results
• Cost and Schedule Overruns
– Project A - 2 month estimate became 15 months
– Project B - 8 month estimate became 2 years
• Client dissatisfaction,
• Team burnout,
• Financial Losses

11. Conclusion
• Hybrid Approach
– HALF-AGILE, HALF TRADITIONAL PROJECT
MANAGEMENT IS A HALF-ASSED SOLUTION
that doesn't work

12. What was successful
• We adopted Agile in Full
– Threw out Hybrid Approaches
– Moving away from fixed bid projects
• Fixed bid only for "small" projects
– Make sure customer has understood and agreed
to an agile approach

13. Results
• We found our biggest successes from those
agile projects
– 1st US-based outsourcing client lasted more
than 2 years.
– Most of our projects are T&M Agile projects
• with a small percentage of fixed bid projects that are
small in scope...
– 100% of our long-term clients are referenceable

14. Back to regular programming

15. What is Agile?

16. The Agile Mindset

17. Agile Manifesto
We are uncovering better ways of developing software by doing it and
helping others do it.Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items
on the left more.
from www.agilemanifesto.org

18. Agile Principles
We follow these principles:
• Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile
processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple
of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout
the project.
• Build projects around motivated individuals. Give them the environment
and support they need, and trust them to get the job done.

19. Agile Principles
• The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
• Continuous attention to technical excellence and good design enhances
agility.
• Simplicity--the art of maximizing the amount of work not done--is
essential.
• The best architectures, requirements, and designs emerge from self-
organizing teams.
• At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.
from www.agilemanifesto.org/principles.html

20. Predictive vs. Empirical
Approaches
“It is typical to adopt the defined (theoretical) modeling approach
when the underlying mechanisms by which a process operates
are reasonably well understood. When the process is too
complicated for the defined approach, the empirical approach is
the appropriate choice.”
- Process Dynamics, Modeling, and Control, Ogunnaike and
Ray, Oxford University Press, 1992

21. Predictive vs. Empirical
Approaches

22. Three Legs of Scrum
• Transparency
• Inspection
• Adaptation

23. Empirical Process Control

24. Agile Values
• Communication
• Simplicity
• Feedback
• Courage
• Respect

25. Agile Practices

26. XP

27. XP Practices
• Fine scale feedback
– Pair programming
– Planning Game
– Test Driven Development
– Whole team
– Customer Tests
• Continuous process
– Continuous Integration
– Design Improvement
– Small Releases

28. XP Practices
• Shared understanding
– Coding Standards
– Collective Code Ownership
– Simple Design
– System Metaphor
• Programmer welfare
– Sustainable Pace

29. Dilbert on XP

30. Scrum Flow

31. Scrum Flow
• Product Backlog – a prioritized list of features
to be delivered
• Sprint Backlog – a subset of the Product
Backlog to be delivered within a Sprint
• Sprint – a period of 2-4 weeks in which
development is done
• Scrum – daily team meeting
• Deliverable – the output of the Sprint is an
“Potentially Shippable Product Increment”

32. Scrum Flow
• At the beginning of each Sprint,
– Team selects items (customer requirements) from a
prioritized list.
– They commit to complete the items by the end of
the Sprint.

33. Scrum Flow
• During the Sprint,
– The chosen items do not change.
– Every day the team gathers briefly
• to report to each other on progress
• update simple charts that orient them to the work
remaining

34. Scrum Flow
• At the end of the Sprint,
– the team reviews the Sprint with stakeholders,
– demonstrates what they have built.
– People obtain feedback that can be incorporated
in the next Sprint.
• Scrum emphasizes
– working product at the end of the Sprint that is
really “done”;
– in the case of software, this means code that is
integrated, fully tested and potentially shippable.

35. How agile are you?

36. How agile are you?
Very Unagile Very Agile

37. Agile Manifesto
We are uncovering better ways of developing software by
doing it and helping others do it.Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items
on the left more.
from www.agilemanifesto.org

38. What we really want
• Its not being more agile per se.
• Its about getting better all the time.
Better
Time

39. Agile practices vs mindset
• More important than adopting the practices
is adopting the mindset
– adopting the mindset is harder
– adopting practices without the mindset leads to
"agile-agile-an"

40. How to get Better
• Small steps
• Find out what works
• Change is hard. It can be slow.
• Each environment is unique
• Use transparency, inspection and adaptation
as a guide to find creative solutions

41. Questions?