Foundations Mechanics Agile Software Development Planning
Transcript of Foundations Mechanics Agile Software Development Planning
Agile Software Development
www.agilecrossing.com
1
Agile Software Development Instructor – Roger Brown CST, CSC
Training Transition
Transformation
All slides © 2014 Roger W. Brown www.AgileCrossing.com
Topics
Foundations
Mechanics
Planning
Scrum Roles
Agile Success Factors
Agile Transition
Extreme Programming
Kanban
2
Agile Foundations
History Values
Principles Brands
3
Empirical Process
• Agile success relies on “Empirical
Process”
• Improvement comes from a continuous
learning cycle we call “Inspect and
Adapt”.
4
Continuous Improvement
Plan
Do Check
Act
Deming Cycle
Empirical Process Transparency,
Inspect and
Adapt
5
notes
6
Agile Software Development
www.agilecrossing.com
2
Agile Basics
• Agile software development implements
Lean principles and dynamics.
• Scrum is one form of Agile, designed
initially for software development but
applicable to other kinds of work.
7
Manifesto for Agile Software Development 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.
www.agilemanifesto.org
Agile Manifesto
8
What is Agile Software Development?
Team Based Incremental Iterative Frequent Delivery Fully Visible Production Quality Value Driven
9
Product Development Value Stream
Product Discovery
Product Definition
Product Development
Product Delivery
Product Operation
Support
Scrum/XP
Lean Startup
Lean UX
DevOps Kanban
Several complementary frameworks are available to increase organizational agility
Business success comes from maximizing value/time.
10
notes
11
Agile Mechanics
Scrum Framework and
Execution
12
Agile Software Development
www.agilecrossing.com
3
Scrum Framework
• Scrum has 4 meetings and 3 artifacts
• Scrum has 3 roles that share the
responsibility of creating value in small
increments
• The roles complement each other to
create a balanced team
13
Scrum Framework
Potentially Shippable Product
Increment
Sprint Backlog
Product Backlog
Release
Planning
Sprint
Planning
Sprint
Review Sprint
Retrospective
Daily
Scrum
1-4
weeks
Story Time
14
The Scrum Team
Desired Features
Product Owner
Development Team
Product
ScrumMaster
15
Product Owner
Maximizes the value of the work done
o Sets Vision o Manages Backlog o Elaborates Features o Reviews Work o Decides Release Dates
16
Development Team Member
o 7 ± 2 o Cross functional o Full-time o Self-organizing o Empowered
Develops the product with high quality
17
ScrumMaster
o Facilitator o Mentor o Coach o Leader o Change Agent
Helps the team improve flow
and throughput The ScrumMaster is the
Heart of Collaboration
18
Agile Software Development
www.agilecrossing.com
4
notes
19
Scrum Execution
• Scrum organizes work into 1-4 week time
boxes called Sprints
• Each Sprint has 4 primary meetings
• The bulk of the time is spent creating
value in the form of a product
20
Sprint Planning Meeting
Product Backlog
Sprint Backlog
Pri
ori
ty
Goal 1: What? • Which PBIs can will comprise our forecast? • What is our Sprint Goal? Ex. Build the shopping cart
Goal 2: How? • Design an implementation plan, often by decomposing into tasks • Double check our forecast
Attended by • Product Owner,
Development Team, ScrumMaster
• Other interested stakeholders
Time-box to 1 hour per week
of Sprint
Sprint Time Box
S1
1-4 weeks
Steady cadence, fixed length Abnormal Termination If the Sprint Goal cannot or should not be reached for
unexpected reasons, stop and plan a new Sprint
Focus No one can change the Sprint plan except the Scrum Team to add or
remove a PBI
S2 S3 S4
22
Daily Scrum
15 Min
The Three Questions What did you do yesterday? What do you plan to do today? Is anything blocking you?
23
Task Board
Sprint Burndown
Information Radiators
Item
24
Agile Software Development
www.agilecrossing.com
5
Sprint Review
• Purpose • Get feedback from the Stakeholders
• Demonstrate the completed stories
• Review progress and adjust future
• Identify new/changed features
• Attendees • Product Owner, Development Team, ScrumMaster
• Any other stakeholders
Preparation • Who will show what? • Deploy to a preview server • Any documentation needed? • Update and show release burnup chart
2 Hours
Show actual running
code!
Sprint Retrospective
• Scrum Team meets privately
• Goal is process improvement
• Format
• Review results of previous experiments
• Gather Data
Reflect on what worked well, what didn’t
• Generate Insights
Discuss results and new ideas
• Decide Action Items
Consider adopting new practices
Stop doing things that are not working
1.5 Hours
Stop Start Continue
Keep it interesting • Appreciations • Food • Variety
Sprint Timeline
Sprint 1 Sprint 2
Re
leas
e P
lan
nin
g Sp
rin
t P
lan
nin
g St
ory
Tim
e
Spri
nt
Re
vie
w\R
etr
osp
ect
ive
Continuous Elaboration of Product Backlog Items
Sprint N
Spri
nt
Pla
nn
ing
Sto
ry T
ime
Sp
rin
t R
evi
ew
\Re
tro
spe
ctiv
e
Spri
nt
Pla
nn
ing
Sto
ry T
ime
Sp
rin
t R
evi
ew
\Re
tro
spe
ctiv
e R
ele
ase
…
Daily Scrum is held every day except Review/Retrospective day.
notes
28
Agile Planning
5 Levels User Stories Prioritization
Estimation Release Planning
29
Agile Planning
• Agile planning is continuous
• Agile planning happens at 5 levels, each
with a different time horizon
• The Product Backlog is the primary
source of work to be completed and
value to be delivered
30
Agile Software Development
www.agilecrossing.com
6
Value Driven
Estimates
Features
Schedule Cost
Plan
Driven
The Plan creates
cost/schedule estimates
Waterfall
The Vision creates
feature estimates
Schedule Cost
Features
Value / Vision
Driven
Agile
Source: Sliger and Broderick “The Software Manager’s Bridge to Agility”
Constraints
31
Product Context - 5 Levels of Planning
Strategy
Portfolio
Vision
Roadmap
Release
Sprint
Day
P1 P2 P3 P4 P5
Product Backlog
Release 1 Release 2 Release 3
s1 s2 s3 s4 … sN
Scru
m P
lan
nin
g
32
Product Vision
• The Big Picture of how the product creates value
• Aligns team and business to the same goal
What is the name? Who is the target customer? What are the key benefits? What are the differentiating features?
33
Product Backlog
• Dynamic set of items to be done
• Prioritized
• Constantly in flux as the situation changes
Story
Story
Story
Spike
Story
Refactor
Story
Defect
Process Change
items are removed
priorities change
items are added
34
notes
35
User Stories
• User Stories are simple descriptions of
desired functionality
• User Stories have two attributes that are
helpful for planning: size and priority
• Stories are elaborated just-in-time for
implementation
36
Agile Software Development
www.agilecrossing.com
7
User Story Template
As a <user role>, I can <do something> so that <I get some value>.
37
Card – Conversation – Confirmation
Sample User Stories
As a student, I can get a degree on-line so that I do not have to move near a college campus
As an online student, I can print a copy of my transcript to show an employer
As a degree candidate, I can see which courses I still need to satisfy my major so I can plan my next term
As a professor, I can get student test summary reports so that I can assess my teaching effectiveness
38
Backlog Hierarchy
Epic User Story Task Task Task Task
User Story Task Task Task Task
User Story Task Task Task Task
Product Backlog
Sprint Backlog
Business Goal
Planning Implementation
39
Where are the details?
(front)
Story 6: Course Catalog Demo As a prospective student, I can browse the course catalog to see if the classes I am interested in are available.
(back)
Story 1 Acceptance Criteria [ ] Has full catalog browse and search controls [ ] Show available dates in summary list [ ] Item click leads to class detail page [ ] Show class star ratings only, no comments [ ] Replace “Register for Course” button with “Join Now!” that links to sign-up page
Automated Tests
Speclet • formula • UI design • screen flow • business rules
40
notes
41
Prioritization
• Priorities help the Scrum Team decide
what to do next
• Priorities help with long term planning
• Prioritization can be done in many ways,
based on many criteria
42
Agile Software Development
www.agilecrossing.com
8
Prioritization - MoSCoW
o Business value
o New knowledge
o Risk/Complexity
o Desirability
43
Story Map
Epic
I can browse by
department
I can search by subject
I can register
I can read content
I can browse by
title
I can unregister
I can browse by professor
I can join a waitlist
I can take tests
I can search by date offered
I can search by major
I can take classes on-line
Browse Search Register Attend Reports
I can do homework
I can print my
transcript
I can see my grade for a class
I can browse by popularity
Theme
Must
Should
Could
Pri
ori
ty
Smaller stories give more options for prioritizing for max value
44
I can print my
schedule
I can print my report
card
I can chat with
classmates
notes
45
Agile Estimating
• Agile estimation is done at both the high
level and the low level
• Estimates are used for planning and for
tracking progress
• Estimates are done quickly, by the
Delivery Team
• Estimates are not commitments
46
Why Estimate?
Story Points • High Level
• Compare one story to another
• Forecast Releases and Sprints
Task Hours • Low Level
• 1-8 hours for a Story element
• Refine Sprint plan
• Track Sprint progress
1 2 3 5 8 13
47
Estimation Basics
Quick
Story 1: Home Page As a prospective student, I can view the college services so that I can decide if I want to apply.
2 Story 17: Major Progress
As a degree candidate, I can see which courses I still need to satisfy my major so I can plan my next term
5
Quick
Relative
Guess
Done by Team
More than 2x effort required
48
Agile Software Development
www.agilecrossing.com
9
Affinity Estimating
Groups of 2-3 people choose some stories
Put in column with similar sized stories
Team members
can move stories
Visual grouping for quick comparisons
1 2 3 5 8 13 20
49
Start with numbers
or arrange by size
first
Velocity
5
12
27
32
36 38
40 37 38
40
0
5
10
15
20
25
30
35
40
45
1 2 3 4 5 6 7 8 9 10
Sto
ry P
oin
ts C
om
ple
ted
Sprint
Team Velocity
How many story points can the Team complete in a Sprint?
Varies by circumstance, increases with
experience
Aggregates Team dynamics and organizational
factors
Is measured, not “managed”
50
Velocity is sum of estimates of
stories completed
notes
51
Long Term Planning
• Scrum-built products may have
Roadmaps and Release Plans
• Team velocity is a measure used in long
term planning
52
Product Roadmap
First sub-setting of Product Backlog for a long product development time frame
• How many releases?
• When?
• What is included in each?
Tim
e
Continuing Education for Professionals
Undergraduate Degrees
Graduate Degrees
The roadmap will be reviewed and updated as things
change
Product Backlog
Releases
53
Velocity
5
12
27
32
36 38
40 37 38
40
0
5
10
15
20
25
30
35
40
45
1 2 3 4 5 6 7 8 9 10
Sto
ry P
oin
ts C
om
ple
ted
Sprint
Team Velocity
How many story points can the Team complete in a Sprint?
Varies by circumstance, increases with
experience
Aggregates Team dynamics and organizational
factors
Is measured, not “managed”
Velocity is sum of estimates of
stories completed
Measurement is more reliable
than estimation
Agile Software Development
www.agilecrossing.com
10
The Elements of Agile Planning
Product Backlog
Must
Should
Could
Won’t in this
Release
s1
s2
s3
…
sN
Release as often as possible
Newsworthy Release Event
Tim
e
Sprints
Priorities Which items are most valuable?
Velocity How much can the team complete in a Sprint?
Estimates How much effort is expected for each item?
Product Backlog What functionality Is needed for financial success?
Release Forecast (volume):
1. How long will it take? Number of Sprints = Total Backlog/Average Velocity 2. How much can we do? Percent of Backlog = Total Backlog/(Average Velocity * Number of Sprints)
Release = a series of Sprints resulting in a marketable delivery of value.
Release Planning Meeting
Share the Vision
Create Prioritized Backlog
Forecast Team Velocity
Forecast Release
1-2 days
Release = a series of Sprints resulting in a marketable release of value.
Visual Progress
Release Backlog
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Q1 Release
Q2 Release
Q3 Release
How much will we complete?
How much is done so far?
Progress is reported in units of actual product ready for
delivery
57
notes
58
Scrum Roles
Product Owner Development Team
ScrumMaster
59
Product Owner
• The Product Owner navigates the product to maximum business value
60
Agile Software Development
www.agilecrossing.com
11
Define the Product
Build the Product
Plan the Product
It’s a Big Job
Corporate Strategy Portfolio Alignment Customer Needs Corporate Needs Competition Stakeholders
Product Vision Revenue Target
Product Backlog Priorities
Funding UX
Dev Team Collaboration Scrum Framework
Product Details Product Review
Release Plan
What else?
61
Product Owner Attributes
• Domain knowledge
• Empowered to
• Spend budget
• Define vision
• Make release decisions
• Understand what customers want
• Available to the team
• Actively manage stakeholders
• Familiarity with product development
• Team protector
62
Managing Value
Return on Investment =
Benefits – Costs
Costs
Cost is easy with a fixed team size and
Sprint length
Benefit is not so easy to
determine Elements of Business Value • Increased sales • Accelerated sales • Decreased expenses • Customer satisfaction/retention • External compliance • Market differentiation
63
Agile Goals for Business
Faster Time to Market
Quicker ROI
Lower Total Cost
Respond to Change
Reduced Risk
Stakeholder Relations
64 Predictability
Manage the Profit Strategy
Time
Pro
fit
competition
market penetration
customer feedback
innovation
compliance
internal stakeholders
market changes
The Product Owner balances competing demands to maximize value/time
65
notes
66
Agile Software Development
www.agilecrossing.com
12
Development Team
• The Team is self-organizing • Teams go through a maturation process
67
Key Success Factors
• Self-organizing
• Cross-functional
• Full-time dedicated
• Work in a shared space
• Empowered to make decisions
• Team Working Agreement
• Definition of Done
• Automated Testing
• Right Skills and Tools
68
Tuckman's Team Development Model
Storming
Forming
Norming
Performing
• Teams go through four stages
• Teams can regress when membership changes
Time
Effe
ctiv
en
ess
69
Motivation
• Financial rewards often give poor results • Intrinsic vs. extrinsic motivation • People are motivated by
• autonomy • mastery • purpose
See Dan Pink, TED.com and Drive
70
Create
Validate Improve
Agile Goals for Developers
Cadence
A Sense of Done
0
20
40
60
M T W T F M T W T F
Wo
rk R
emai
nin
g (h
rs)
Visible Progress
Quality Work
Feedback
Teaming
71
notes
72
Agile Software Development
www.agilecrossing.com
13
ScrumMaster
• The ScrumMaster is responsible for the health and growth of the Scrum Team
• The ScrumMaster is a facilitator, mentor, negotiator, protector, coach and servant leader
73
Facilitator
• Keep meetings productive and short
• Mediate disputes
• Grease the wheels
74
Coach
• Lead people to their own solutions
• Aware of the bigger picture
• Able to mentor individuals
• Knows when • to be prescriptive • to nudge • to keep distance
It’s better to be paying attention than to have all
the answers - Ward Cunningham
75
Servant Leader
• Lead vs. Manage
• Lead to make others better
• Increase teamwork and personal involvement
• Lead by example
76
Day in the Life of a ScrumMaster
Manage impediments Facilitate meetings Mediate and negotiate Teach Scrum Manage the process Assist the Product Owner
Observe and coach Team Encourage excellence Protect Team from distractions Build relationships Promote Organizational Agility Administer
ScrumMaster 7 Team Members Productivity
77
notes
78
Agile Software Development
www.agilecrossing.com
14
Agile Success Factors
Focus and Flow Scrum Enhancers
Managing Technical Debt
79
Focus and Flow
• Scrum works best when the Team
achieves a smooth flow of work
• Scrum dynamics are based on the
mathematics of queuing theory that we
use to manage the Internet
80
Pull Systems
Push systems overwhelm capacity, creating turbulence, rework, waste and delay
Pull systems have a steady flow that provides predictability
Push
♫
81
Small Batches
Small batches move through
a system quicker
Single-piece-flow reduces the wait time
and moves risk to the
margin
Minimize work in progress
82
notes
83
Scrum Enhancers
• A 1-sprint look-ahead on stories will help
the flow
• Defining Ready and Done will
dramatically reduce time waste
84
Agile Software Development
www.agilecrossing.com
15
Backlog Grooming
Product Owner spends 30% of their time working on the Product Backlog
• Identify new stories
• Splitting epics and stories
• Updating Release Plan with current velocity data
• Adjusting priorities
• Preparing next stories
• Designing user experience
85
Story Time
Development Team spends 5-10% of Sprint with the Product Owner preparing for the next Sprint
• Reviewing candidate stories
• Getting details and acceptance criteria
• Some technical design
• Estimate new stories
• Considering new ideas
Often a regular meeting 1 hour/week
or 2-3 hours mid-sprint
86
Definition of Ready
Negotiate with your Team - What they need for each story - When they need it
87
Sample Right size Screen sketches Acceptance criteria Dependent stories? Speclets
Definition of Done
Unit tested to 90% code coverage Code reviewed Acceptance tests pass UI Tested User Help updated Deployment scripts updated
• When estimating size, consider all the work needed to complete the story
• The Definition of Done may evolve over time
Sample
May also have one
for sprints and
releases
88
Sprint Flow
Sprint N Sprint N+1
Candidate Stories for N+1 (1.5 x velocity)
Definition of Ready
Screen Designs for N+1 (LoFi)
Continuous Product Backlog Grooming
Story Time Sprint Planning
89
Definition of Done
notes
90
Agile Software Development
www.agilecrossing.com
16
Managing Technical Debt
• Technical Debt is poorly designed code
written to save time
• Technical Debt compounds over time
• Regular payments on Technical Debt will
enhance agility
91
Sources of Technical Debt
• Known defects left for later
• Stories not finished
• Overly complex code
• Unreadable code
• “Clever” solutions
• Poor designs
• Hard-to-test code
• Disabled code
92
Cost of Technical Debt
Cost to fix a defect as time passes
Impact on Team Velocity over time
Debt avoidance
Debt accumulation
Delayed debt payments
93
Managing Technical Debt
• Test-Driven Development
• Pair Programming
• Legacy debt payment allowances
• Boy Scout Rule
• Agile design training
• Code quality measurement tools
• Tech Debt Backlog
• Refactor stories
94
notes
95
Agile Transition
Scaling Agile Up and Out Organizational Change
Management’s Role
96
Agile Software Development
www.agilecrossing.com
17
Scaling Agile Up and Out
• Agile can scale to many Teams
• Distributed Agile is constrained by the
laws of physics but there are patterns
that can help
97
Scaling Agile Up
Multi-Team Product • Team is the scaling unit
• Divide work across multiple small teams
• by feature
• by component
• Organize with Chief Product Owner Team and Scrum of Scrums
SoS
tactical
Team 1 Team 2 Team 3 Team 4
CPO strategic
98
Distributing Scrum Out
• How well does it work? Scrum is the best way to manage distributed Teams. Distributed Teams are not the best way to do Scrum.
• But distributed teams are a common reality so
• Prefer whole teams at each location
• Start project co-located
• Have ambassadors who travel
• Have buddies across locations
• Expect more documentation
• Don’t let anyone go dark
• Use video, IM, artifact sharing tools
99
notes
100
Organizational Change
• Agile development is simple but not easy
• Organizations are resistant to change
• Choosing the easy parts may fail to give
the desired results
101
Satir Change Model
102
Agile Software Development
www.agilecrossing.com
18
Scrum Challenges
• Scrum is a vehicle for change • Not a process
• Scrum challenges the status quo • Reveals impediments and dysfunctions
in the organization
• Uncovers opportunities to excel in the market
• Partial Scrum will hide the dysfunctions
• Largest impediments are waterfall habits • Predictive thinking
• Command and control
• Demanding something will make it happen
• Willingness to sacrifice quality
- Ken Schwaber
Hybrid Scrum
103
Success Factors
• Involved Leadership • Emphasis on Customer Value • Empirical Process • Dedicated Cross-functional Teams • Decentralized Control • Enhanced Collaboration • Pull Systems • Modern Technology • Coaching
104
notes
105
Management’s Role
• Agile Leadership vs. Traditional
Management
• Decentralized Control
• Manager’s Value Proposition
• Leading Agile Change
106
Management or Leadership?
107
Old New
Responds to change Embraces change
Knows the answers Fosters new ideas
Bureaucratic Collaborative
Leader Decides Decentralized decisions/ownership
Authoritarian Influential
Decentralized Control
• Business set the strategy • Team is empowered to choose and
execute the tactics
108
Agile Software Development
www.agilecrossing.com
19
Management Value Proposition
Results
Value - faster time to market - right product - higher quality - lower cost
Competitive Advantage - adaptability to changing market - risk mitigation - customer satisfaction
Productivity - transparency - reduced waste - motivated workforce
Contributions
Lead - set the strategy - champion the changes - enable an Agile workplace
Participate - guide the strategy - observe and comment - sponsor Agile management teams
Expect change - make changes as needed - socialize the changes
109
Visible Status in an Agile Enterprise
Enterprise Transition Team manages an improvement backlog
Management can view the status of any project or portfolio at any time
110
notes
111
Extreme Programming
Quality Testing
Agile Engineering
112
Quality and Testing
• Automated acceptance testing is used to ensure the right product is built
• Unit testing ensures the product is built right
113
Elements of High Quality
• Less re-work
• Fewer trouble calls
• Higher customer satisfaction
• Easier to enhance the product
• No “technical debt”
Build quality in! It’s cheaper in the long run.
114
Agile Software Development
www.agilecrossing.com
20
The Testing Pyramid
Manual Tests through UI
Automation Suites
Unit Tests
Automated UI Tests
Automated Acceptance
Tests
Unit Tests
Traditional (find bugs)
Agile (prevent bugs)
Exploratory
testing
115
Single Piece Flow
Do This
Don’t Do This
116
notes
117
Agile Engineering Practices
Review of complimentary practices
118
Complementary Practices
• Co-location
• Pair Programming
• Refactoring
• Test-Driven Development
• Continuous Integration
• Exploratory Spikes
• Legacy System
Strategies
• Evolutionary Design
• Agile Architecture
119
Co-location
• Maximum communication
• Quicker resolutions
• Team Trust
• Learning
• Reduced overhead
• Better focus
Productivity can double!
120
Agile Software Development
www.agilecrossing.com
21
Pair Programming
• Team members work side-by-side
• Better Design
• Higher Quality
• Shared Knowledge
• Continuous Learning
121
Refactoring
• Improve design without changing function
• Well known patterns
• Always leave the code better than we found it
122
TDD Rhythm
Add a test
Run test and fail
Write code to pass test
Run tests, all pass
Refactor
Remove duplication and improve
design
Compile or logical failure
Just enough to pass!
Start a task
123
TDD Screen Shot
124
Benefits of TDD
• Higher quality
• Testing is not short-changed
• Safer to refactor
• Living Specification
• Cadence and Momentum
• Confidence
125
Number of Tests
Con
fid
enc
e
Continuous Integration
126
Agile Software Development
www.agilecrossing.com
22
Exploratory Spikes
• Time-boxed experiment with stated goals • Support feature or task estimates
• Explore unfamiliar technologies or components
• Prototype and compare major design alternatives
• Story or task-sized
127
Acceptance Test Examples
• Based on Use Case • The “sunny day scenario” is one test
• Each exception scenario can be another
• Activity description • When a user clicks on the Options screen, a modal panel of option categories opens defaulting
to the General tab
• Algorithm or formula check • Give a purchase price of $1.25 and a deposit of $5.00, the vending machine will return change
consisting of 3 dollar bills and 3 quarters
• Spread sheet
• Entitlement rule • A Supervisor can view work orders initiated by someone else but not change them
input input output output output output output
price deposit dollars? quarter? dimes? nickels? pennies?
1.25 5.00 3 3 0 0 0
1.15 2.00 0 3 1 0 4
0.85 1.00 0 0 1 1 0
128
FitNesse Screen Shot
129
Legacy System Strategies
• Legacy System == system with no tests
• Known patterns
• Write “characterization tests” to reveal current behavior
• Work in small steps
• Debug with unit tests
• Look for seams
• Break dependencies
130
Evolutionary Design
• Whiteboard vs. design document
• Constant refactoring
• YAGNI – no gold plating, minimal complexity
• Change is the norm
• Write readable code
• Write testable code
• Design to interfaces
• Use design patterns wisely
131
Agile Architecture
• Architecture == anything that is hard to change
• Design for 90%, not the last 10%
• Wire frame
• Encapsulate dependencies
• Loose coupling, high cohesion
132
Agile Software Development
www.agilecrossing.com
23
notes
133
Kanban
134
Kanban
• Kanban is a simple Agile form based on
visual management and limiting work in
progress
• It is best for work that is highly variable
and not under control of the team
135
Kanban
Work Requests
Managed Queue
Varied items are pulled into a work stream
when someone has time to deal with them.
Irregular arrival of requests is smoothed
into to a predictable output flow.
time
136
Kanban Core Properties
• Visualize the workflow • Limit WIP • Measure and manage flow • Make process policies explicit • Improve collaboratively using models and the
scientific method • Theory of Constraints • Systems Thinking • Deming • Toyota Product System
137
Kanban Board
138
Ready Analysis Develop Code Review
Test Release
8 4 3 5 4 8
Self Assignment
Incremental Improvement
WIP Limits
Prioritization Visual Management
Agile Software Development
www.agilecrossing.com
24
Scrum vs. Kanban
Scrum Kanban
Teams required Teams may emerge
Explicit roles No new roles
Sync input and output cadence Input and output cadence are independent
Defined artifacts, meetings, teams Start with current work flow, evolve process
Quick estimation No estimation
Measure velocity Measure throughput
Sprint-sized batches Continuous flow with WIP limits
Multiplicative increases in productivity from Team synergies
Fractionally improved productivity from incremental changes
Promotes innovation through sustained collaboration
Focused on task-sized work by silo-ed individuals
Long term predictability Near term predictability 139
notes
140
Instructor
Roger Brown
• Agile Coach
• Scrum Alliance
• Contact Web: www.agilecrossing.com
Email: [email protected]
Twitter: @rwbrown
Blog: www.agileCoachJournal.com
LinkedIn: http://www.linkedin.com/in/rogerwbrown
V 3.5
141
Agile Software Development Instructor – Roger Brown CST, CSC
Training Transition
Transformation
All slides © 2014 Roger W. Brown www.AgileCrossing.com