All About Agile: Breaking complex features into something that can be delivered in an iteration - Agile Software Development Made Easy!

Message from discussion All About Agile: Breaking complex features into something that can be delivered in an iteration
Received-SPF: pass (google.com: domain of hubert.sm...@gmail.com designates 209.85.198.238 as permitted sender) client-ip=209.85.198.238;
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=x8Ztd/vSbqWr6HNXvJV8FPFGT4yGRcN1FVTdjfpg2bYM8s70IMKE9ErFgoRskm9yz0
         Ip2egpYKwHTmeIxNeDsrkDj0nvV1L1Ox/b0qlN3cmZhZOwzw4K3QXtV0kiunDCfAoaAh
         P40bL2Pnx1pL/gl/IgCE6X+PiGp+7xOlUXnq4=
Message-ID: <4bbcf6e30810151420l726ec099p2c359f462b7aa144@mail.gmail.com>
Date: Wed, 15 Oct 2008 15:20:11 -0600
From: "Hubert Smits" <hubert.sm...@gmail.com>
To: allaboutagile@googlegroups.com
Subject: Re: All About Agile: Breaking complex features into something that can be delivered in an iteration
In-Reply-To: <4b61da32-758c-4939-8695-ac2f07b1a...@v13g2000pro.googlegroups.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_28035_10341785.1224105611767"
References: <4b61da32-758c-4939-8695-ac2f07b1a...@v13g2000pro.googlegroups.com>

------=_Part_28035_10341785.1224105611767
Content-Type: text/plain; charset=ISO-8859-1

Hey Stevio,

A1: Go to Bill Wake's website (XP123.com) and look for the article "Twenty
ways to split stories"

A2: Create a release, starting with release planning, and a number of
Sprints. Every Sprint delivers the prioritized architectural stories, *proven
by user requirements*. The user material can be minimal, but it has to be
real and serves to prove that your architecture things are working in a real
environment. The first release can have a release goal to 'prove the
architecture'. More info in my paper on 5 levels of planning (see
www.rallydev.com). Try to keep this release as short as possible, you will
not to be able to predict architectural requirements any more then you can
predict user requirements.

A3: I don't have one documented (did see the AOL Video API team do this
successfully). Browse around the yahoo groups for the Embedded Agile group.

Success, Hubert

On Wed, Oct 15, 2008 at 12:00 PM, Stevio <st...@jsbrewer.plus.com> wrote:

>
> Q1. Is there any very clear and concise presentation/material
> available anywhere which summaries to senior software chaps how to
> break complex features down into chunks that are small enough to
> implement and test within a single Scrum iteration?
>
> Q2. If a new feature requires a major investment in terms of new
> architectural infrastructure which is going to take multiple sprints
> to develop (it's 3 months work), what do you deliver as working,
> tested code at the end of an sprint? If you spend lots of time
> developing unit tests for this, they are pretty much useless later in
> the process once more of the design has been implemented and are
> therefore seen as wasted effort.
>
> Q3. Does anyone know of a real world example that is well documented
> somewhere which shows the power of Agile in a complex embedded
> development environment (not applications)?
>
> Both of the above are being given as objections to us adopting Scrum
> and I'd like some help removing these blockages.
>
> Thanks for any suggestions,
> Stevio
>
> >
>

------=_Part_28035_10341785.1224105611767
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">Hey Stevio,<br><br>A1: Go to Bill Wake&#39;s website (XP123.com) and look for the article &quot;Twenty ways to split stories&quot;<br><br>A2: Create a release, starting with release planning, and a number of Sprints. Every Sprint delivers the prioritized architectural stories, <u>proven by user requirements</u>. The user material can be minimal, but it has to be real and serves to prove that your architecture things are working in a real environment. The first release can have a release goal to &#39;prove the architecture&#39;. More info in my paper on 5 levels of planning (see <a href="http://www.rallydev.com">www.rallydev.com</a>). Try to keep this release as short as possible, you will not to be able to predict architectural requirements any more then you can predict user requirements. <br>
<br>A3: I don&#39;t have one documented (did see the AOL Video API team do this successfully). Browse around the yahoo groups for the Embedded Agile group.<br><br>Success, Hubert<br><br><div class="gmail_quote">On Wed, Oct 15, 2008 at 12:00 PM, Stevio <span dir="ltr">&lt;<a href="mailto:st...@jsbrewer.plus.com">st...@jsbrewer.plus.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Q1. Is there any very clear and concise presentation/material<br>
available anywhere which summaries to senior software chaps how to<br>
break complex features down into chunks that are small enough to<br>
implement and test within a single Scrum iteration?<br>
<br>
Q2. If a new feature requires a major investment in terms of new<br>
architectural infrastructure which is going to take multiple sprints<br>
to develop (it&#39;s 3 months work), what do you deliver as working,<br>
tested code at the end of an sprint? If you spend lots of time<br>
developing unit tests for this, they are pretty much useless later in<br>
the process once more of the design has been implemented and are<br>
therefore seen as wasted effort.<br>
<br>
Q3. Does anyone know of a real world example that is well documented<br>
somewhere which shows the power of Agile in a complex embedded<br>
development environment (not applications)?<br>
<br>
Both of the above are being given as objections to us adopting Scrum<br>
and I&#39;d like some help removing these blockages.<br>
<br>
Thanks for any suggestions,<br>
Stevio<br>
<br>
<br>
</blockquote></div><br></div>

------=_Part_28035_10341785.1224105611767--