Discusses traditional Waterfall sequential development model with newer Agile iterative development methodologies such as used in Adaptive Software Development, Extreme Programming (XP), Feature-Driven Development (FDD), Scrum, and others.
3. Traditional Waterfall
Requirements
Analyze
Design
Implement
Test
Release
Sequential Steps
4. Agile Manifesto (2001)
“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.”
5. Agile Software Methods
Adaptive Software Development – ASD
Crystal Clear
Dynamic Systems Development Method – DSDM
Extreme Programming – XP
Evolutionary Development - EVO
Feature-Driven Development – FDD
Lean Development
Scrum
many other variations...
6. What is Agile?
Non-Waterfall, non-sequential
Incremental, iterative, time-boxed processes
Light-weight, designed for ease of use
Focused on flexibility
Targets maximizing product-value given fixed
resources and schedules.
Product-focus rather than process-focus
Deemphasizes long-range planning details
Focuses planning on the immediate iteration
Promotes openness and transparency
Provides improved visibility to stakeholders
7. Project Management
Workflow
Product
Vision
Document
Engineering
System
Establish Mitigate risks Milestone
milestone dates and Schedule
and goals dependencies
Project
Conduct Align
milestone schedules &
reviews communicate
status
Estimate and Align features Feature
prioritize to milestones Schedule
Feature
features
Report status Complete Review tasks
and remove work and assign
blockages resources
8. What‟s different with
Scrum?
Estimate and Align features Long-term
Feature
prioritize (Product)
features to milestones Schedule
Backlog
Retrospective
Time boxed: 30 days Short-term
(Sprint)
Backlog
Self-directed team
Report status Complete Review tasks
and remove work and assign
blockages
Feature
resources
“Sprint” Time boxed: daily Team Sync
(“Scrum”)
Visibility, inspection, adaptation
9. Daily Scrum
15 minutes once a day.
Each person answers three questions:
1. What did you work on yesterday?
(how much time did you spend?)
2. What will you will be working on today?
(any change to the remaining estimate?)
3. Do you have any blocking issues?
Recommend:
• Capture daily meeting minutes in pages on shared OneNote.
• Include a copy of the current Burndown Chart at the top of each day’s page.
15. Estimation “Cone of Uncertainty”
Analysis & Development Stabilization
Design
4x
Early estimates
vary wildly: 8x
Lots of surprises:
We learn as the
project progresses
- 4x
16. Work-Item Planning
1. Create a work breakdown schedule that
identifies the tasks to be completed.
2. For each task, define “done”. (see Defining “Done” next)
3. Estimate time* for each task. (see Planning Poker next)
If more than 3 days:
Decompose the task into 1/2 to 3 day work-items.
For each work-item, define “done”.
*All time estimates “unbuffered”.
17. Work-Item Planning – Agile Tips and Techniques
After creating a high-level breakdown of tasks, prioritize the high-level
task list based on a blending of the following three qualities:
1. Architecturally significant
If implemented, we are forced to design, build, and test the core architecture.
2. High product/business value – key critical product features
3. High risk (such as, “must be able to handle 2000 concurrent transactions")
(Applying UML and Patterns, Craig Larman, 2003, Ch 2.4, discussion of “Unified Process”).
Use a product-value naming convention to name features and tasks:
Naming Template:
<action> the <result> <by|for|of|to> a(n) <object>
Name Examples:
Calculate the total amount of a Sale
Calculate the total quantity sold by a Retail Outlet for an Item Description
Determine the most recent Cash Register Assignment for a Cashier
(Agile Software Development Ecosystems, Highsmith, 2002, Ch 20 “The FDD Process Model “)
18. Defining “Done”
Define “done” for each work item
Agree on how to know when an item is “done”.
Use a definition that clearly identifies when the item is complete.
Insert an Excel comment* for each item to note when it is “done”.
If assumptions about “done” change, re-do Planning Poker.
Result: Every Sprint item has a “Done” comment.
Ok: Coding complete (“complete” can be subjective)
Better: Coding complete, unit test complete,
working code and tests checked into branch. (“checked in” is definitive)
*TIP: Use Edit->Paste Special…->Comments to repeat the definition for like items
19. Planning Poker
Requires: Planning Poker card deck for each participant.
For each item in the Sprint Backlog:
1. Dev or test lead verbally describes the feature to be implemented.
2. Each person secretly selects an estimate card: 4,8,12,16,24,32,40,>40
Estimates are in unbuffered hours.
Estimates are only for the work to be completed during this Sprint.
3. Everyone reveals their cards at once.
4. High and low (and others) discuss their assumptions & decision.
5. Repeat until the estimates converge (typically 2 to 4 iterations).
6. Optional: Risk Assessment (“Three-point” / “Wide-band Delphi” technique)
On the final pass ask each person to select 3 cards:
an Optimistic time, a Most-Likely time, and a Pessimistic time.
The divergence of optimistic and pessimistic is useful to identify high risk items.
7. Fill in results in the Initial (estimate) column of the Sprint worksheet.
8. Estimate next item.
Result : Initial column filled in for all Sprint work items
22. Related Reading
5 Questions on Agile Development, October 2007, Steve McConnell
http://blogs.construx.com/blogs/stevemcc/archive/2007/10/08/5-questions-on-agile-development.aspx
Legacy of Agile Software Development, 2007, Steve McConnell
http://www.construx.com/Page.aspx?hid=1821
Why I Don‟t Use Story Points for Sprint Planning, Mike Cohn
(or “Estimate Sprint Work Items in „Hours‟ instead of „Story Points‟ ”)
http://blog.mountaingoatsoftware.com/?p=15
Don‟t Average During Planning Poker, Mike Cohn
http://blog.mountaingoatsoftware.com/?p=14
Toward a Catalog of Scrum Smells, Mike Cohn
(or “How to Tell When Good Scrum Goes Bad”)
http://www.mountaingoatsoftware.com/system/article/file/11/ScrumSmells.pdf
Editor's Notes
Show sample OneNote Scrum milestone notes for Packaging and RenderingShow sample Daily Scrum minutes from PackURI Feature Crew for FC070104Show PackURI progress sequence FC070921 to FC071016PackURI M1 Daily Scrum minutesonenote:http://windows/wex/dox/features/packaging/Shared%20Documents/DoxPack/Win7-Design/PackUri.one#section-id={0C4B7ED7-D427-45FF-9136-BDBC5D9F82A1}&endRendering M1 Daily Scrum minutesonenote:http://windows/wex/dox/features/rendering/Shared%20Documents/DOX%20Rendering%20Shared%20Notebook/M1%20Scrum.one#section-id={9C317007-35D7-4C72-B0D8-51889F75EF23}&end(Slide source & notes: jackd)