Avoid
Waste (!Waste)
Here are some of the most known work optimizing principles
related to Avoiding Waste, where many
of them have as source TPS philosophy to avoid sources of Muda/Waste (it is better to return to original ideas, beyond
various further Lean evolutions; see biblio-TPS)
The other two are the ones that bother me the most, and could be specific for knowledge work: Not Used Talents and Improvement
Stalemate. In our case, these
sources of waste will be interpreted from software domain point of view.
Principles
& practices. XP, Scrum and DA
As
in the case of Core Agile Capability we need have a traceability between
principles, values and the practices that bring them to live. A such trace could be found at the end only from what is useful in the real work.
In
the following parts, we will try to present how this realization is done by practices
from original main Agile methods: XP-Extreme Programming and Scrum and how we can get a more robust approach using DA - Disciplined Agile. We mention only
practices that are explicitly
mentioned by the methods & their guidance ... and what we have found that works in real practice. Here it is summary, I will come back with details for each part.
"What we need" - description of what we have find that it is working to manage that aspect of the waste.
Important: if Core Agile Capability – Responding to Changes - is not met, the software development is not optimized from the start: this core capability address all the optimizing work principles at their fundamentals.
.
No
Inventory: reducing work in progress
What
we need
· First, we need to
“make the work easy” (See biblio-Kent_Beck): a big work in
progress (inventory) will exponentially increase the complexity &
incertitude, will reduce reaction time (core required capability) and quality.
· Reduce the work
in progress (WIP) on all possible dimensions, from making the release smaller
to avoid multi-tasking
Avoid
Defects
What we need
· To prevent
defects & catch them as early as possible ~ provide build-in quality; all the practice that “shift left” the quality risks will be useful
· First, to make
the work easy: see Avoid Overproduction and Avoid Big Inventory
Avoid
Waiting
What
we need
· Work should be
“Ready” – actionable (!) - before start
using main resources: we do not want to wait for dependencies related to information,
artifacts and others; what is missing usually is the overall perspective, that
a Rolling Wave approach could bring:
product, release, iteration, inside iteration
· We want to avoid
bottlenecks in work, such skills (specialization) bottlenecks
Avoid
Overproduction
What
we need
· To avoid “Big
work” that bring many risks: it is hard to include & manage required changes,
it is a high probability to deliver results that are no more needed
· To develop and be
ready to deliver big value first; will be much easier drop not started “junk stories” on request
· To not guess
about production needs: mixing envisioning and JIT on requirements and solution,
implement what and if is needed
Avoid
Over-Processing
What we need
· Avoid extra work,
not required by customer
· Avoid process ceremonial
that does not bring value
· See also dedicated
sections for: Avoiding Defects (Built-In
Quality), Avoid “Transport & Motion”, Avoid Re-Work
Avoid
“Transport & Motion”
What we need
- If,
in case of manufacturing, products could be damaged by transport & motions,
we can found an equivalent for this waste, also for knowledge work/software
development: unnecessary long chain of information handover & information
duplicate in a long chain of artifacts.
- Successive
handovers could be caused by lack team ownership over information and lack of
cross-functional skills
Avoid Not-used
talents
What we need
·
Practices support
to quick and effective learning & skills improvement
·
To develop
cross-functional skills. Example: a programmer with requirements & testing
skills will perform TDD and design better
Continuous
Improvement & no persistent impediments
·
To avoid blockage
on process improvements
·
A process that
make the impediments visible & it is effective on removing them
Avoid
rework
What we need
·
To avoid “Waterfall
rework”: big work with too few feedbacks could increase rework to infinite
·
To avoid “Scrum-Agile
rework”: lack of look ahead on requirements & solution could induce need of
rework
·
To avoid late defects
detection – see Avoid Defects
·
Finally, we need
to balance envisioning and defer of the commitment (JIT) and also get as much
feedback it is possible
Final
thoughts
Work optimization it is
related to some main ideas:
·
Teams should
choose the optimum practices and ways of work in context
·
A good range of
skills and known practices maximize the also the range of available options
Disciplined Agile principles are about choices and growing
team’s members, offer a solid fundament and guidance for work optimizations,
while including also XP and Scrum related practices.
Notes about practices
Specific for Agile is that with one practice we can get multiple
benefits. If the same practice could address more sources of waste, we could
consider that practice as more valuable for our process.
See specified bibliography for each method for more details
about mentioned practices
Bibliography
Biblio-TSP
·
Toyota Production
System: Beyond Large-Scale Production 1st Edition, by Taiichi Ohno,
Productivity Press; 1 edition (March 1, 1988)
·
https://en.wikipedia.org/wiki/Toyota_Production_System
Biblio-Kent_Beck
Biblio-DA Disciplined
Agile
·
“Disciplined
Agile Delivery: A Practioner’s Guide to
Agile Software Delivery in the Enterprise”, by Scott Ambler and Mark Lines
Biblio-XP Extreme Programming
·
Extreme
programming explained: embrace change, Kent Beck, Addison-Wesley Professional;
US ed edition (October 5, 1999)
Biblio-Scrum
·
Software in 30
Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave
Competitors In the Dust 1st Edition, by Ken Schwaber , Jeff Sutherland
