In this slidedeck, we help explain how our messaging to the Leadership team, that is largely experienced in conventional ways of software development, must change to help them understand how Lean-Agile thinking drive Business Agility. This specific presentation is focussed on how the messaging around Requirements needs to change!

1. @sudiptal
GETTING “REQUIREMENTS”
RIGHT FOR BUSINESS AGILITY
Sudipta Lahiri
Head of Engineering and Products, Digite
1

2. @sudiptal
BusinessAgility
■ Ability of a business system to rapidly respond to change by adapting its initial stable
configuration (https://en.wikipedia.org/wiki/Business_agility)
2

3. @sudiptal
We preach some pretty “weird” stuff… to achieveAgility!
“Projects” is a bad term!
No(almost) Estimation!
Zero Budgeting!
No Managers but “servant-leaders”
Don’t allocate work... let people pull their work!
Multi-tasking is a bad thing!
Tracking 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 we did all this time!
3

4. @sudiptal
maguzz.henislie.com
4

5. @sudiptal
Digite’s Business AgilityWebinar Series
■ Designed to unravel some of these “weird” ideas…
■ Covering topics of Delivery from Estimation => Planning => Forecasting =>Tracking
to
■ Covering topics of SDLC from Requirements => Build &Test => Deployment
■ Let’s start by understanding the “starting point…”
5

6. @sudiptal
Change comes to as a “Requirement”…
■ For software development, this means 3 important things:
1. The Requirement should be clear…
2. Team must be able to accept this change
1. Ideally, not leave existing work midway to taking it to a logical conclusion
3. Delivering “rapidly” must be associated with a concept of size!
Let’s take this one step at a time…
6

7. @sudiptal
1. “Change” as clear Requirements
■ We all understand that when a Requirement goes to Development, it must be fully
thought off…
– It must be fully “spec(ed)”
■ Question is:
– Can we “really” do it?
7

8. @sudiptal
“Requirements” => “Hypothesis”
■ Earlier paradigm of “defining”
Requirements is plain optimistic!
– You will not get it right
– It will change sooner than you
think!
■ Product Management can only
“guess” what is needed…
– Quickly roll that out => Measure
market reaction => Recalibrate!
– Premise for Lean-Startup
8

9. @sudiptal
The “work” dimension
■ If people are deeply immersed in a big chunk of work,
it’s hard to drop the ball and jump to something new
■ Things must be brought to a logical point so that it
can be restarted later
■ Working in shorter buckets of time will cause lesser
disturbance for the team; reduce the wait time for
the “change!
– 1wk better than 2wks better than 1mth…
The “people” dimension
■ People need to understand that this is
the new “norm”
■ Change does not mean bad planning
OR incomplete pre-requisites
■ However, “Change” does mean
shifting gears; its disruptive and
people have to be educated to be
patient
– Explain theWhy and the Impact
2.Team’s ability to “Accept Change”
9

10. @sudiptal
3. Delivering rapidly
■ Smaller the size, the faster you can deliver
– It still has to deliver value… else, you won’t get market feedback!
■ High level of Quality is taken for granted
– Delivering rapidly cannot be at the lost of quality
– Need a high level of delivery maturity to deliver consistent quality
■ Automation is key!
– You cannot afford to lose time in testing manually!
– Given that we are testing a hypothesis, we will need to keep reiterating
■ Manual testing is not an option; get theTesting Pyramid right
– CI/CD pipelines can cut short the CycleTime from post-development to Production to
near 0
10

11. @sudiptal
Therefore, if you need Business Agility…
■ Your unit of work must deliver VALUE
– Why else would anyone use it and give you feedback?
■ Your unit of work must be INDEPENDENT
– Cannot be dependent on many other requirements to get deployed to production
■ Your unit of work must be SMALL
■ Your unit of work must beTESTABLE
– You need fully contained with all theTechnology layers together
– You cannot work with “Tasks” needed to get that small requirement done!
■ Your unit of work must be MEASURABLE
– You need to clearly know how you will validate if people like it or not!
– You need an Acceptance Criteria with objective metric to measure against criteria!
11

12. @sudiptal
With those SMALL, INDEPENDENT,
TESTABLE, MEASURABLE units of work that
deliverVALUE……
■ You need to deliver is short time buckets…
■ You need to deliver with full Automation with the rightTesting Pyramid and a CI/CD
pipeline
12

13. @sudiptal
There is no “CRITICAL PATH”
with INDEPENDENT stories…
https://tensix.com/2017/08/monitoring-critical-paths-to-any-schedule-activity-in-primavera-p6/https://en.wikipedia.org/wiki/Critical_path_drag
13

14. @sudiptal
Kill the “Acceptance Phase”
14
https://t2informatik.de/en/smartpedia/90-90-rule/
Acceptance Phase

15. @sudiptal
Recommendation
■ If you are doing Support or Maintenance, you would be getting small independent
work requests –Tickets, Defect Fixes, Small Enhancements
■ If you get large EPICs or new development ideas, then you need a technique to
identify Stories that are SMALL, INDEPENDENT,TESTABLE andVALUABLE
– That technique is “Story Mapping”
– Extremely powerful to get your Stories identified in an extremely fast, transparent
manner without extensive back-and-forth discussions
– With prioritization => leading to Release Planning
– A few extra steps will able you complete (Agile) Estimation
– Can finish this whole process for a 40-50pm work in a day!
15

16. @sudiptal 16

17. @sudiptal
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
The funny thing is…
17

18. @sudiptal
From the Lean-UX BoK From the Kanban ESP BoK
A few approaches to “identify” that ~50%
https://medium.com/@divoviyam1994/red-route-in-application-design-1a61251225a
18

19. @sudiptal
The “Fixed Scope” conundrum…
■ End users/Customers have an expectation of “what all I need…”
■ What happens IF because of continuous feedback, this scope cannot be completed
■ Best Case Scenario
End User/Customer understands:
■ Agile; continuous prioritization
■ All of system is never used; Edge
use cases make system more
complex; take more effort!
■ We got best value by focusing on
what we really need NOW
■ How:
– Keep them in the process
– Be transparent
■ Not so great scenario
End User/Customer understands:
■ What you did; why you did it…
■ Acknowledges that you have delivered what they
value but not completed the original scope
■ They were part of the re-prioritization; it was
done with their consensus.Whenever they re-
prioritise, highlight what got bumped
■ It could have got bumped for developer issues (A)
OR customer issues (B) OR either/neither (C)
– For A: Accept and bite the bullet
– For B: Follow theCC process
– For C: Negotiate; find a middle path
■ Worst Case scenario
End User/Customer does not care!
■ Keep asking the Customer IF they
need what was original spec(ed) OR
what the feedback is now!
■ If they don’t want to get involved,
escalate to the next level
■ If they still do not respond, then
stick to the original scope; ignore
the feedback!
■ If they still want to stick to the
original scope, so be it!
19

20. @sudiptal
The “visible” anti-patterns!
■ High Defect Leakage
– You aren’t ready for any of this!
– Need to get your house in order to make this happen
■ Lots of Dependencies
– SAFe designed Dependencies for points of collaboration – not to define Dependent
requirements
– If you have Dependencies, you do not have “INDEPENDENT” work
■ Will increase CycleTime, Blocks, delayed market feedback!
■ Tasks on the Board
– A different card for front-end, a different card for back-end
■ Horizontal slicing vsVertical slicing
20

21. @sudiptal
In closing…
■ We cannot predict anymore what will work in the market
– We need to make quick releases with small, independent work units (Stories)
– We need to using specific techniques to make this possible
– We need to explain early in the life-cycle, that a FixedTime, Fixed Budget but
continuouslyVariable Scope IS MORE BENEFICIAL than delivering Fixed Scope, Slipping
Timeline and Slipping Budget!
■ Message your Elevator Pitch around:
– Business Agility withoutCritical Path….
– Business Agility without Acceptance Phase…
■ In subsequent webinars, we cover how Estimation, Planning, Forecasting and subsequent
Execution have undergone a radical change to build modern day systems… … and how you
can sell this to your Leadership!
21

22. @sudiptal
■ Reach me at:
– @sudiptal
– slahiri@digite.com
– lahiri.sudipta@gmail.com
THANK
YOU!
22
“Absorb what is useful, discard
what is useless and add what is
specifically your own”
Bruce Lee