Software Agile Development An Introduction
Typical Software Project Lifecycle
Slow start as everyone attempts to make sense of what problem is being solved Struggle to interpret users requirements and translate into specification language Development team begins to build system, but soon realizes that solution cannot be delivered in allocated time Changes come in at rapid pace; Defects grow at a increasing rate Final months become a battle against the bugsovertime and weekends are the automatic responselife is miserablebut the end is near Pep talks from management about how great the team is when faced with adversity. Asks you to step up once more and show how you meet challenges System is delivered; Quality is questionable; Users are not satisfied; years of maintenance and patches neededwe celebrate! Project Post-Mortem On to the next project, where the same steps will be repeated
Copyright Scott W. Ambler
2
20th Century Software Development
1960s Ad Hoc Code-and-Fix Programming
1970s Waterfall or sequential lifecycle model
Taught as the the ideal approach; a way to explain the creative process Adopted by the US Department of Defense Assumed low-change, low-novelty, and low-complexity work
1980s Plenty of bad music and haircuts
Defense Spending during Regan Administration Commercial Software, Hardware, and Network companies forming
1990s US Department of Defense changes
Based on failure rate, changed to iterative development preference Standish Report comes out in 1994 Dot-com companies producing high-speed, high-quality products to meet market needs and survivehow?
Copyright Scott W. Ambler 3
Business of Software Development
Early software companies are technology-driven
Business people have to respond to what developers give them Focus on innovation and novelty Development as a black box activity
Focus then shifts to market-driven
Solutions to improve speed at which businesses can move Business people define product needs to Development IT departments became a cost to company bottom line Project Portfolio Management Feature Portfolio Management Incremental Funding Models Collaborative delivery of value Offshore development to save on costs Accountability and Visibility
Copyright Scott W. Ambler
4
Software Development and dot-com
In the dot-com era.
Investors and developers paid little attention to ROI thinking High demand for technical people Young, energetic workforce Get rich nowsacrifice everything Eat plenty of Pizza! Big Spending Pressure to get something to market quickly
After the bubble burst
End of the Y2K Fear September 11 Impact Downsizing, Rightsizing, & Global Competition Back to business basics
What did we learn?
Copyright Scott W. Ambler 5
Software Development Landscape
From the well-known Standish CHAOS Report 1994
Software projects fail: Cancelled - 31%; Late or lacking of features 53% Industry has only delivered on-time and on-budget 16% of the time! In 1995, this cost American companies well over $150 billion 94 of 100 projects will have restarts Average cost overrun is 189% 3 top reasons for failure Lack of user (sponsor) involvement No executive management support Unclear, incomplete, & changing requirements
Typical software project experiences a 25% change in requirements 45% of features defined in early specs are never used
Copyright Scott W. Ambler 6
Bridge to Success
The Standish Group concluded that keys to success are:
Shorter time frames Delivery of software components early and often Iterative process Growing" software vs. "developing" software Engage the user earlier Clear statement and set of objectives for components Keep it simple! - Complexity = confusion and cost
Copyright Scott W. Ambler
7
Introduction to Agility
Agility is a comprehensive response to the business challenges of profiting from rapidly changing, continually fragmenting, global markets for high-quality, high-performance, customer-configured goods and services Agility is the ability to both create and respond to change in order to profit in a turbulent business environment Agile projects are not controlled by conformance to plan but by conformance to business value Agility is a way of life, a constantly emerging and changing response to business turbulence
Copyright Scott W. Ambler
8
What About Standardization?
Department of Defense Specifications International Standards Organization (ISO) Software Engineering Institute (SEI) Capability Maturity Model (CMM) 5 Levels Project Management Institute (PMI) Body of Knowledge (PMBOK) Many derivatives as each company has created their own versions Standards have tried to capture the best practices of software development Organizations have tried to use these as prescriptive methods for success.and often failed
Copyright Scott W. Ambler 9
Three Flawed Assumptions
It is actually possible to plan a large project well enough that success is primarily determined by degree of conformance to plan It is possible to protect against late changes to a large system project It make sense to lock in big project decisions early
Copyright Scott W. Ambler
10
An emerging wave
Iterative Development
An approach in which the overall lifecycle is composed of several iterations, each a mini-project
Incremental Development
Concept of growing a system through a series of Iterations
Agile Development
Time-boxed Iterative, Incremental development that include values and practices that encourage rapid and flexible response to change flexibility/maneuverability to compete In IT: Scrum, XP, RUP, DSDM, FDD, Crystal In Construction: Last Planner
Results
88% of organizations cited improved productivity 84% cited improved quality 83% cited increase in overall business satisfaction
Copyright Scott W. Ambler
11
What is Agile?
An iterative and incremental (evolutionary) approach performed in a highly collaborative manner with just the right amount of ceremony to produce high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders.
Core principles
Fits just right process Continuous testing and validation Consistent team collaboration Rapid response to change Ongoing customer involvement Frequent delivery of working software
Copyright Scott W. Ambler
12
Values of Agile Development
individuals and interactions working software customer collaboration responding to change over over over over processes and tools comprehensive documentation contract negotiation following a plan
While there is value in the items on the right, we value the items on the left more.
Copyright Scott W. Ambler
13
How Agile is Different
Focus on collaboration:
Less paperwork and more conversation Stakeholders actively involved
Focus on working software:
Greater feedback makes agile projects easier to manage Less documentation is required Less bureaucracy
Agilists are generalizing specialists:
Less hand offs between people Less people required Specialists find it difficult at first to fit into the team
Agile is based on practice, not theory:
This is a significant change from traditional You need to see how agile works in practice to truly understand it
Copyright Scott W. Ambler 14
Mythbusters
Myth
No Documentation Undisciplined Planning No Not Predictable Does Not Scale a Fad Is Silver Bullet RUP isnt agile Not Fixed Price
Reality
Agile Documentation Requires great discipline Just-in-time (JIT) planning Far more predictable Eclipse is agile quickly becoming the norm Its It requires skilled people RUP is as agile as you make it Agile provides stakeholders control over the budget, schedule, and scope
Copyright Scott W. Ambler
15
Why Agile Works
Copyright Scott W. Ambler
16
Some Common Practices
Regular Deployment of Working Software Pair Programming Refactoring Continuous Integration Test Driven Development (TDD) Shared Code Ownership Active Stakeholder Participation
Copyright Scott W. Ambler
17
Agile Methods
Extreme Programming (XP) (Kent Beck, Ward Cunningham, Ron Jeffries) Scrum (Jeff Sutherland, Mike Beedle, Ken Schwaber) DSDM Dynamic Systems Development Method (Community owned) Crystal (Alistair Cockburn) ASD Adaptive Software Development (Jim Highsmith) XBreed (Mike Beedle)
Copyright Kyle R. Larson
18
All Agile Methods
Maximize value by minimizing anything that does not directly contribute to product development and delivery of customer value Respond to change by inspecting and adapting Stress evolutionary, incremental development Build on success, not hope
Copyright Kyle R. Larson
19
Weve Seen It Before
Lean Manufacturing (1990, Toyota) Agile Manufacturing Just-in-time JIT Common goals include:
Reduce Cycle Time Maximize Quality Reduce Costs
Copyright Kyle R. Larson
20
Lean
Lean means prioritize and optimize everything to deliver value to the customer One common technique: Postpone decisions until the last responsible moment. Live with uncertainty but define, communicate, and manage it
Lean Manufacturing and the Toyota Production System, SAE International
Lean Software Development: An Agile Toolkit, Mary & Tom Poppendieck, 2003
Copyright Kyle R. Larson
21
Scrum
Term in rugby to get an out-of-play ball back into play Term used in Japan in 1987 to describe hyper-productive development Used by Ken Schwaber and Mike Beedle to describe their Agile methodology
Copyright Kyle R. Larson
22
Extreme Programming
A collection of best practices each done to the extreme Sounds extreme, but very disciplined Created by Kent Beck, Ward Cunningham, Ron Jeffries
Copyright Kyle R. Larson
23
Scrum with Extreme Programming
SCRUM
Project Management Best Practices
EXTREME PROGRAMMING
Mostly Technical Best Practices
Scrum works well as a wrapper around Extreme Programming
Copyright Kyle R. Larson
24
Agile Independence
Not created by any single company, but by a group of software industry experts to find better ways of developing software by doing it and helping others do it.* Agile Principles:
highest priority is customer satisfaction welcomes changing requirements frequently deliver working software advocates close collaboration and rapid feedback reinforces inspect and adapt
* www.agilealliance.org
Copyright Kyle R. Larson
25
Agile Management
Defined Project Project Management vs. Empirical Project Management
Copyright Kyle R. Larson
26
Defined PM
Assumes we can predict how the project will unfold assumes very little uncertainty
Time to complete and costs predictable Uses work breakdown structure Manages to a static plan Primary participants: development team Success; On Time & On Budget
Copyright Kyle R. Larson
27
Empirical PM
Software and systems construction is a discovery process manages uncertainty Focuses on value/cost tradeoffs Plan is volatile; use discoveries to reprioritize and adjust Primary participants: project steering team Success; Delivering good value in reasonable time
Copyright Kyle R. Larson
28
PM End-Game
Almost all projects eventually revert to empirical PM
Copyright Kyle R. Larson
29
Both Are Needed
Defined PM works because many things in a project are deterministic. Defined model provides constraints:
deliver not the best solution, but the best we can afford
Entire Project Defined Empirical
Copyright Kyle R. Larson
30
Empirical PM Strategy
Early estimates of cost and value, tied to business processes Deliver subsets of functionality prioritized by business value Reassess and re-plan to fit resources, schedule, and discoveries
Copyright Kyle R. Larson
31
Best-Practice Scheduling/Tracking
Align accountability with responsibility Those who will produce the work, estimate the work Measure one level up Keep estimation techniques simple, consistent, and believable Generate, own, and use your own data
Copyright Kyle R. Larson
32
Empirical PM Getting Started
Early estimates, for mgmt to prioritize Structure more important than accuracy Sets confidence/predictability expectations Begins tone of inspect and adapt How system delivers value is as important as what it costs
Copyright Kyle R. Larson
33
Planning in Uncertainty
In list of business use cases leave rows for undiscovered process In list of system use cases leave rows for undiscovered use case In supplementary requirements section leave rows for unknown requirements Budget for technical solutions to be more complex than originally anticipated
Copyright Kyle R. Larson
34
Agile PM Concepts
Software construction is a discovery process Not the best solution; the affordable solution Invent successful outcomes
Copyright Kyle R. Larson
35
Scrum Overview
Empirical management and control process for projects and products Widely used since 1990s Wraps existing engineering practices Manages noise, allows overhead to wither Simple, common sense Delivers business functionality in 30 days Scalable
Copyright Kyle R. Larson
36
Scrum Scheduling and Tracking
Copyright Kyle R. Larson
37
Scrum Roles
Product Owner Team Scrum Master
Copyright Kyle R. Larson
38
Scrum Roles Product Owner
Single person who owns, maintains, prioritizes Product Backlog Empowered to make decisions for customers and users Responsible for vision, ROI, and releases of product Attends Sprint planning and Sprint review meetings
Copyright Kyle R. Larson
39
Scrum Roles - Team
Self-organizing, cross-functional, no formal roles Seven plus or minus two people Best experts available Cost and commit to work, and responsible for delivering Full autonomy and authority to deliver during Sprint
Copyright Kyle R. Larson
40
Scrum Roles Scrum Master
Project manager, Coach, and/or Player-Coach Responsible for process and maximizing team productivity Sets up and conducts meetings
Sprint Planning Daily Scrum Sprint Release
Copyright Kyle R. Larson
41
XP Definitions
Kent Becks idea of turning the knobs on all the best practices up to 10. Optimizing the Circle of Life by hitting the sweet-spot of practices that self-reinforce and become more than the sum of the parts (synergize).
Copyright Kyle R. Larson
42
XP Circle of Life
Customer Defines Value 1
Developers Build Value 4
2
Developers Estimate Cost
3
Customer Chooses Value
Copyright Kyle R. Larson 43
Cost-of-Change Curves
Flattening cost of change curve is both enabled by and exploited by Extreme Programming (XP)
Copyright Kyle R. Larson 44
The Four XP Values
Simplicity
Simplest thing that could possibly work YAGNI
Feedback
Testing Experimenting Delivering
Communication
Developers Users Customers Testers Code
Courage
Trust History
Copyright Kyle R. Larson
45
The Four XP Variables
Quality
Internal high, fixed
Schedule
Fixed-length, short iterations
Cost
People-Time Mythical Man-Month
Scope
Negotiable
Copyright Kyle R. Larson
46
Twelve XP Practices
Planning Game Short Releases Simple Design Testing Refactoring Pair Programming Collective Ownership Continuous Integration On-site Customer Sustainable Pace Metaphor Coding Standards
Copyright Kyle R. Larson
47
1. Planning Game
Release Planning: Define and estimate higher-level features down to about 5-10 days effort each. Customer lays features in fixed-length iteration schedule. Iteration Planning: Same, but to 3 or less days effort & detailed story cards within next iteration. Simple to steer project towards success.
Copyright Kyle R. Larson
48
2. Short Releases
Deliver business value early and often Do not slip iteration release dates
adjust scope within an iteration, never time or quality
Small, stable teams are predictable in short time-frames
Copyright Kyle R. Larson
49
3. Simple Design
XP Mantra: The simplest thing that could possibly work. Meet current, minimum business requirements only. Avoid anticipatory design. YAGNI You Arent Going to Need It
Copyright Kyle R. Larson
50
4. Testing
Automated unit tests for every entity. Automated acceptance tests for every story / requirement. All unit tests pass 100% before checking in a feature. Test-First, in small increments:
Write the test Prove it fails (red-bar) Code until it passes (green-bar)
Copyright Kyle R. Larson
51
5. Refactoring
Refactoring: changing internal structure without changing external behavior Remove duplication. Once and Only Once, Three strikes and your out. Leaves code in simplest form. When change is hard, refactor to al...