Embed Size (px)
Citation preview
@sudiptal
@sudiptal
The Game has changed!
3
@sudiptal
Sudipta Lahiri (Sudi)[email protected], [email protected]
• 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
@sudiptal
Why this talk?Lean/Agile Adoption has been weak! Mostly, at Team level A few at Program level Almost none at Organization level
@sudiptal
@sudiptal
Just reflect on what we preach today...
“Projects” is a bad term!No(almost) EstimationNo(almost) Planning
No Schedules with associated BudgetsNo 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 collaborateWe will deliver more, faster with lesser
planning, estimation...!
That’s exactly opposite to what we did all this time!
@sudiptal
... in every aspect...
... and its our job to educate why and how!
The game has changed...
@sudiptal
1. The nature of applications
@sudiptal
Then!
@sudiptal
Now!
@sudiptal
Recognize that the fundamental nature of applications have changed
UI and application interaction has become paramount! That’s a discovery process
@sudiptal
2. Planning: The way we plan and track has changed!
@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.png
@sudiptal
Estimation: Now...
(Ultra) Fast
Relative
Gut feel first estimate is generally right!https://styleshare.github.io/images/2015-11-05-estimator/planningpoker.jpg
@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!
@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
@sudiptal
Product VisionRelease Vision
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...
@sudiptal
Scheduling/Forecasting: Now… A Kanban system
Henrik Kniberg
Delivered features
Date
When will all of this be
done?
Around week 27-30
@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
@sudiptal
In short, the entire planning and monitoring approach has changed
Estimation, Scheduling, Forecasting
How do you communicate Lean/Agile without bridging this gap?
@sudiptal
2. Requirements – The game has changed!
@sudiptal
These BRDs used to work (mostly)... then!
Our BRDs... then!
@sudiptal
But... written specs are often misunderstood...
@sudiptal
@sudiptal
@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”
@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 anymore
@sudiptal
2. Completeness of BRDs
@sudiptal
Then: Acceptance/payment linked to it
We had to complete every line of the signed off the BRD!
@sudiptalHenrik Kniberg
Now: We know that we build the wrong thing, often
Sources:Standish group study reported at XP2002 by Jim Johnson, Chairman
Always7%
Often13%
Some-
times16%Rarely
19%
Never
45%
Features and functions used in a typical system
Half of the stuff we build is
never used!
Comple
xity
Cost
# of features
This graph courtesy of Mary Poppendieck
@sudiptal
Therefore... Backlog Grooming!
@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!
@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!
@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
@sudiptal
2. CUT: the game has changed!
@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 bogusIt encouraged Developers to test less (and file less defects)!
@sudiptal
Then...
Test Coverage was an enigma!Automation was considered expensive…
… because we viewed as a Project
@sudiptal
Now...
If done right, (near) 100% Test Coverage is accomplishedAutomation, done with development, isn’t another “overhead” cost; saves cost significantlyThe tooling supports this!
@sudiptal
The scope, role and responsibility of “Dev” has changed
TDD is the “new” norm
Sell the “guarantee” of test coverage
@sudiptal
3. Testing: A completely different paradigm
@sudiptal
Then…
Testing is Testing team’s responsibility
@sudiptal
Now…
Testing is everyone’s responsibility
@sudiptal
Then…
Dev
TestCode Drop
The long gap increased risk and wastage
45
@sudiptal
Then...
@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!
47
@sudiptal
Then...
@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
@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 also do not work
@sudiptal
@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)!
@sudiptal
Communicate the “full” picture
Just doing the Ceremonies or putting a Kanban Board is neither Agile nor Lean
The game has “indeed” changed!
@sudiptal
Thank you for your time today... For any questions or
clarifications, reach me at: @sudiptal [email protected] [email protected] http://sudi-
thoughts.blogspot.in/
Join Limited WIP Societies @ NCR, Bangalore, Pune, Chennai, Hyderabad
Join us at Lean Kanban India 2016!Bangalore, Sep 9-10
