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

Introductionto Agile Executive Overview Gpi Asia Rev2

•
•
Benjamin Scherrey
Benjamin Scherrey

Our training partner, GPIAsia, asked us to produce an executive overview version of our 2-day Introduction to Agile course for an iTAP program intended to introduce Agile concepts to CMMI practitioners. Was an interesting challenge. Should know in a week or two if any of this gets traction from that audience. If it does, I'll take credit. If not - I'll blame my colleague Pam who delivered it with me. :-) As with all my presentations, you really need to hear the talk to get the full benefit but at least you can see the subjects we touch on.

1 of 34
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

More Related Content

Introductionto Agile Executive Overview Gpi Asia Rev2

  • 1. Agile Development An Executive Overview
  • 2. 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
  • 3. 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
  • 4. 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 5
  • 6. 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
  • 7. 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 8
  • 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. 9
  • 10. Agile Fixes Costs & Schedule to Drive Features © www.StickyMinds.com 10
  • 11. How is Agile Unique? • Completely Value Driven • Time Boxed Iterations 11
  • 12. 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 13
  • 14. How is Agile Unique? • Completely Value Driven • Time Boxed Iterations • Test Driven Development 14
  • 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! 15
  • 16. How is Agile Unique? • Completely Value Driven • Time Boxed Iterations • Test Driven Development • User Stories describe Features 16
  • 17. 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
  • 18. User Story Description Story Card Story ID Notes from Discussion Exit Criteria Story Points
  • 21. How is Agile Unique? • Completely Value Driven • Time Boxed Iterations • Test Driven Development • User Stories describe Features • Planning & Estimating with Story Points 21
  • 22. 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. 23
  • 24. Absolute Estimation Hard to get good numbers. Perspective’s may radically impact results. Humans just not good at this. 24
  • 25. Absolute Estimation Humans good at making relative judgments. Consensus can be reached quickly. Assessment accuracy is “close enough”. 25
  • 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. 26
  • 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. 27
  • 28. 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 29
  • 30. 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
  • 31. 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
  • 32. 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. 33
  • 34. 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