Why Agile? Why Now? IPMA Forum 2009

download Why Agile? Why Now?   IPMA Forum 2009

of 62

  • date post

    13-May-2015
  • Category

    Technology

  • view

    3.134
  • download

    1

Embed Size (px)

description

This session will have something for everyone. For the person new to Agile Development, this will provide a basic knowledge to distinguish Agile development from traditional Waterfall development. For those that have some knowledge, this will provide some practical examples and stories about what is happening in the “real world”. We are in tough financial times, and are being ask to do more than ever with less people. Faster, better, and cheaper is the new mantra for organizations. Companies that will survive and endure for the long haul are looking for different and better ways to deliver software and are discovering Agile development as a possible answer. How do you get started with Agile practices? What are some lessons learned that I can watch out for as we get started? What will Agile fix and what will it expose? In this session, these questions and others will be answered. We will also explore how Agile development came to be and provide a foundational knowledge of the common practices including the Scrum framework and Extreme Programming (XP).

Transcript of Why Agile? Why Now? IPMA Forum 2009

  • 1.Why Agile? Why Now? IPMA Forum 2009 May 19, 2009

2.

  • Certified Scrum Practitioner
  • Over 20 years experience across spectrum of industries
  • Participated in a variety of roles from Developer to CTO
  • Expertise in assisting transitions to agile since 2003
  • Delivers mentoring and training on Agile Practices throughout the organization

Skip Angel [email_address] Blog: AgileIQ ( www.agileiq.org ) Podcast: The Agile Coach LinkedIn, Twitter @skipangel 3. Agenda

  • Whats The Problem?
  • What Is Agile?
  • Why Now?
  • What Should I Expect With Agile?
  • How Do I Start Agile Well?
  • Where Can I Learn More?
  • What Are Your Questions?

4. Whats The Problem? 5. "If you keep on doing what you've always doneyou'll keep on getting what you've always got." 6. Defined Process Control

  • Traditional Practices:
  • Traditional software development models are based upon a defined methodology which attempts to
    • Define all requirements up front
    • Logically break down the work
    • Estimate the effort / durations
    • Plan out all the work
    • And only then begin the developmentwhile trying to limit/control any change that will threaten the plan.

Document System Concept System Requirements Architectural Design Detailed Design Code, Debug, Unit Test System Test Deploy & Operate Waterfall Development Methodology Sequential 7.

  • The traditional methods are highly sequential
  • One functional role leads off (e.g. design)
  • Some work is completed
  • Then work is handed off to the next role (e.g. coding)

Defined Process Control 8.

  • Ask Customers what they want
    • (When they really dont know)
  • Reward them for thinking of everything
    • (Call the initial list Scope)
  • Penalize them for adding things later
    • (Control Scope aggressively)
  • The result is Overproduction of Features

Legacy Of Waterfall 9.

  • The best way to manage scope
  • Less Code More Value!
  • Develop the 20% of the features that deliver 80% of the value
  • Develop & deploy highest priority first
  • Stop when you run out of time or money

Conclusion? 10. Dont Build What Wont Be Used

  • Featured / Functions Used in a Typical System
    • The biggest cost of Predictive Development is overproduction of features
    • Must be designed, built and maintained
    • Dont get used; provide no value

*Standish Group Study Reported in 2000 Chaos Report. 11. Software Project Success Rates

  • Background
  • Software projects present some unique challenges, and have experienced historicallylow success rates .

From Standish Group CHAOS database. NOTE: Challenged vs. Failed distinguishes between a project failure and a project management failure, which still may deliver some value. 12.

  • Categorization of agreement versus certainty

Software Development Project Complexity Modeled from Stacey, Ralph D. (1999). Strategic Management & Organizational Dynamics: The Challenge of Complexity. Third Edition. New York: Financial Times Prentice Hall. Anarchy Simple Complex Technology Requirements Complicated Complicated Far fromCertainty Close toCertainty Far fromAgreement Close toAgreement 13. Empirical Process Control 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, theempiricalapproach is the appropriate choice. Process Dynamics, Modeling and Control , Ogunnaike and Ray, Oxford University Press, 1992 Empirical Process Control uses Inspection and Adaptation 14. An Empirical Process Control 15. Why Agile? Constraints Estimates Features Schedule Cost Plan Driven The Plan creates cost/schedule estimates Waterfall Source: Michelle Sliger in Relating PMBOK Practices to Agile Practices The Vision creates feature estimates Schedule Cost Features Value / Vision Driven Agile 16. What Is Agile? 17. The Agile Umbrella Scrum XP Crystal Lean DSDM FDD AGILE 18. The Agile Manifesto*

  • We are uncovering better ways of developing software bydoing itandhelping others do it . Through this work we have come to value:
  • Individuals and interactionsover processes and tools
  • Working softwareover comprehensive documentation
  • Customer collaborationover contract negotiation
  • Responding to changeover following a plan
  • That is, while there is value in the items on the right, we value the items on theleftmore.
  • *www.agilemanifesto.org

2007 SolutionsIQ - v15 19. Principles Behind Agile Manifesto*

  • Early and continuous delivery of valuable software
  • Deliver working software frequently
  • Working software is the primary measure of progress
  • Continuous attention to technical excellence
  • The art of maximizing the amount of work not done
  • Welcome changing requirements
  • Business and developers work together
  • Face-to-face conversation is most efficient
  • Build projects around motivated individuals
  • Self-organizing teams deliver the best solutions
  • Sustainable development
  • The team reflects at regular intervals

2007 SolutionsIQ - v15 * Adapted fromwww.agilemanifesto.org/principles 20. What Is Scrum?

  • Basics
  • In the sport of rugby, a scrum is when the players form up as a tight, integrated pack.
  • The ball is put into play and the team works to achieve the goal of moving the ball.

A Rugby Scrum 21.

  • Scrum refers to a holistic or rugby approachwhere teams goes the distance as a unit, passing the ball back and forthas opposed to the traditional sequential or relay race approach for managing new product development.

What Is Scrum? 22.

  • Scrum is a way of getting product development unstuck and moving forward:
    • There is little or no delivery of functioning software
    • The team has low morale
    • Management is ineffective
    • Low quality of the software
  • Scrum is effective at sustaining that momentum :
    • When you would like to avoid the outcomes above

When Is A Scrum Formed In Software? 23. Deliver Working Software Frequently OBJECTIVE: Deliver a Product Increment in a fixed time period (called a Sprint) Sprint Length Commit & Deliver 24. The Scrum Framework 25. Scrum Project Roles 26.

  • Test-driven development
  • Automated builds and continuous integration
  • Collective code ownership
  • Continuous refactoring
  • Frequent design and code reviews
  • Highly collaborative team processes
  • High customer contact and max transparency
  • Automated acceptance and regression tests

Technical Best Practices For Teams 27. Why Now? 28.

  • Economy: Do more with less
  • Competitors: Respond quickly to the marketplace
  • Social Media: Listen to us or else
  • Technology: Provide new features frequently or fall behind in the times
  • Customers: Give us something that works and wont break
  • Investors/Shareholders: Make money or well go somewhere else

Our Current Challenges 29. 30. Product Engineering Then & Now Collaboration Innovation Releases Feedback Customers Process Architecture Culture Testing Tools 31. What Is Happening In The Marketplace?

  • Enterprise Agile adoption has accelerated, increasing approximately two and a half times faster between 2006 and 2007 than between 2005 and 2006.
  • Larger enterprises continue to be more likely to adopt Agile than smaller enterprises.
  • The financial services industry continues to lead the pack in enterprise adoption of Agile processes; the retail and public sector segments continue to lag.
  • Adoption of Agile processes clearly correlates with adoption of other leading-edge technologies and techniques like SOA, ALM, and SaaS.

Enterprise Agile Adoption In 2007 Forrester Research From:Enterprise And SMB Software Survey, North America And Europe, Q3 2007 Analyst contact:Carey Schwaber February 6, 2008 32. 1/4 Of Enterprises Currently Use Agile Processes, And Nearly 1/2 Of Remaining Are Aware Of Agile Source: Enterprise And SMB Software Survey, North America And Europe, Q3 2007 Base: 1,017 North American and European enterprises How familiar are you with Agile software development processes? 33. Agile Adoption Increased 53%