agile lean conference 2016 - buglione_lean for (being) agile
TRANSCRIPT
L4A – Lean for (being) Agile Some thoughts and tips for a progressive path to higher maturity &
capability levels
Luigi Buglione – [email protected] - Engineering
www.eng.it 2 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 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
www.eng.it 3 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
L4A Let’s Social...ize!
If you want to share comments/notes/pics…
@agileleanconf
@Gufpi_Isma
@itSmfItalia
@engineeringspa
@lbumeasure
#Lean
#Agile
#L4A
#AgileMeasurement
#FSM
…
www.eng.it 4 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
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
www.eng.it 6 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Introduction L4A – Lean for (being) Agile
Not Lean
Lean
Agile
www.eng.it 7 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Introduction Lean/Agile – Definition
Q:…but what about Measurement/Estimation practices in Lean/Agile?
www.eng.it 8 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Introduction Agile is Lean? Which relationship?
www.eng.it 9 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Introduction Lean & Agile – Comparing Approaches
www.eng.it 10 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Introduction Lean & Agile – Comparing Approaches
www.eng.it 11 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Introduction Lean – The Seven (7) Mudas
www.eng.it 12 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Introduction Lean – The Eight (8) Mudas
www.eng.it 13 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Introduction Lean & Measurement – Six Sigma DMAIC
www.eng.it 14 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
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”
www.eng.it 15 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
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.
www.eng.it 16 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
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
• …
www.eng.it 17 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
L4A: Best Practices
www.eng.it 18 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
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
...To From...
www.eng.it 19 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Best Practices 1) Lean Measurement – Automation #2
Some notes for starting: • 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
www.eng.it 20 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Best Practices 2) Requirements – Elicitation
Some notes for starting: • 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
www.eng.it 21 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
3) Requirements – Management
Some notes for starting: • 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
www.eng.it 22 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
4) Measurement – Sizing Units
Some notes for starting: • 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
www.eng.it 23 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
5) Estimation
Some notes for starting: • 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
www.eng.it 24 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
6) Monitoring & Control
Some notes for starting: • 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
www.eng.it 25 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Best Practices 7) Estimation – Project Historical Data
Some notes for starting: • 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
www.eng.it 26 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Best Practices 8) Project Mgmt – Standards adoption
Some notes for starting: • 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 • …
www.eng.it 27 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Best Practices 9) Agile Measurement Plan
Some notes for starting: • 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: [...]
www.eng.it 28 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Best Practices 10) Agile RCA-based improvement
Some notes for starting: • 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
www.eng.it 29 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Best Practices Goal: Reinforcing Maturity & Capability
www.eng.it 30 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Best Practices Goal: Reinforcing Maturity & Capability
Special cause
(GP.2.2 @ OT)
Common cause (GP.2.9 @
+PA) • Source: http://goo.gl/i6IvI
www.eng.it 31 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Some Conclusions...
www.eng.it 32 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
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)
www.eng.it 33 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Lessons Learned...
URL: www.dilbert.com
L4A
URL: www.bitstrips.com
www.eng.it 34 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Q & A L4A
Thanks for your attention! Grazie per l’attenzione!
www.eng.it 35 ALCI 2016 (Rome – Italy) – 11/02/2016 © 2016 L.Buglione
Contact Data L4A
Luigi Buglione
Engineering Ing. Inf. SpA [email protected]