Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Are you Agile enough?

•
•
Orange and Bronze Software Labs
Orange and Bronze Software Labs

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 of 41
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
Are you agile enough?
What I'll cover • Chaos Theory • The Agile Mindset • Agile Practices • How agile are you?
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.
Two Stories • Installing Oracle 9i on HP-UX • Fixing a bug Software Development is FUNDAMENTALLY a CHAOTIC process.
Islands of Stability
Detour: A Story about Agile Adoption
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...
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...
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
Conclusion • Hybrid Approach – HALF-AGILE, HALF TRADITIONAL PROJECT MANAGEMENT IS A HALF-ASSED SOLUTION that doesn't work
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
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
Back to regular programming
What is Agile?
The Agile Mindset
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
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.
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
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
Predictive vs. Empirical Approaches
Three Legs of Scrum • Transparency • Inspection • Adaptation
Empirical Process Control
Agile Values • Communication • Simplicity • Feedback • Courage • Respect
Agile Practices
XP
XP Practices • Fine scale feedback – Pair programming – Planning Game – Test Driven Development – Whole team – Customer Tests • Continuous process – Continuous Integration – Design Improvement – Small Releases
XP Practices • Shared understanding – Coding Standards – Collective Code Ownership – Simple Design – System Metaphor • Programmer welfare – Sustainable Pace
Dilbert on XP
Scrum Flow
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”
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.
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
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.
How agile are you?
How agile are you? Very Unagile Very Agile
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
What we really want • Its not being more agile per se. • Its about getting better all the time. Better Time
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"
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
Questions?

More Related Content

Are you Agile enough?

  • 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.
  • 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
  • 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
  • 22. Three Legs of Scrum • Transparency • Inspection • Adaptation
  • 24. Agile Values • Communication • Simplicity • Feedback • Courage • Respect
  • 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
  • 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.
  • 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