Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

680 views

Published on

‘Agile’ risks to be a very (ab)used term in the ICT (and not) community during last years. Agile means – as in the Agile Manifesto – to be responsive, working in team and be ready to change. But what do we need for really being agile? The answer is simple: start to be (before) LEAN in order to be (after) AGILE. Too often these two terms risk to be meant as synonyms, but they are different and complementary to each other. The presentation will show a possible path to do that, adopting Lean techniques as suggested by Six Sigma for reducing wastes (the seven ‘muda’) and only then adopting Agile ones, also applied to Functional (and not) Sizing Methods, such as Function Points and SNAP. Note from the conference organizers: “Muda” is a Japanese word meaning “waste”. The Toyota Production System identified seven types of “muda”.

Published in: Software
  • Be the first to comment

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

  1. 1. 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
  2. 2. 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
  3. 3. www.eng.it3 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 L.Buglione L4A Let’s Social...ize! If you want to share comments/notes/pics…  @IFPUG  @engineeringspa  @lbumeasure  @Gufpi_Isma  #Lean  #Agile  #L4A  #AgileMeasurement  #FSM …
  4. 4. www.eng.it4 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 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
  5. 5. www.eng.it5 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 L.Buglione
  6. 6. www.eng.it6 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 L.Buglione Introduction L4A – Lean for (being) Agile Not Lean Lean Agile
  7. 7. www.eng.it7 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 L.Buglione Introduction Lean/Agile – Definition Q:…but what about Measurement/Estimation practices in Lean/Agile?
  8. 8. www.eng.it8 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 L.Buglione Introduction Agile is Lean? Which relationship?
  9. 9. www.eng.it9 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 L.Buglione Introduction Lean & Agile – Comparing Approaches
  10. 10. www.eng.it10 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 L.Buglione Introduction Lean & Agile – Comparing Approaches
  11. 11. www.eng.it11 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 L.Buglione Introduction Lean – The Seven (7) Mudas
  12. 12. www.eng.it12 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 L.Buglione Introduction Lean – The Eight (8) Mudas
  13. 13. www.eng.it13 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 L.Buglione Introduction Lean & Measurement – Six Sigma DMAIC
  14. 14. www.eng.it14 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 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”
  15. 15. www.eng.it15 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 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.
  16. 16. www.eng.it16 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 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 • …
  17. 17. www.eng.it17 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 L.Buglione L4A: Best Practices
  18. 18. www.eng.it18 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 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 ...ToFrom...
  19. 19. www.eng.it19 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 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
  20. 20. www.eng.it20 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 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
  21. 21. www.eng.it21 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 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
  22. 22. www.eng.it22 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 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
  23. 23. www.eng.it23 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 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
  24. 24. www.eng.it24 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 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
  25. 25. www.eng.it25 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 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
  26. 26. www.eng.it26 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 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 • …
  27. 27. www.eng.it27 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 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: [...]
  28. 28. www.eng.it28 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 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
  29. 29. www.eng.it29 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 L.Buglione Best Practices Goal: Reinforcing Maturity & Capability
  30. 30. www.eng.it30 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 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
  31. 31. www.eng.it31 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 L.Buglione Some Conclusions...
  32. 32. www.eng.it32 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 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)
  33. 33. www.eng.it33 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 L.Buglione Lessons Learned... URL: www.dilbert.com L4A URL: www.bitstrips.com
  34. 34. www.eng.it34 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 L.Buglione Q & AL4A Thanks for your attention! Obrigado pela sua atenção!
  35. 35. www.eng.it35 IFPUG ISMA11 (Sao Paulo – Brazil) – 18/11/2015 © 2015 L.Buglione Contact DataL4A Luigi Buglione Engineering Ing. Inf. SpA luigi.buglione@eng.it

×