Re: Why develop verttical slices of functionality? (Definitive Texts)
- Hi David,
--- In email@example.com, "david.hicks_radtac"
>Rather than texts, consider this. The answer is two fold, one related
> Hi - can anyone recommend the best texts for explanations of why it is
> best for teams to develop complete vertical slices of functionality
> rather than (for example) back-end components.
to RISK and the other related to TRUST:
RISK: With the rate of change of technology and the ridiculous number
of moving parts in those technologies to build industrial strength,
web-enabled apps., the risk of pieces not doing what you expect is
very high. We have one to two dozen syntaxes and semantics of the
different components to manipulate. We partition the problem based on
limitations of the technology, not to match sensible business
structure. So the benefit of doing what Ken Schwaber calls sashimi,
slices through the problem, validates that this collection of
components and versions can deliver value now. With the next version
change, it needs to be verified again. And that's where the safety
net of XP comes in. XP folks call this this practice - doing a spike
or a tracer bullet.
TRUST: There is s terrible history of the business giving the
developers some requirements/specs and then needing to wait for months
to see anything that represents value to them. If on every iteration,
we can show those funding the project some visible progress in their
terms they will be much more inclined to continue to pay for the
project and feel good about it. And even more importantly, it keeps
the discovery conversation going between the user community and the
development team as they simultaneously discover what will work for
So that's the essence of it - managing risk and trust while maximizing
I hope this helps David - let me know if you need more detail or help
with training and coaching your development and management teams.
Lean/AGile Coach, Trainer and