Why Agile? Why Now?   IPMA Forum 2009
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Why Agile? Why Now? IPMA Forum 2009

  • 4,261 views
Uploaded on

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.......

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).

More in: Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,261
On Slideshare
4,228
From Embeds
33
Number of Embeds
5

Actions

Shares
Downloads
205
Comments
0
Likes
4

Embeds 33

http://www.slideshare.net 17
http://www.lmodules.com 9
http://www.linkedin.com 4
https://www.linkedin.com 2
http://www.slashdocs.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • IPMA Forum 2009 - Why Agile? Why Now? Thanks for coming to this opening session of IPMA Forum 2009. This session is entitled “Why Agile? Why Now?”. Hopefully you are in the right session! Before I get started I want to take a poll of the group (raise your hands until not applicable): How many people have read something on Agile? How many have practiced Agile on some project? How many are practicing Agile on their current project? How many feel they are practicing well? Discuss findings with the group. © Copyright 2009 SolutionsIQ

Transcript

  • 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
    • What’s 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. What’s The Problem?
  • 5. "If you keep on doing what you've always done… you'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 development…while 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 don’t 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. Don’t Build What Won’t 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
      • Don’t 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 historically low 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 from Certainty Close to Certainty Far from Agreement Close to Agreement
  • 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, the empirical approach 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 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.”
    • * 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 from www.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” approach—where teams goes the distance as a unit, passing the ball back and forth—as 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 won’t break”
    • Investors/Shareholders: “Make money or we’ll 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% Year-Over-Year Between 2006 And 2007 *Source: Business Technographics ® November 2005 North American And European Enterprise Software And Services Survey † Source: Business Technographics September 2006 North American And European Enterprise Software Survey ‡ Source: Enterprise And SMB Software Survey, North America And Europe, Q3 2007 *Base: 911 North American and European enterprises † Base: 1,057 North American and European enterprises ‡ Base: 1,002 North American and European enterprises “ How familiar are you with Agile software development processes?”
  • 34. Industries Using Agile Practices Source: Enterprise And SMB Software Survey, North America And Europe, Q3 2007 Base: 1,017 North American and European enterprises (percentages may not total 100 due to rounding) “ How familiar are you with Agile software development processes?”
  • 35. Enhancing ROI
    • ROI in Software Projects
    • Plan-driven vs. Agile - more or less risk?
    ROI Scrum Brings ROI Back $ Time Release 1 Release 2 Release 3 Go Live
  • 36. Delivering Value Early With Less Risk Traditional vs. Agile Software Delivery Traditional Scrum Risk Project Run Rate Cumulative Value Risk Cumulative Value Project Run Rate Halt project when desired value is reached Start with high-risk, high-value items to drive down risk and maximize ROI
  • 37. Traditional vs. Agile Approach
  • 38. What Should I Expect With Agile?
  • 39. Forrester
  • 40.  
  • 41. Agile Is Pervasive Change Old Organization New Organization Centralized Distributed Unified perspective Diversified perspective Declared meaning Emergent meaning Analytical Creative Analysis leads to action Learning by doing Certain Uncertain Strategy concept Local action Authoritative Participative Authoritative; Hierarchical Shared Leadership
  • 42.
    • Agile is not “just a dev process change”
    • “ Caused by…” or “Revealed by…”
    Agile Is Pervasive Change
  • 43. Scrum Will Expose The Mess
  • 44. Satir Change Model Source: Virginia Satir – graphic by Steve Smith
  • 45. Resistance To Change
      • An individual's predisposition toward change
      • Surprise and fear of the unknown
      • Climate of mistrust
      • Fear of failure
      • Loss of status and/or job security
      • Peer pressure
      • Disruption of cultural traditions and/or group relationships
      • Personality conflicts
      • Lack of tact and/or poor timing
      • Non-reinforcing reward system
    Driving Forces Restraining Forces Why People Resist Change In The Workplace
  • 46. Resistance To Change
    • Why Organizations Resist Change
      • Structural or Bureaucratic Inertia
      • Group Norms
      • A Resistant Organizational Culture
      • Threatened Power
      • Threatened Expertise
      • Threatened Resource Allocation
    Driving Forces Restraining Forces
  • 47. Agile Is Simple…Yet Very Hard Agile Adoption Time Management Awareness Executive Sponsorship Wide-Spread Adoption Enterprise Team Grassroots
  • 48. How Do I Start Agile Well?
  • 49. Agile Myths
    • Lack of Discipline
      • “ Agile lets my Engineering Teams do whatever they want”
      • “ Quality of the product will fall off”
    • Lack of Visibility
      • “ I have no view into what is happening”
      • “ I can’t predict what I will get, or when”
    • Lack of Applicability
      • “ Agile is just for software geeks”
      • “ Agile is just for small teams”
    • “ Agile is easy”
  • 50. You Know You’re Not Doing Agile If …
    • Team is co-located, but not sitting within the length of a school bus to each other.
    • Team is distributed, but there is an absence of microphones and webcams and 1-2 meetings a day.
    • Team has not delivered anything to real users in the last 3 months.
    • If no user has seen real running software inside the last month.
    • They don't have the output of last month's retrospective on the wall.
    • They don't have fully automated unit tests, and a large number of acceptance tests aren't automated.
    • They're not having a build integration at least once a day.
    • They write big requirements documents, and they don't know how to split those up into smaller pieces.
    • They have itty-bitty requirements on the order of "here's what happens when you click here," but they don't have long-term vision.
    • People keep saying, "It's not my job.”
    Alistair Cockburn http://searchsoftwarequality.techtarget.com/qna/0,289202,sid92_gci1255480,00.html
  • 51. NOKIA Checklist
    • Iterations are longer than 6 weeks
    • Iterations are not timeboxed
    • Team tries to finish all specification before programming
    • Iteration doesn't result in workable code
    • Iterations doesn't include testing
    • Your product backlog doesn't contain estimates
    • You cannot generate a release burn-down chart and don't know your velocity
    • The team doesn't know who the product owner is
    • There is a project manager in the project who is [unnaturally] involved with [redirecting] the work of the team
  • 52. What Can Cause Agile/Scrum To Fail?
    • Ineffective use of the retrospective
    • Inability to get everyone involved with planning
    • Failure to pay attention to infrastructure required
    • Failure to have dedicated roles – ScrumMaster, Product Owner and Team
    • Product Owner that isn’t ready for the team
    • Reverting to form
    • Obtaining only “checkbook commitments” from executive management
    • Teams lacking authority and decision-making ability
    • A culture that does not support learning
    • The embrace of denial instead of the brutal truth
  • 53. Sample Rollout Plan
  • 54. Case Study: SEARCH
    • National Consortium for Justice Information and Statistics
    • Serves justice and public safety agencies
    • Three core offerings:
        • Systems and Technology
        • Law and Policy
        • Research and Statistics
  • 55. Case Study: SEARCH
    • Exceeded customer expectations
    • Delivered features on schedule and with high quality
    • Extended project to continue delivering features incrementally
    • Wish to replace web based JIEM tool
    • Users desire “stand alone”
    • Phase 2, more enhancements
    • Eclipse rich-client platform
    • Current features migrated with four 1-month “cycles”
    • Features developed and delivered in 2 week increments
    Justice Information Exchange Model (JIEM)
  • 56. Case Study: SEARCH
    • “ This project has exceeded my expectations, and I think really shows how a successful agile project should run.”
    • “ Quality has been consistently high, and I feel the application still has room to grow because they’ve practiced diligent refactoring and testing.  Their technical capabilities are top-notch.”
    • Director, Systems and Technology
    • SEARCH--The National Consortium for
    • Justice Information and Statistics
  • 57.
    • Helps handle changing requirements & priorities
    • Lowers cost of change
    • Provides better visibility into project progress
    • Reduces risk
    • Maximizes Return on Investment (business value prioritized)
    • Encourages higher quality, simpler code
    • Delivers business value early & often
    Benefits Of Agile Naresh Jain: http://www.slideshare.net/nashjain/agile-is-the-new-waterfall
  • 58.
    • Courage!!!
    • Constant business involvement
    • Need for more discipline
    • Greater emphasis on testing (and automation)
    • Whole organization involvement
    • Keep an open mind
    • Become a learning organization
    Agile Is NOT A Silver Bullet Naresh Jain: http://www.slideshare.net/nashjain/agile-is-the-new-waterfall
  • 59. Where Can I Learn More?
  • 60. Resources
    • BOOKS:
      • Agile Software Development with Scrum by Ken Schwaber, Mike Beedle
      • Agile Project Management with Scrum by Ken Schwaber
      • User Stories Applied by Mike Cohn
      • Agile Estimating and Planning by Mike Cohn
    • ONLINE:
      • www.agilealliance.org
      • www.scrumalliance.org
      • www.agileiq.org
  • 61.
    • We offer a full range of services—from training and consulting to development and talent acquisition
    • Leading provider of Scrum Certification Training
    • Headquarters in Redmond, WA. Founded in 1979
    SolutionsIQ
  • 62. Agile Services at Every Stage
  • 63. What Are Your Questions?