agility accelerates ...
Doppelter Output in der halben Zeit Wo bleibt die Qualität?
SAQ Jahresversammlung 8. April 2014
hEp://www.management30.com
Mischa Ramseyer Agile Executive Coach
@ramsyman
What is Quality?
? 10.04.14 SAQ Jahresversammlung 3
ISO 9000 Definiton of Quality
“Quality is the degree to which a set of inherent characteristics fulfills
requirements.“
The standard defines requirement as need or expectation.
10.04.14 SAQ Jahresversammlung 4
Philip B. Crosby‘s DefiniRon of Quality
"Conformance to requirements“
The requirements may not fully represent customer expectations;
Crosby treats this as a separate problem.
10.04.14 SAQ Jahresversammlung 5
Joseph Juran‘s DefiniRon of Quality
"Fitness for use“
Fitness is defined by the customer
10.04.14 SAQ Jahresversammlung 6
Peter Drucker defines Quality as
"Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay
for.“
10.04.14 SAQ Jahresversammlung 7
American Society for Quality say‘s
A subjective term for which each person has his or her own definition. In technical usage, quality can have two meanings:
a. The characteristics of a product or service that bear on its ability to satisfy stated or implied needs;
b. A product or service free of deficiencies.“
10.04.14 SAQ Jahresversammlung 8
W. Edwards Deming says
Concentrating on "the efficient production of the quality that the market expects,“
and he linked quality and management:
"Costs go down and productivity goes up as improvement of quality is accomplished
by better management of design, engineering, testing and
by improvement of processes.“
10.04.14 SAQ Jahresversammlung 9
DefiniRons of Quality
Quality Fulfill the requirements
Fitness for use
Build what the customer is willing to pay for
No Bugs
goes up by empirically improve processes
10.04.14 SAQ Jahresversammlung 10
Idea
What is Quality about?
10.04.14 SAQ Jahresversammlung 11
Idea
Idea Idea Product
Development
Do the Right Thing! Do the Thing Right!
EffecRveness Efficiency
What is more important?
? 10.04.14 SAQ Jahresversammlung 12
agility accelerates ...
DO THE RIGHT THING
10.04.14 SAQ Jahresversammlung 13
The „Cost of Complexity“ is huge!
10.04.14 SAQ Jahresversammlung 14
It‘s all about secng prioriRes!
10.04.14 SAQ Jahresversammlung 15
Do the Right Thing!
10.04.14 SAQ Jahresversammlung 16
• Deliver Business Value • in the right order • as early as possible • conRnuously
• Reduce risk • Collect Customer
Feedback as early as possible
• Embrace Change • Release when good
enough
© pragmatic solutions gmbh 2009 - 2014
Good enough is enough to Release!
10.04.14 SAQ Jahresversammlung 17
Business Value
Time
Feature
Good Enough
Release 1.0
Faster Time to Market and Lower Cost
means earlier ROI
80% Business Value
20% Time
Release 1.x
Built-‐in Change Management
10.04.14 SAQ Jahresversammlung 18
Business Value
Time
New Feature identified during development
Good Enough
Release 1.0
Release 1.x
exchange
Idea
3 Rmes as EffecRve
10.04.14 SAQ Jahresversammlung 19
Idea
Idea Idea Product
Development
Do the Right Thing! Do the Thing Right!
EffecRveness Efficiency 3x
agility accelerates ...
DO THE THING RIGHT
10.04.14 SAQ Jahresversammlung 20
Do the Thing Right!
Where Defects Originate What it costs to fix them
The Economics of Testing
The Relative Cost of Fixing Defects One of the most well known facts about software defects is that the longer they go undetected, the more expensive they are to fix. Although research differs on the exact ratios, the general rule is 1:10:100. That is, if a defect costs one unit (hour, dollar, etc.) to fix in requirements and design, it costs 10 units to fix in testing (system/acceptance) and over 100 times to fix in production. Sometimes the cost to fix a defect in production costs much more than 100 times the cost of fixing it in the requirements phase. This cost of defects doesnFt even take into account the impact cost of defects. These costs could be attributed to lost revenue, reimbursements, fraud, lost customers, bad public relations, and litigation. In the case of safety critical systems, how can one put a cost value on a human life?
The Relative Cost of FixingDefects
0102030405060708090100
Req's Design Code Test Prod
The Relative Cost of FixingDefects
0102030405060708090100
Req's Design Code Test Prod
STBC - 3
10.04.14 SAQ Jahresversammlung 21
The Economics of Testing
The Economics of Testing There is a definite economic impact of software testing. One economic impact is from the cost of defects. This is a very real and very tangible cost. Another economic impact is from the way we perform testing. It is possible to have very good motivations and testing goals while testing in a very inefficient way. In this section, we will examine the economic impact of defects and ways to economize testing.
Where Defects Originate To understand the dynamics and costs of defects, we need to know some things about them. One of the most commonly understood facts about defects is that most defects originate in the requirements definition phase of a project. The next runner-up is the design phase. Some problems in getting accurate, clear, and testable requirements are: � Many people do not have a solid requirements gathering process � Few people have been trained in or understand the dynamics of requirements � Projects, people, and the world around us change very quickly � The English language is ambiguous and even what we consider clear language can be
interpreted differently by different people. The figures in this pie chart were taken from a James Martin study and the numbers track very closely to measurements of typical software projects.
Where Defects OriginateCode7%
Other10%
Req's56%
Design27%
Where Defects OriginateCode7%
Other10%
Req's56%
Design27%
This
doc
um
ent
may
not
be
repr
odu
ced.
STBC - 1
James MarRn Study
1:10:100
How would you handle the problem?
? 10.04.14 SAQ Jahresversammlung 22
From SpecificaRon to Discussion
10.04.14 SAQ Jahresversammlung 23
As an
employee I want
to log my working /me so that
I always keep track of my daily working /me
User Story Template
Speak the same language
• An „Ubiquitous Language“ is needed to bridge the communicaRon gap
• Use Domain Modeling to describe the Business Domain
10.04.14 SAQ Jahresversammlung 24
Timetracking Domain Model
Introducing Acceptance Criterias Priority As a [role] I can [goal] so that [reason] EsAmaAon
10 Employee log my working Rme I always keep track of my daily working Rme
2
10.04.14 SAQ Jahresversammlung 25
Narrow down the scope of the Story using Acceptance Criterias • At least a „How-‐to-‐demo-‐Workflow“ • Add them to the Product Backlog
Example 1. Fill in starRng-‐, lunch & end Rme in natural hours & minutes 2. Decimal working hours will be displayed & saved 3. Displayed working hours must be present in the DB
Introducing SpecificaRon by Example
10.04.14 SAQ Jahresversammlung 26
Business Rules • Given work Rme is > 9h
Then break = 1 hour • Given work Rme is > 7h
Then break = 30 min • Given work Rme is > 5.5h
Then break = 15 min
Morn In
Lunch out
Lunch In
Eve Out
Time
9:00 12:00 13:00 17:05 7.08
8:00 12:00 13:00 17:00 8.00
8:00 -‐ -‐ 17:01 8.02
7:30 12:00 13:00 17:00 8.50
... ... ... ... ...
Priority As a [role] I can [goal] so that [reason] EsAmaAon
10 Employee log my working Rme I always keep track of my daily working Rme
2
Build Executable DocumentaRon
10.04.14 SAQ Jahresversammlung 27
Scenario: Log Rme Given my Rme of <arrival> And the Rme I go for <lunch-‐out> And the Rme I return from <lunch-‐in> And the Rme I leave in the <evening> When I entered my Rme Then the <total> decimal Rme is calculated Examples: | arrival | lunch-out | lunch-in | evening | total!| 09:00 | 12:00 | 13:00 | 17:05 | 7.08!| 08:00 | 12:00 | 13:00 | 18:00 | 9.00!| 08:00 | - | - | 17:01 | 8.02!| 07:30 | 12:00 | 13:00 | 17:00 | 8.50!!!
In terms of the ubiquituous language
Address Inner-‐ & Outer Quality
10.04.14 SAQ Jahresversammlung 28
Inner Quality is inside the system
TDD improves inner quality
10.04.14 SAQ Jahresversammlung 29
RED GREEN
REFACTOR
Write a failing test Make it compile Make it work in production code
Make it nice eliminate duplication increase expressiveness
No production code without a
test
TDD is NOT an opRon
10.04.14 SAQ Jahresversammlung 30
Built in Regression BeEer Design
Fewer Bugs Faster Development
RED GREEN
REFACTOR
What is Pair Programming?
10.04.14 SAQ Jahresversammlung 31
Driver Navigator
Pair Programming
10.04.14 SAQ Jahresversammlung 32
Faster, but more Effort
BeEer Code & Design
Half of Bugs Knowledge spread
Double pack!
10.04.14 SAQ Jahresversammlung 33
RED GREEN
REFACTOR
Build Quality In
10.04.14 SAQ Jahresversammlung 34
Test Refactor
Code
Test Refactor
Code
Test Refactor
Code
Select a User Story
Identify Acceptance Criterias
Implement Acceptance test(s)
Failing Acceptance
Test
Passing Acceptance
Test
Refactor Acceptance
Test
Customer Acceptance
Behaviour Driven Development
Test Driven Development
Check against Requirements
FuncAonal Check if the System works as required • Unit Test • IntegraRon Test • Regression Test • User Acceptance Test
NON-‐FuncAonal Check if the System operates as intended • Technical TesRng
• Build • Deployment
• Load, Stress & Performance • Security & PenetraRon • Usability
10.04.14 SAQ Jahresversammlung 35
Checking vs. TesRng
Checking • Automated • Expected Result • Developer-‐Mindset • Developer Know-‐how • Basis for TesRng
10.04.14 SAQ Jahresversammlung 36
TesAng • Manual • Exploratory • User-‐Mindset • Business Know-‐how • On Top of Checks
Test AutomaRon is NOT an opRon!
10.04.14 SAQ Jahresversammlung 37
• Business Scenarios UI
• Business FuncRonality Services
• Inner Quality Unit
Checks & Tests
10.04.14 SAQ Jahresversammlung
Unit Tests
Single Unit Mock Objects Coded TDD Refactoring
IntegraRon Test
Check Test Environment MulRple Units Prepared „Real“ Data Coded & Configured Expected Output
Regression Test
Replay Unit-‐ / IntegraRon-‐Tests Don‘t break something else
System Tests
Manual Exploratory User Mindset Acceptance
NON-‐funcRonal
Usability Performance Security
38
ConRnuous IntegraRon is NOT an opRon
10.04.14 SAQ Jahresversammlung 39
Build
Test Deploy
Publish reports
Idea
3 Rmes as Efficient
10.04.14 SAQ Jahresversammlung 40
Idea
Idea Idea Product
Development
Do the Right Thing! Do the Thing Right!
EffecRveness Efficiency 3x
agility accelerates ...
CONCLUSION
10.04.14 SAQ Jahresversammlung 41
Idea
Build Quality In: Boost ProducRvity
10.04.14 SAQ Jahresversammlung 42
Idea
Idea Idea Product
Development
Do the Right Thing! Do the Thing Right!
EffecRveness Efficiency 3 x 3 = 9
Do the Right Thing
Do the Thing Right
EffecRveness
Efficiency
Delivery Products Services
© 2012 -‐ 2014 pragmaRc soluRons gmbh
The AdpaRve PragmaRc OrganisaRon
Network & Empowerment
Do the Right Thing
Do the Thing Right
OrganisaRon
EffecRveness
Efficiency
Culture
Context & Constraints
Delivery Products Services
© 2012 -‐ 2014 pragmaRc soluRons gmbh
The AdpaRve PragmaRc OrganisaRon
Network & Empowerment
Do the Right Thing
Do the Thing Right
Strategy
OrganisaRon
EffecRveness
Efficiency
Culture
Context & Constraints
Delivery Products Services
© 2012 -‐ 2014 pragmaRc soluRons gmbh
The AdpaRve PragmaRc OrganisaRon
ConRnuous Improvement & InnovaRon
Mehr zu den Herausforderungen im Management des 21. Jahrhunderts
10.04.14 SAQ Jahresversammlung 46
25./26. April 2014
hEp://zuerich.pm
-‐camp.org
10.04.14 SAQ Jahresversammlung 47
slideshare.net/pragmaticsolutions
info@pragmatic-‐solutions.ch
@ramsyman and/or @pragsol
facebook.com/PragmaticSolutionsGmbh
plus.google.com/b/100642162720912501942
www.pragmaRc-‐soluRons.ch
10.04.14 SAQ Jahresversammlung 48