No Bull Agile - techtowntraining.comtechtowntraining.com/.../No-Bull-Agile-2.pdf · Outrageous Agile (“Agile Bull”) •New vocabulary, old practices •Agile as a “Methodology”
Post on 11-Jun-2020
4 Views
Preview:
Transcript
No Bull AgileMarc J. BalcerSeptember 2017
Origins of Agile
Outrageous Agile
No Bull Agile
What’s your most outrageousexperience with an
agile project?I notice he
doesn’t capitalize
“agile”
Outrageous Agile (“Agile Bull”)
• New vocabulary, old practices
• Agile as a “Methodology”
• Agile is just “lots of little waterfalls”
• All user stories must fit one form
• Create a big backlog up front
• No definition of “done”
• Coding done but testing incomplete
“No Bull Agile”
We Favor
• Reason over Rigidity
• Content over Ceremonies
• Diagrams over Documents
• Tests over Tasks
Once upon a time…
Agile Manifesto
We are uncovering better ways of developing software. 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
The dirty little secret of the Agile Alliance
Consumer Auto Finance
• Followed PMI principles
• Planned as Lotus Notes systemto be delivered in 2000
• 9 months of business analysis
• 6 months of software design
• 13 months of development and testing
• Died a slow, horrible death
1998: A Tale of Two Leasing Projects
Consumer Auto Finance
• Followed PMI principles
• Planned as Lotus Notes systemto be delivered in 2000
• 9 months of business analysis
• 6 months of software design
• 13 months of development and testing
• Died a slow, horrible death
Construction Equipment Finance
• “What’s PMI?”
• “In 60 days can you build a web app for dealers to enter credit apps?”
• “You’re nuts!”
• “Each deployment changes our vision”
• “What do you need next?”
• Deployed and still running today
1998: A Tale of Two Leasing Projects
Consumer Auto Finance
• Followed PMI principles
• Planned as Lotus Notes systemto be delivered in 2000
• 9 months of business analysis
• 6 months of software design
• 13 months of development and testing
• Died a slow, horrible death
Construction Equipment Finance
• “What’s PMI?”
• “In 60 days can you build a web app for dealers to enter credit apps?”
• “You’re nuts!”
• “What do you need next?”
• “Each deployment changes our vision”
• Deployed and running today
1998: A Tale of Two Leasing Projects
(the rabid agilist)
See! This proves that
waterfall is EVIL!!!!
The Poor Maligned Waterfall
Maintenance Deliver it and keep it going
Requirements Know what the customer wants
Design Figure out how to build it
Implementation Build it
Testing Compare “as built” to the requirements
The Poor Maligned Waterfall
Maintenance
Requirements
Design
Implementation Can you build without knowing the needs or having a design scheme?
Testing Can you deliver an untested product?
The Poor Maligned Waterfall
Maintenance
Requirements
Design
Implementation Can you build without knowing the needs or having a design scheme?
Testing Can you deliver an untested product?
It’s not the waterfall.It’s the size of the blocks.
“Size of the blocks?”
On October 25, 2019 Sam will be coding
the online loan payment page.
Really…???
This week Sam will be adding
fields to the credit application
Reliable
The Real Difference
When people say
“Waterfall” vs. “Agile”
they really mean
“Predictive” vs. “Adaptive”
Predictive
When I know everything up front• I can plan every step
• I measure progress as tasks completed against that project plan
but
• Changes mess up that planand are to be avoided at all cost
Adaptive
I’m not going to know everything up front• Short term, I’m pretty certain• Further out, I’ll stay looser
(so I can respond to the business)
• I measure progress by delivered business value
and
• Change happens(“Now that I am doing this, …”)
The Real Difference
Predictive
• I need to gather every requirement
• I need to write all the use cases
• I need to know all the ways things can be different or go wrong
and then
• I have to put it all into a big, comprehensive requirements document
Adaptive
• What’s the simplest thing that can possibly work?(the “minimum viable product”)
• If we don’t do it now we can always add it later as needed
and then
• Let’s start doing real workand, with the customer,evaluate as we go
Perspectives on Analysis
Agile Manifesto
We are uncovering better ways of developing software. 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
Agile Manifesto
We are uncovering better ways of developing software. 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
Outrageous Agile
Outrageous Agile
• New vocabulary, old practices
• Agile as a “Methodology”
• Agile is just “lots of little waterfalls”
• All user stories must fit one form
• Create a big backlog up front
• No definition of “done”
• Coding done but testing incomplete
Old Way Agile Way
Requirement User Story
Use Case Big User Story(or is a user story a little use case?)
Requirements Document Backlog (of user stories)
Waterfall Phases Lots of little waterfalls
“It’s just new words”
Outrageous Agile
• New vocabulary, old practices
• Agile as a “Methodology”
• Agile is just “lots of little waterfalls”
• All user stories must fit one form
• Create a big backlog up front
• No definition of “done”
• Coding done but testing incomplete
The Rabid Agilist
In the Agile Methodology
there is only ONE TRUE WAY!
“The Agile Methodology”
Outrageous Agile
• New vocabulary, old practices
• Agile as a “Methodology”
• Agile is just “lots of little waterfalls”
• All user stories must fit one form
• Create a big backlog up front
• No definition of “done”
• Coding done but testing incomplete
Outrageous Agile
• New vocabulary, old practices
• Agile as a “Methodology”
• Agile is just “lots of little waterfalls”
• All user stories must fit one form
• Create a big backlog up front
• No definition of “done”
• Coding done but testing incomplete
Waterfall in the Extreme
Maintenance
Requirements
Design
Implementation
Testing
Design
Impl
Test
Design
Impl
Test
Design
Impl
Test
Design
Impl
Test
Design
Impl
Test
Design
Impl
Test
Concurrent Activities
Delivery and Maintenance
Requirements
Design
Impl
Test
sprint
Not mini-waterfalls
Delivery and Maintenance
Requirements
D
I
T
D
I
T
D
I
T
D
I
T
D
I
T
D
I
T
D
I
T
sprint
Not mini-waterfalls
Delivery
Requirements
Design
Implementation
Testing
Team produces automated unit tests for
code functions…
…but the (automated) tests for the UI features aren’t done until later
Customer & Product Owner see the new features and running tests
Iteration Planning
Demo
Retrospective
Design
Impl
Test
Design
Impl
Test
Design
Impl
Test
Design
Impl
Test
Design
Impl
Test
Design
Impl
Test
Concurrent Activities
Delivery and Maintenance
Requirements
Design
Impl
Test
sprint
Outrageous Agile
• New vocabulary, old practices
• Agile as a “Methodology”
• Agile is just “lots of little waterfalls”
• All user stories must fit one form
• Create a big backlog up front
• No definition of “done”
• Coding done but testing incomplete
Outrageous Agile
• New vocabulary, old practices
• Agile as a “Methodology”
• Agile is just “lots of little waterfalls”
• All user stories must fit one form
• Create a big backlog up front
• No definition of “done”
• Coding done but testing incomplete
Outrageous Agile
• New vocabulary, old practices
• Agile as a “Methodology”
• Agile is just “lots of little waterfalls”
• All user stories must fit one form
• Create a big backlog up front
• No definition of “done”
• Coding done but testing incomplete
User Stories
“A short, simple description of a feature
written from the perspective of the user who will
make use of the feature.”
An employee can report a personal car expense by specifying a date
and miles driven.
A manager must identify the specific expense items that led to
rejecting the expense report.
Agile Manifesto
We are uncovering better ways of developing software. 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
User Stories
Card• Keep it short
Conversation• Enough to get the team to
understand and agree to the need
Confirmation• Know when you are done
An employee can report a personal car expense by specifying a date
and miles driven.
A manager must identify the specific expense items that led to
rejecting the expense report.
Ron Jeffries, “Essential XP: Card, Conversation, Confirmation”
Individuals and Interactions over Processes and Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation
Responding to Change over Following a Plan
Agile Manifesto
We are uncovering better ways of developing software. Through this work we have come to value:
What?!
No big requirements
document?
Individuals and Interactions over Processes and Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation
Responding to Change over Following a Plan
We are uncovering better ways of developing software. Through this work we have come to value:
Only user stories?!
No more use cases, models—nothing but little
user stories!
Card• Keep it short
Conversation• Enough to get the team to
understand and agree to the need
Confirmation• Know when you are done
User Stories
“As an industry, we love syntax wars”—Gojko Adzic and David Evans. Fifty Quick Ideas to Improve Your User Stories.
“As a ___I want ___So that ___
There’s NO OTHER WAY!
An employee can report a personal car expense by specifying a date
and miles driven.
Have the option to enter start and end odometer readings for
personal car expenses.
User Stories
Card• Keep it short
Conversation• Enough to get the team to
understand and agree to the need
Confirmation• Know when you are done
An employee can report a personal car expense by specifying a date
and miles driven.
Have the option to enter start and end odometer readings for
personal car expenses.
Outrageous Agile
• New vocabulary, old practices
• Agile as a “Methodology”
• Agile is just “lots of little waterfalls”
• All user stories must fit one form
• Create a big backlog up front
• No definition of “done”
• Coding done but testing incomplete
The “Backlog”
The set of user stories that have been identified
but not committedand not completed.
The “Backlog”
• What’s been requested(the total set of stories)
• What’s most important to do next(the prioritization)
• What can be reasonably done in the next sprint(the sprint plan)
• What’s left(the backlog)
Agile ≠ BRUF*
BigRequirementsUpFront
*
Now what about the group that starts their agile project by producing 10,000 stories?
trip planningadvancesexp reportingapprovalspaymentscust billing
Planning Levels
SprintCommitted current workorganized as user stories, scenarios, and tasks
Product BacklogWork yet to be doneorganized as user stories
RoadmapLong-term goalsusually specified as broad categories
* Some of this vocabulary is specific to Scrum
trip planningadvancesexp reportingapprovalspaymentscust billing
Planning Levels
Product BacklogWork yet to be doneorganized as user storiesand other items
RoadmapLong-term goalsusually specified as broad categories
SprintCommitted current workorganized as user stories, scenarios, and tasks
Roadmap
• Long-Term Vision
User Stories
• Short-Term Objectives
Roadmap Direction vs. Story Specifics
Integrate with the trip approval system
Issue reimbursements through payroll
Report personal car expenses by specifying a
date and miles driven
Report personal car expenses by specifying start and end odometer
readings
this increment
backlog(future)
Associate gift and meal expenses using a
provider’s NPI
Agile ≠ BRUF*
BigRequirementsUpFront
*
Now what about the group that starts their agile project by producing 10,000 stories?
Outrageous Agile
• New vocabulary, old practices
• Agile as a “Methodology”
• Agile is just “lots of little waterfalls”
• All user stories must fit one form
• Create a big backlog up front
• No definition of “done”
• Coding done but testing incomplete
User Story Card Principles (the “three Cs”)
Card• Keep it short
Conversation• Enough to get the team to
understand and agree to the need
Confirmation• Know when you are done
Report personal car expenses by specifying a
date and miles driven
Report personal car expenses by specifying start and end odometer
readings
Typical Sprint Planning
• Select the stories to be done
• Define the tasks needed to complete them
• Agree upon the acceptance criteria for each story (and the iteration)
17-7
Tasks!Tasks!Tasks!
Tests No Surprises
Report personal car expenses by specifying a
date and miles driven
Report personal car expenses by specifying start and end odometer
readings
Who Tests What When?
Delivery
Requirements
Design
Implementation
Testing
Product Owner & Customer define requirements in terms of acceptance criteria(the “back of the card”)
Team accepts a story only once the acceptance criteria are detailed in specific scenarios (“if it does all this, it’s good”)
Iteration Planning
Demo
Retrospective
per story
Outrageous Agile
• New vocabulary, old practices
• Agile as a “Methodology”
• Agile is just “lots of little waterfalls”
• All user stories must fit one form
• Create a big backlog up front
• No definition of “done”
• Coding done but testing incomplete
Outrageous Agile
• New vocabulary, old practices
• Agile as a “Methodology”
• Agile is just “lots of little waterfalls”
• All user stories must fit one form
• Create a big backlog up front
• No definition of “done”
• Coding done but testing incomplete
Who Tests What When?
Delivery
Requirements
Design
Implementation
Testing
Product Owner & Customer define requirements in terms of acceptance criteria(the “back of the card”)
Team accepts a story only once the acceptance criteria are detailed in specific scenarios (“if it does all this, it’s good”)
Team produces automated unit tests for
code functions…
…plus automated tests for UI / customer features
Customer & Product Owner see the new features and running tests
Customer tests the new release (“user acceptance testing”)
Iteration Planning
Demo
Retrospective
No mini-waterfalls
Delivery
Requirements
Design
Implementation
Testing
Team produces automated unit tests for
code functions…
…but the (automated) tests for the UI features aren’t done until later
Customer & Product Owner see the new features and running tests
Iteration Planning
Demo
Retrospective
Sprint Includes Testing
Delivery
Requirements
Design
Implementation
Testing
Product Owner & Customer define requirements in terms of acceptance criteria(the “back of the card”)
Team accepts a story only once the acceptance criteria are detailed in specific scenarios (“if it does all this, it’s good”)
Team produces automated unit tests for
code functions…
…plus automated tests for UI / customer features
Customer & Product Owner see the new features and running tests
Customer tests the new release (“user acceptance testing”)
Iteration Planning
Demo
Retrospective
Outrageous Agile
• Changing the vocabulary without changing the practices
• Treating “Agile” as a “Methodology”
• Trying to do everything with one format of user stories
• Treating the backlog as the whole set of requirements
• Committing to a story without agreeing to how you know it’s done
• Completing an increment without complete testing
No Bull Agile
“No Bull Agile”
We Favor
• Reason over Rigidity
• Content over Ceremonies
• Diagrams over Documents
• Tests over Tasks
“No Bull Agile”
We Favor
• Reason over Rigidity
• Content over Ceremonies
• Diagrams over Documents
• Tests over Tasks
Reason over Rigidity
Common Cultish Behaviors
• Only document with “user stories”
• Change the whole vocabulary
• Jump straight into iterations
• Focus only on code
• Pretend to know the customer best
• Revert to junior high school
In the Agile Methodology
there is only ONE TRUE WAY!
“No Bull Agile”
We Favor
• Reason over Rigidity
• Content over Ceremonies
• Diagrams over Documents
• Tests over Tasks
Ceremony Trap, a.k.a. “Cargo Cult Agile”
I have to define two-hour tasks
User story:“As a ___ I want to ___
in order to ___”
Story Point Planning Poker
But shouldn’t we first play the paper airplane
game?
“Content over Ceremonies”
“As an industry, we love syntax wars”—Gojko Adzic and David Evans. Fifty Quick Ideas to Improve Your User Stories.
“As a ___I want ___So that ___
There’s NO OTHER WAY!
As an employee I want to report a personal car expense by specifying
a date and miles driven.
Have the option to enter start and end odometer readings for
personal car expenses.
User Stories
Card• Keep it short
Conversation• Enough to get the team to
understand and agree to the need
Confirmation• Know when you are done
As an employee I want to report a personal car expense by specifying
a date and miles driven.
Have the option to enter start and end odometer readings for
personal car expenses.
Content over Ceremonies
• It’s not the form of the user story,it’s the content of the story.
• It’s not the form of the daily standup, it’s that real communication takes place.
• It’s not the form of the demo,it’s the information collected from the customer (product owner)
• It’s not the job title or role,it’s what each person contributes
“No Bull Agile”
We Favor
• Reason over Rigidity
• Content over Ceremonies
• Diagrams over Documents
• Tests over Tasks
Diagrams over Documents
No more use cases, models—nothing but little
user stories!
A picture’s worth a thousand words.
A good sketch is better than a long
speech.
Un bon croquisvaut mieux qu’un
long discours.
1-3
A picture’s worth a thousand words.
A good sketch is better than a long
speech.
1-3
A picture’s worth a thousand words.
1-3
User Stories are Deltas (not little use cases!)
Is this a• Completely new capability?• Change to existing capability?
Does this affect a• Multi-actor business process?• Single actor activity?• Single step (e.g. UI page)?
Have an “overall model”
System
Process
Activity
Step
Action
5-level architecture
Collection of processes that manage, control, or report on some aspect of a business.
The steps that one or more actors go through in order to achieve some business goal.
The work done by a single actor to carry out one step in a business process.
Individual units of work performed by a single actor (e.g. a UI screen)
The basic atomic units of UI behavior (e.g. “enter x into a field,”
“click the OK button”)
17-3
System
Process
Activity
Step
Action
Process
Process Model
Activity
Activity Model
System
System Overview
System
Diagrams over Documents
Process
Activity
“No Bull Agile”
We Favor
• Reason over Rigidity
• Content over Ceremonies
• Diagrams over Documents
• Tests over Tasks
Planning Includes Tests
• Select the stories to be done
• Define the tasks needed to complete them
• Agree upon the acceptance criteria for each story (and the iteration)
17-7
Tasks!Tasks!Tasks!
What’s my story?
As an employee I want to report my travel expenses in order to get reimbursed.
As an employee I want to enter a new expense report in order to start the reimbursement process. As an employee I want to
report a personal car expense by specifying a date and miles driven.
17-4
System
Process
Activity
Step
Action
Tests No Surprises
Report personal car expenses by specifying a
date and miles driven
Report personal car expenses by specifying start and end odometer
readings
Test-Based Burndown Chart
“No Bull Agile”
We Favor
• Reason over Rigidity
• Content over Ceremonies
• Diagrams over Documents
• Tests over Tasks
Parting Thoughts
• Tolerate Incompleteness
• Change Happens
• Do the Least to Deliver the Most
Thank you
Marc J. BalcerChief Architect
Model Compilers LLCmarc@modelcompilers.com
http://www.modelcompilers.com
Questions?
Marc J. BalcerFounder & Chief Architect
Model Compilers
email: marc@modelcompilers.com
top related