L4A - Lean for (being) Agile - Some thoughts and tips for a progressive path to higher maturity & capability levels

www.eng.it
Some thoughts and tips for a
progressive path to higher
maturity & capability levels
L4A – Lean for (being) Agile
Luigi Buglione, Ph.D.
Process Improvement & Measurement Specialist
Industry & Services Business Unit
Engineering Ing.Inf. SpA
ISMA11- IFPUG Int. Conference on Sw Measurement & Analysis
Sao Paulo (Brazil), November 18 2015

www.eng.it2 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 L.Buglione
L4A Presentation goals
 G1. Analyze the most common measurement-related
practices in the Lean/Agile communities  towards a ‘L4A’
viewpoint (not the same thing!)
 G2. Discuss most relevant potential issues from a
measurement viewpoint
 G3. Propose possible counter-measures to overcome such
flaws for strengthening measurement practices also in L4A
teams/projects

L4A Let’s Social...ize!
If you want to share
comments/notes/pics…
 @IFPUG
 @engineeringspa
 @lbumeasure
 @Gufpi_Isma
 #Lean
 #Agile
 #L4A
 #AgileMeasurement
 #FSM
…

Agenda
• Introduction
– Lean/Agile – what does it mean? Friends or Foes?
– Lean Six Sigma + Agile Manifesto – Values and Principles
– Lean/Agile Measurement – Main Issues
• Best Practices
1. Requirements - Elicitation
2. Requirements - Management
3. Measurement – Sizing Units
4. Estimation
5. Monitoring & Control
6. Estimation – Project Historical Data
7. Project Management – Standard definitions
8. Agile Measurement Plan
9. Agile RCA-based improvements
10. Lean Measurement – Automation (Data Collection)
• Conclusions & Prospects
• Lessons learned
• Q & A
L4A

Introduction L4A – Lean for (being) Agile
Not Lean Lean Agile

Introduction Lean/Agile – Definition
Q:…but what about Measurement/Estimation practices in Lean/Agile?

Introduction Agile is Lean? Which relationship?

Introduction Lean & Agile – Comparing Approaches

Introduction Lean – The Seven (7) Mudas

Introduction Lean – The Eight (8) Mudas

Introduction Lean & Measurement – Six Sigma DMAIC

Introduction Agile Manifesto (2001) – The new values
Source: www.agilemanifesto.org
“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”

Introduction Agile Manifesto (2001) – 12 principles
Source: www.agilemanifesto.org
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the
customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference
to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and
trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be
able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10.Simplicity--the art of maximizing the amount of work not done--is essential.
11.The best architectures, requirements, and designs emerge from self-organizing teams.
12.At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.

Introduction Lean/Agile Measurement - Main issues
An initial list of issues from which moving for improving lean/agile measurement
practices:
1. Measurement is not an evaluation/assessment
2. Managing a project in an agile way does not mean to do not measure at all, but you cannot
measure anything  from data collection (lean) to Story Points (agile), let’s find a balance!
3. The attention paid to historical data risks to be less than needed for properly re-estimating an
artifact when the team composition will change over time
4. Story Points (SP)
 Are not a ‘size unit’ but an elaboration of effort needed to develop an artifact
 Are relative and specific to a team, not necessarily to several ones
 Have not a common, shared definition (repeatibility issue)
5. Bad perception from Agile teams/projects on ‘typical’ measurement practices and techniques
6. Some Agile Measurement best practices
 improving the current ones
 Moving from the Agile Manifesto principles and values
• …

L4A: Best Practices

Best Practices 1) Lean Measurement – Automation #1
Some notes for starting:
• Often misunderstandings about which tools to adopt to make faster the measurement
process, not asking if they’re the right tools for obtaining the right result(s) at the right price
• Look at the final informative goal and its accuracy (e.g. what is a LOC?)
• Open Source Software (OSS) can be a good source of solutions for starting to automate and
allow an easier data collection for a Lean Measurement
• Need to choose the right tool without adapting it too much before adopting it, otherwise
better to choose another one
...ToFrom...

Best Practices 1) Lean Measurement – Automation #2
• Another risk separating Lean from Agile could be about the amount of data needed to
become Lean (before) and Agile (later)
• How many data should we need to understanding where are our ‘mudas’?
• Which non-intrusive ways to adopt for obtaining such result(s)?
From... ...To

Best Practices 2) Requirements – Elicitation
• User Stories (US) are not Use Cases, related but not the same thing
• US do not take much information from UML documentation (e.g. sequence diagrams)
• US typically contain the ‘functional’ side of the story but often miss the non-functional ones
and those related project-level activities/constraints to be mentioned for do not reducing the
real scope in terms of effort/cost,
• Move to US2, with MoSCoW priority criteria and fsu/nfsu for sizing FURs/NFRs
From... ...To

3) Requirements – Management
• Using the INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) criteria by
Mike Cohn a US should be evaluated both by customer and provider, but the ‘negotiation’ still
risk to be mostly on the qualitative/subjective side
• Move to the INVEST Grid and INVEST Process
From... ...To
Best Practices

4) Measurement – Sizing Units
• US typically use Story Points (SP) that’s a manner to determine in a subjective way a
magnitude scale between the less (or more) complex requirement against the other ones
(e.g. 2x, 3x, …)
• US are currently not sized, as meant from a measurement viewpoint
• If a US would contain both the expression of FURs+NFRs, at least two sizing units should be
expressed in the card, not only one  US2!
From... ...To
Best Practices

5) Estimation
• The Planning Game (and/or Planning Poker) are the typical way the Team discusses and
evaluates. Story Points and not sizing unit(s) are used, missing the determination of
quantities of work to be done, using historical data about specific productivities
• Assumed that CMMI (or other Maturity Models) are heavy-weight and not light-weight ones
From... ...To
Best Practices

6) Monitoring & Control
• The Burndown chart logic is typically used ‘burning’ Story Points…
• …but it could be applied also to other (sizing) units, also FP and SNAP Points (SP) for
better tracking different entities (product, not project) and attributes (e.g. functional size, not
effort)
From... ...To
Best Practices

Best Practices 7) Estimation – Project Historical Data
• The Planning Game is a process for estimating Stories and Epics, determining on a local
base an estimation
• But what about the recording of data into a Knowledge Base (e.g. MEB – Measurement
Experience Base in ISO 15939)? Several frameworks/best practices as ITIL, CMMI and ISO
x-management systems ask for it
From... ...To

Best Practices 8) Project Mgmt – Standards adoption
• Story Points (SP) are a good example of ‘local definition’ for a team and not for the whole
organization, as well as a priority scale for implementing that SP by the related assigned
tasks…What is the ‘standard’ definition of a SP? Is it repeatable and consistent?
• A standard definition for a sizing unit, for instance, would lead more teams to exchange
their own project historical data and thus sharing a larger knowledge base across the
organization (higher value for mid-large organizations)
• Another buzzword is “velocity”…
From... ...To
Some possible definitions:
• Source #1
• Source #2
• Source #3
• Source #4
• Source #5
• …

Best Practices 9) Agile Measurement Plan
• Since SP represent the way to estimate the needed effort and each Sprint is time-boxed,
very few other measures are typically gathered in an agile project, often not collected under
an organic measurement plan
• What about a project measurement plan defining – as usual – the “5Ws+H” elements to
which add a second “H(ow much)” for upper/lower thresholds moving from historical data?
• What about to introduce GQM as a goal-oriented technique and EAM (Entity-Attribute-
Measure) analysis for not missing/overlapping measures in a balanced plan?
From... ...To
[US typical (old) structure]:
• As a [Role]
• I want [...]
• in order to [...]
• Acceptance Criteria: [...]
• Story Points: [...]
[US typical (new) structure]:
• As a [Role]
• I want [...]
• in order to [...]
• Measure by […]  EAM
• Acceptance Criteria: [...]
• Thresholds (UCL/LCL)
• Story Points: [...]

Best Practices 10) Agile RCA-based improvement
• Retrospectives are in Scrum the typical final Sprint meeting with a continuous improvement
purpose run out from the Team and participated also by the Scrum Master and the Product
Owner
• What about running an agile Root-Cause Analysis (RCA) using mind maps and adding details
about measures and historical data?  Q-RCA!
From... ...To
• Mind Maps software: http://goo.gl/ltxfao

Best Practices Goal: Reinforcing Maturity & Capability

Best Practices Goal: Reinforcing Maturity & Capability
Special cause
(GP.2.2 @ OT)
Common cause (GP.2.9 @
+PA)
• Source: http://goo.gl/i6IvI

Some Conclusions...

L4A Some conclusions...
• Lean vs Agile: not the same thing...
 Misconception – complementary approaches
 Need to be Lean (before) in order to become Agile (after) – common stream is ‘measure well’
 Mixing techiques and approaches can return a better results, keeping the best from the two
• Lean/Agile vs Measurement: a false perception
 Lean is strongly based on Measurement  LSS (Lean Six Sigma)
 Not true that an agile project doesn’t measure and it’s only based on the time-box principle
 Measurement and measures can be apply with care, applying the lean/agile values-principles
• How many measures to apply?
 2-3 measures per informative goals could be a good target, as ITIL v3 CSI suggests
 Improve a typical Hypothesis/User Story (US) also specifying sizing units (e.g. FP/SP) and MoSCoW
prioritization criteria, together with a refinement of INVEST criteria using the INVEST Grid+Process
 Lean/Agile Measurement and Tools
 Data from log files could be a good way to gather data in automatic manner
 Apply the Burndown chart but also applying the concept to the sizing units used in a Sprint
 Lean/Agile Projects and Measurement Plans
 Measurement plans can be derived using few measures, possibly connected each other
 Base measures can be joined into derived measures (metrics) obtaining more informative value at
the same gathering costs and included as ‘new’ different measures into the plan
An optimist will tell you the glass is half-full;
the pessimist, half-empty; and the engineer will tell you the
glass is twice the size it needs to be
(Unknown)

Lessons Learned...
URL: www.dilbert.com
L4A
URL: www.bitstrips.com

Q & AL4A
Thanks for your attention!
Obrigado pela sua atenção!

Contact DataL4A
Luigi
Buglione
Engineering Ing. Inf. SpA
luigi.buglione@eng.it

L4A - Lean for (being) Agile - Some thoughts and tips for a progressive path to higher maturity & capability levels

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (8)

En vedette

En vedette (8)

Similaire à L4A - Lean for (being) Agile - Some thoughts and tips for a progressive path to higher maturity & capability levels

Similaire à L4A - Lean for (being) Agile - Some thoughts and tips for a progressive path to higher maturity & capability levels (20)

Plus de Luigi Buglione

Plus de Luigi Buglione (20)

Dernier

Dernier (20)

L4A - Lean for (being) Agile - Some thoughts and tips for a progressive path to higher maturity & capability levels