The game has changed!
•Als PPTX, PDF herunterladen•
0 gefällt mir•455 views
1. The document discusses how the game has changed for agile and lean adoption and implementation. It highlights how the nature of applications, planning approaches, requirements gathering, testing paradigms, and metrics have fundamentally changed from past practices. 2. Key shifts mentioned include moving from detailed upfront estimation and planning to relative planning approaches like planning poker, embracing feedback and changing requirements over fixed requirements documents, shifting testing to be everyone's responsibility through practices like TDD and continuous integration. 3. The overall message is that merely doing agile ceremonies or practices does not equal true agile adoption - the underlying mindsets, tools, and metrics used must fundamentally change to match the new paradigms.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie The game has changed!
Ähnlich wie The game has changed! (20)
Mehr von Sudipta Lahiri
Mehr von Sudipta Lahiri (18)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
The game has changed!
- 1. @sudiptal
- 2. @sudiptal The Game has changed!
- 3. @sudiptal Sudipta Lahiri (Sudi) slahiri@digite.com, lahiri.sudipta@gmail.com • Senior Vice President, Digité • Agile/Lean practitioner (75%) • Lean Transformation of our own team • Developed SwiftKanban (www.swiftkanban.com), SwiftALM (www.digite.com) • Licensed user base of over 500,000 • Agile Coach (25%) • Train and coach teams/organizations in Lean/Agile • Run the LimitedWIP Societies in India My Background 3
- 4. @sudiptal Why this talk? Lean/Agile Adoption has been weak! Mostly, at Team level A few at Program level Almost none at Organization level
- 5. @sudiptal
- 6. @sudiptal Just reflect on what we preach today... “Projects” is a bad term! No(almost) Estimation No(almost) Planning No Schedules with associated Budgets No Managers but “servant-leaders” Don’t allocate work... let people pull their work! Multi-tasking is a bad thing! 100% utilization is a bad thing! Testers and Developers will collaborate We will deliver more, faster with lesser planning, That’s exactly opposite to what we did all this time!
- 8. @sudiptal ... in every aspect... ... and its our job to educate why and how! The game has changed...
- 9. @sudiptal 1. The nature of applications
- 10. @sudiptal Then!
- 11. @sudiptal Now!
- 12. @sudiptal Recognize that the fundamental nature of applications have changed UI and application interaction has become paramount! That’s a discovery process
- 13. @sudiptal 2. Planning: The way we plan and track has changed!
- 14. @sudiptal Estimation: Then... Extremely time consuming (months) Needed a fair amount of detail Filled with assumptions... http://chronologist.com/images/function-points-are-fantasy-points/function-point-estimation-worksheet
- 15. @sudiptal Estimation: Now... (Ultra) Fast Relative Gut feel first estimate is generally right! https://styleshare.github.io/images/2015-11-05-estimator/planningpoker.jpg
- 16. @sudiptal Scheduling/Forecasting: Then... http://www.techrepublic.com/blog/tech-decision-maker/managing-deadlines-in-microsoft-project-2007/ Assumptions at all levels • Team Member Productivity • Work Item Estimates • Resource Skillsets • Dependencies • Project/Resource Calendar Yet, we give a deterministic end date!
- 17. @sudiptal Scheduling/Forecasting: Then… Critical path planning Fast tracking or Crashing Take a day for medium size projects; several days for large size projects Specifically, if your resources are not always under your direct control
- 18. @sudiptal Short reminder What do we want to accomplish in this release and how much is left ? Why is this important and to whom ? Scheduling: Now...
- 19. @sudiptal Scheduling/Forecasting: Now… A Kanban system Henrik Kniberg Delivered features Date When will all of this be done? Around week 27-30
- 20. @sudiptal Scheduling/Forecasting: Now… A Scrum system Worst (28SP*6=168) Average (33SP*6=198) Release Backlog for 6 Sprints Last Release FP Velocity Reference: AgileSparks
- 21. @sudiptal In short, the entire planning and monitoring approach has changed Estimation, Scheduling, Forecasting How do you communicate Lean/Agile without bridging this gap?
- 22. @sudiptal 2. Requirements – The game has changed!
- 23. @sudiptal These BRDs used to work (mostly)... then! Our BRDs... then!
- 24. @sudiptal But... written specs are often misunderstood..
- 25. @sudiptal
- 26. @sudiptal
- 27. @sudiptal We accept that requirements are effective only when given by a conversation... ... between the Developer and the Consumer... ... supported by a common understanding of what is “acceptable”
- 28. @sudiptal Written requirements have failed as the artefact for Requirement definition Use written requirements as a starting point and define acceptance criteria The importance of collaboration (not hand-off) between the 2 parties is established! CR/Scope Change isn’t paramount
- 29. @sudiptal 2. Completeness of BRDs
- 30. @sudiptal Then: Acceptance/payment linked to it We had to complete every line of the signed off the BRD!
- 31. @sudiptal Henrik Kniberg Now: We know that we build the wrong thing, often Sources: Standish group study reported at XP2002 by Jim Johnson, Chairman Always 7% Often 13% Some- times 16% Rarely 19% Never 45% Features and functions used in a typical system Half of the stuff we build is never used! Cost # of features This graph courtesy of Mary Poppendieck
- 33. @sudiptal Recognizing “premise” of conversation... We demo early We break Requirements as per INVEST We Automate We Deliver Continuously to get Early Feedback Feedback for change is welcome… It means you are paying attention to what I am building… and I am building something closer to your need!
- 34. @sudiptal A very different thought process... We don’t commit to scope... we commit to effort and timeline and keep delivering what makes most sense, demoing and taking feedback, regularly!
- 35. @sudiptal True agility isn’t without: Small, independent requirements Automation CI and CD Caution: You will not get “agility” by doing requirement decomposition the traditional way, with dependencies
- 36. @sudiptal 2. CUT: the game has changed!
- 37. @sudiptal How can a Developer be trusted to test his own code? Metrics like Defect Density were used as for appraisal It encouraged Testers to file more defects, often bogus
- 38. @sudiptal Then... Test Coverage was an enigma! Automation was considered expensive… … because we viewed as a Project
- 39. @sudiptal Now... If done right, (near) 100% Test Coverage is accomplished Automation, done with development, isn’t another “overhead” cost; saves cost significantly
- 40. @sudiptal The scope, role and responsibility of “Dev” has changed TDD is the “new” norm Sell the “guarantee” of test coverage
- 41. @sudiptal 3. Testing: A completely different paradigm
- 44. @sudiptal Then… Dev Test Code Drop The long gap increased risk and wastage
- 46. @sudiptal Now… Buggy software is harder to test, harder to modify and slows overall productivity Keep the code clean; fix bugs fast Can’t go home if the build is broke!
- 48. @sudiptal Now… Tested is part of “DONE” .... It cannot be “Done” if it isn’t Implemented and Tested Without Testing, you don’t know if the expectations are met Classic implementation in Agile EVM
- 49. @sudiptal Testing “psyche” has changed completely! The role is not to test; the role is to deliver a quality service The “testing” role is more driven by the Dev team (refer the Testing Pyramid) Therefore, the traditional metrics
- 50. @sudiptal
- 51. @sudiptal The game has “indeed” changed! From the nature of applications… … to the way projects are planned, tracked and monitored… … to the way SDLC is executed… … to the way tools have evolved to deliver CI and CD… … to the way teams have to be structured and appraised (which we did not cover today)!
- 52. @sudiptal Communicate the “full” picture Just doing the Ceremonies or putting a Kanban Board is neither Agile nor Lean The game has “indeed” changed!
- 53. @sudiptal Thank you for your time today... For any questions or clarifications, reach me at: @sudiptal slahiri@digite.com lahiri.sudipta@gmail.co m http://sudi- thoughts.blogspot.in/ Join Limited WIP Societies @ NCR, Bangalore, Pune, Join us at Lean Kanban India 2016! Bangalore, Sep 9-10
Hinweis der Redaktion
- How many CEOs would get their job if this is what they told their respective Boards?
- Keep the Code Clean This principle is an example of the discipline that Agile teams have. It takes tremendous internal discipline to fix bugs as they are found. If it’s a genuine bug, as opposed to a new story, it is fixed within the iteration. To do otherwise is like cooking in a filthy kitchen: it takes longer to wade through the mess to do the cooking, and the resulting food may or may not be edible.
- “Done Done,” Not Just Done In traditional environments that have a strict division between development and test, it is typical for the developers to say they are “done” with a feature when they have implemented it, but before it is tested. Of course the feature isn’t “done” until it’s been tested and any bugs have been fixed. That’s why there’s a long standing joke in the industry that a given software release is usually “90% done” for 90% of the project. (Or, in other words, the last 10% of the effort takes 90% of the time.) Agile teams don’t count something as “done,” and ready to be accepted by the Product Owner or Customer until it has been implemented and tested.