Loading ...
Sorry, an error occurred while loading the content.

Re: Why develop verttical slices of functionality? (Definitive Texts)

Expand Messages
  • jay_conne
    Hi David, ... Rather than texts, consider this. The answer is two fold, one related to RISK and the other related to TRUST: RISK: With the rate of change of
    Message 1 of 6 , Sep 3, 2008
    • 0 Attachment
      Hi David,

      --- In scrumdevelopment@yahoogroups.com, "david.hicks_radtac"
      <david.hicks@...> wrote:
      >
      > 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.

      Rather than texts, consider this. The answer is two fold, one related
      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
      them.

      So that's the essence of it - managing risk and trust while maximizing
      learning.

      I hope this helps David - let me know if you need more detail or help
      with training and coaching your development and management teams.

      Jay Conne
      Lean/AGile Coach, Trainer and
      ScrumMaster Practicing.
      www.jconne.com jay@...
    Your message has been successfully submitted and would be delivered to recipients shortly.