Why Agile? Why Now? IPMA Forum 2009

Why Agile? Why Now? IPMA Forum 2009 May 19, 2009

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

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?

"If you keep on doing what you've always done… you'll keep on getting what you've always got."

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

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

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

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?

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.

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.

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

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

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

The Agile Umbrella Scrum XP Crystal Lean DSDM FDD AGILE

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

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

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

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?

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?

Deliver Working Software Frequently OBJECTIVE: Deliver a Product Increment in a fixed time period (called a Sprint) Sprint Length Commit & Deliver

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

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

Product Engineering – Then & Now Collaboration Innovation Releases Feedback Customers Process Architecture Culture Testing Tools

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

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?”

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?”

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?”

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

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

Traditional vs. Agile Approach

What Should I Expect With Agile?

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

Agile is not “just a dev process change” “ Caused by…” or “Revealed by…” Agile Is Pervasive Change

Satir Change Model Source: Virginia Satir – graphic by Steve Smith

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

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

Agile Is Simple…Yet Very Hard Agile Adoption Time Management Awareness Executive Sponsorship Wide-Spread Adoption Enterprise Team Grassroots

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”

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

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

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

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

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)

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

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

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

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

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

Why Agile? Why Now? IPMA Forum 2009

More Related Content

What's hot

Similar to Why Agile? Why Now? IPMA Forum 2009

More from skipangel

Recently uploaded

Why Agile? Why Now? IPMA Forum 2009

Editor's Notes