From: George Dinwiddie <lists <at> idiacomputing.com>
To: scrumdevelopment <at> yahoogroups.com
Sent: Monday, July 16, 2012 7:04 PM
Subject: Re: [scrumdevelopment] How to split a story that doesn't have customer value when split
I've been waiting for time to formulate a useful reply to this.
On 7/8/12 5:20 PM, Cass Dalton wrote:
> One of the difficulties of the systems my company builds
is that they
> are real time systems with multiple software and hardware components.
Cool! Are you aware of http://groups.yahoo.com/group/AgileEmbedded/
> Lets say that you have a system that has to interact with an existing
> system. It has to intercept events that are passing through the system.
> Some events are notifications, some events are compact data streams.
> Each data stream has a preceding notification.
Are these one to one? Or may there be multiple notifications before a
data stream? Or notifications that have no data stream?
> There are some
> notifications/data streams that we want to process, some that we don't.
> There are post-processing plug-ins. Each plug-in is interested in a
> different set of no
I presume the "we" in that first sentence is "a particular plug-in." Is
> These plug-ins, the management of the
data and messages, and everything new aside from a minimal amount of
> code have to live on one or more separate machines (a non-negotiable
> political customer constraint). The first plug-in to be used requires a
> huge amount of signal processing to get any information out of the data
What about the notification? What's required to understand it?
> For example, lets assume that we have to parse an HTML stream
> from only the voltages as seen by the network interface card. But we
> don't have a NIC, we don't have access to any of the existing ethernet
> driver code, TCP/IP network stack, HTTP libraries, etc. We have to
> write all that from scratch.
Why from scratch? Once you convert the v
oltages to ones and zeros, you
should be able to use an off-the-shelf network stack.
> The user need is that they want to automatically parse the HTML
> these data streams.
That sounds like a proposed solution, rather than a need. Surely they
have some use for the parsed HTML.
> To get this done, we have to interface to the
> existing system, build something that will intelligently route the data
> to the right post-processor, something that will make sure that the
> right processor is installed (we're always striving for deliverable code
> at the end of each sprint), and we need the processor.
It sounds like the guts of the system is two-fold:
1. to decide which plugin needs to process the data, &
2. to process the data in some unspecified way.
> I know that I
> have already assumed some of the system design in this description, but> it is for the purpose of describing the complexity of the system. Lets
> just assume that this system design is what the team decided was the
best solution. Even by taking liberties like hardcoding the
> post-processor to use and things like that, it will still take at least
> three sprints to come close to anything that they customer will see as
Is it the processing of the data (which appears to be the real reason
for the system) the thing you think will take 3 weeks? If so, we'll
certainly need to know more about what sort of processing you're doing.
If it's the network interface that's slowing you down, I'd skip that at
first. Prove the processing works to the customer's satisfaction.
There's huge value in that.
I'd start with using some off-the-shelf hardware and software to give
the network interface, and develop the logical heart of the matter,
first. I'd likely start with a simpler process, just to prove out the
decision-making. Or I might start out with hard-coding the decision and
starting with the
processor, as you suggest.
Either way, I'm sure there are more splits that can be done.
Once those two things are working, at least rudimentarily, then I would
start working backwards to replace the hardware with software, assuming
that's a requirement.
> But in my example, that's akin to taking a string of
> the ethernet voltages and manually translating them to IP packets,
> manually translating the string of IP packets to a TCP connection, etc
> on to the HTML stream. There's some customer value in that you are
> understanding the customer's need, but there's still a lot of work to do
> to build the actual system.
Yes, I don't know why your solution is specified to do everything from
scratch. Of course, the
good thing is that some of these are well-known
problems (well-known in the industry, if not to particular people) and
can also be done in parallel if you've
got enough people available.
If you don't have enough people then, well, lots of work means it takes
lots of time. There's still value in seeing the novel parts of the
system work early, and leaving the well-known problems to later.
I hope I've understood you well enough.
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
sp; Consultant and Coach http://www.agilemaryland.org
To Post a message, send it to: scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo
! Groups Links
<*> To visit your group on the web, go to: http://groups.yahoo.com/group/scrumdevelopment/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to: http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)
<*> To change settings via email: scrumdevelopment-digest <at> yahoogroups.com scrumdevelopment-fullfeatured <at> yahoogroups.com
<*> To unsubscribe from this group, send an email to: scrumd
evelopment-unsubscribe <at> yahoogroups.com
<*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/