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!
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
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
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
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
Hinweis der Redaktion
How many CEOs would get their job if this is what they told their respective Boards?
I would guess that any diligent Project Manager would spend hours manipulating and playing around with this! There used to be a whole time role called Project Administrator just doing this on MS Project.
I would guess that any diligent Project Manager would spend hours manipulating and playing around with this! There used to be a whole time role called Project Administrator just doing this on MS Project.