The document discusses how the game has changed for software development practices. It outlines how planning, requirements, testing and other practices are now different compared to past decades. Estimation, scheduling and forecasting have shifted from lengthy upfront processes to relative and iterative approaches. Requirements are now defined through collaboration rather than written specifications. Testing is a shared responsibility across teams rather than isolated to a separate testing team. The role of testing has changed from finding defects to delivering quality. Adopting agile practices means recognizing how the entire ecosystem for development has evolved.
2. Why this talk?
Lean/Agile Adoption has been weak!
Mostly, at Team level
A few at Program level
Almost none at Organization level
3.
4. Just reflect on what we preach today...
No Projects
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, estimation...!
That’s exactly opposite to what was
practiced for the last 5-6 decades!
16. 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. In short, the entire planning and monitoring
approach has changed
Estimation, Scheduling, Forecasting
How do you communicate without bridging
this gap?
23. We accept that requirements are
effective only when given by a
conversation...
... between Business and
Development...
... supported by a common
understanding of what is
“acceptable”
24. Written requirements have failed as the
artefact for Requirement definition
The importance of collaboration (not hand-
off) between the 2 parties is established!
CR/Scope Change isn’t paramount anymore
27. 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
29. Recognizing premise of conversation...
Implement...
Demo early
Requirements as per INVEST
Automate
Deliver Continuously to get Early Feedback
Feedback for change is welcome!
30. 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!
31. 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
33. 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
It encouraged Developers to file less defects!
34. Then...
Test Coverage was an enigma!
Automation was considered expensive
Yes, when viewed as a Project
No, when viewed as a Service
35. Now...
If done right, (near) 100% Test Coverage is
accomplished
Automation, done with development, isn’t another
“overhead” cost; saves cost significantly
The tooling supports this!
36. The scope, role and responsibility of
“Dev” has changed
TDD is the “new” norm
Sell the “guarantee” of test coverage
44. Thought Process 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
45. 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
46. 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)!
47. Understand that the ecosystem has
changed
Just doing the Ceremonies or putting a
Kanban Board is neither Agile nor Lean
You won’t get any Agility with the same!
Give the complete picture
The game has “indeed” changed!
