Re: Agile Specification?
- If it looks like a duck, walks like a duck, and quacks like a duck...
Why not simply call it a requirements specification? I don't see
anything particularly agile about it. This is neither good nor bad.
Requirements should *always* represent the minimal amount of
information necessary to capture the scenario(s).
This reminds me of the "debates" when use cases were introduced into
OO circles in the early UML days. Some argued that use cases weren't
object-oriented. Well, of course. They're requirements, not objects.
--- In firstname.lastname@example.org, "Jeff Sutherland"
> When Alistair says something like:
> "There is no such thing as "agile specification".
> The phrase is a hoax."
> It means there is something really interesting to talk about.
> At PatientKeeper we have "Agile Specifications" in order to solve a
> problem. Maybe Alistair can come up with a better name.
> Problem: You will implement over a thousand user stories over many
> years at random times. Very tight precision is required for screen
> shots, flow, and business logic as a error could kill a patient. Or a
> physician could call it "crap" and refuse to use it.
> Forces: Physician users require an exact fit to their workflow, their
> inferencing from clinical data, in minimal time while standing in
> front of a sick patient using their iPhone for all clinical data.
> Developers have no idea exactly how this should look to a physician.
> Neither does the Product Owner, even though the Product Owner may be a
> physician. Physician thought leaders must use working prototypes to
> determine exactly how it should look and feel to the physician while
> coming to a consensus and developers much exactly create their chosen
> approach or physicians may refuse to use the product. Physicians will
> not use a mouse. Most things must require one click and anything
> requiring more than three clicks will never be used as it will
> interfere with conversation with the patient. Any data corruption is
> life threatening. Lack of ease of use is life threatening.
> For example, a small amount of the clincial data is lab results. There
> are dozens of lab tests, each producing a complex data set with
> multiple values and normals ranges. There is interaction between these
> results. Automatic alerts for critical conditions based on a complex
> relationship between multiple lab results is needed. These are
> regularly updated by clinical boards that determine best practice. All
> lab tests are graphed differently to exacting specification taught in
> medical schools. Often new lab tests are required. They are based on
> research data developed in labs. The developer must be able to quickly
> review all previous implementations of all lab results to fit this new
> result into the physician's workflow in the correct way. The physical
> implementation of the current product is not sufficient for this
> Solution: The Product Owner creates a dccument that is just enough,
> and just in time called Lab Tests. It grows over time as there are
> more lab tests, and as research data influences lab test results. The
> Product Owner does high level analysis of screen shots, workflow, data
> structures, business logic and presents it as a very light weight use
> case to support user stories implemented at a point in time. The
> Product Owner has tested a fully working prototype of this
> implementation on a group of physician thought leaders before any
> story for these is ready to go into a Sprint. Developers refuse to
> develop any story that does not achieve this "ready" state. In fact,
> they are told to take the day off if the Sprint Backlog is not "ready."
> Result: Over eight years and thousands of stories the global
> specification has grown to almost thirty pages. A development can
> capture in his mind in less than five minutes the history of
> implementation of all lab results than is essential for implementation
> of a new blood test for treating diabetic patients.
> The Product Owners are extremely disciplined in this environment. They
> know developers will take the day off if their "Agile Specification"
> is not in a ready state for creation of user stories in a Sprint.
> The Team is also very disciplined and achieves a velocity that is 10
> times as fast as their waterfall competitors causing revenue to
> quadruple in 2007.
> Name for this thing: Up for grabs.
> Need for this thing: Absolutely essential or you will risk killing
> patients Or even worse, the physicians will refuse to use it declaring
> it "a piece of crap."
> Jeff Sutherland
> --- In email@example.com, "aacockburn" <acockburn@>
> > --- In firstname.lastname@example.org, "chuckspublicprofile" <chuck-
> > lists2@> wrote:
> > >
> > > I'd rather have a 1-30 page doc then 100 use cases each being 2
> > > pages. :-)
> > That has to be one of the most bizarre non-comparable pairs I've
> > ever seen. A 1-30 page doc is for 1 user story, which is one
> > sentence in a 2-page use case.
> > If your project has 100 2-page use cases to implement, that means
> > you're going to be looking at
> > 100 use cases X 20-30 user stories per UC X 3-30 pages spec
> > = 50,000 pages of "agile specifications"
> > At that point, they're not agile, and you'd be better off with
> > just the 100 2-page use cases.
> > On the other hand, if all you have is 1 user story with 10-30 pages
> > of documentation, then all you'd have on the other side of the
> > fair comparison is 1/2 a page of use case. In which case you'd
> > probably be better off with just the 1/2 page of use case.
> > Please get your comparison partners straight.
> > > (Maybe I misunderstood you to be negative on the so
> > > called "agile specification" doc)
> > >
> > I do dislike the phrase "agile specification" -- not because Jeff
> > chooses to write something down, which is fine by me and totally
> > up to his team, but because he or someone is passing this off
> > on the community as a "new standard OK thing", which it isn't.
> > What is OK is to write stuff down, whatever the team feels they
> > need to write down to keep track of the work.
> > What is not OK is to act like everyone should want to write down
> > the same stuff, when in truth different teams all want to write
> > down different amounts of stuff and different stuff inside that.
> > There is no such thing as "agile specification".
> > The phrase is a hoax.
> > This has nothing to do with either user stories or use cases.
> > Alistair
- God I've seen those disturbances too, but like I said, I respect both
perspectives. It's a very fine line.... very fine line....
Someday we'll figure out a way to punish these offenders and abusers. :-)
--- In email@example.com, "aacockburn" <acockburn@...>
> Hi, Chuck --- not much there for me to disagree with, which is
> remarkable considering how long it is :-)
> -- except possibly that I have managed to live long
> enough (10 years :) to see such seeming minor phrases become
> major disturbances that never get put out. I was sensing
> 'agile specification' as one of these, and hence jumped
> (seemingly overenergetically) right away.
> I wish others would have your sense of pragmatism,
> (Oddly enough, the use case book seemingly achingly Shu level
> to me - I can't imagine writing more Shu level. ouch. :)
> (for Ri level, see my Agile Software Development book, or even
> the Crystal Clear book, which is a Ha-Ri mix.)
> --- In firstname.lastname@example.org, "chuckspublicprofile" <chuck-
> lists2@> wrote:
> > (Forgive me if I misuse the Shu-Ha-Ri thing -- just recently read it
> > for the first time and since Mr. Cockburn is part of the primary
> > audience in this discussion, wanted to try to connect with his
> > communication patterns.)
> > I see value in both perspectives, so let me say that first. I'm the
> > OP, and I wasn't looking to quote anyone so much as understanding
> > this "interesting facet of agile" was all about, and I had trouble
> > finding it defined elsewhere.
> > I think I could make a case for saying that a) The AS should be a
> > strongly suggested or required artifact/activity but b) only in
> > part because the definition is still pretty wide open. However, I
> > could care less whether it should be so, as every client I've worked
> > at evaluates said tools and chooses them based on their own needs.
> > such, I have no compelling reason to argue the AS, or the name for
> > that matter.
> > Now, back to "providing problem context" and truth in advertising,
> > I think more defined/practical/Shu (whatever you want to call it)
> > processes/techniques/activities have value. I also think that more
> > qualified/contexted/Ri (less defined, more general, etc)
> > processes(etc) have value too.
> > One could argue it both ways. For instance, I have been a huge fan
> > Mr. Cockburns work on Use Cases. However, he wrote one book (I
> > it was Writing Effective Use Cases), that totally threw off one of
> > clients. The book was so advanced (Ha-Ri?), so qualified, so
> > and context sensitive, that these clients of mine were confushed and
> > mis-using his advice. They were writing use cases, that within a
> > SINGLE use case, they were communicating at vary high ranges of
> > altitude (cloud-sea, kite-underwater, etc). That was just one of
> > misuses they were committing. They were operating at the Shu level
> > but thinking they were at the Ri level (this happens a LOT in the
> > industry, IMO). It was a mess. Having had 8 years of prior Use
> > experience and study of Mr. Cockburn's works, I showed up and
> > to get them to focus on sea level as a first step, and things got
> > markedly better. I think Mr. Cockburn even says, in that book, that
> > sea level is where you tend to get a lot of ROI.
> > My point in telling this story is as follows:
> > - Having both very practical(Shu) level advice and very highly
> > "context sensitive"(Ri?) advice is good. Even practical level
> > that has very little context can be good. In the end, people solve
> > problems, not books/articles/emails. As such, both ends of the
> > spectrum can get people in trouble.
> > - People can misuse BOTH levels very easily, quoting Mr. Agile Guru
> > much as they want. Anyone who believes something solely because Mr.
> > Agile said it is a fool anyway, and I don't actually know many
> > who do it -- as most developers thing their ideas are just as good
> > better than any Gurus(which I disagree with in general)...
> > And full circle, back to the AS. First, it's a very remote point,
> > we saw -- it's barely mentioned anywhere on the internet, and not in
> > any agile books that I'm aware of. Mr. Sutherland likes it and has
> > been very careful to define the term loosely. AFAIK, Mr. Sutherland
> > hasn't mentioned anywhere that it is a required activity/artifact,
> > other than to gain a measly 2-3 points on the enhanced Nokia test,
> > in his training courses), something only a small fraction of the
> > industry pays attention to anyway.
> > In conclusion, I don't think, currently, that the use of the term AS
> > is really going to have much impact and certainly much negative
> > impact. Hopefully, when Mr. Sutherland gets time, he can expound a
> > little more on it. In the meantime, I get what he is saying, and
> > not going to go tell anyone that we have to do it because Mr. Agile
> > Guru X said it. Some dumbarses might do that, but really.... there
> > NO cure for the dumbarse disease, so we might as well realize that
> > move on. Just my 1 cent. (I could charge 2 cents if I was
> a "guru" --
> > hee hee)
> > Charles Bradley
> > --- In email@example.com, "aacockburn" <acockburn@>
> > wrote:
> > >
> > > --- In firstname.lastname@example.org, Robert Biddle
> > > <Robert_Biddle@> wrote:
> > > >
> > > > Oh, I did see and understand the objection.
> > > >
> > > > It's just that I didn't understand the strength with
> > > > which you objected. I still don't.
> > > >
> > > > Maybe I missed where it was being implied that everyone
> > > > should do the practice?
> > > > Or maybe I don't understand your feelings about the use of the
> > > > word "Agile"?
> > >
> > > No - it's not the word 'agile'.
> > >
> > > There are some people who hold a lot of influence in this
> > > Jeff's one. (OK, I'm one, and Ron's one, and Martin Fowler's one,
> > > Mary Poppendieck's one, etc.).
> > >
> > > When one of us makes a sweeping generalization that x-and-so is
> > > the "agile missing piece", then there will be lots and lots and
> > > lots of people who will run around quoting that person (as we
> > > already saw with Jeff's 'agile specification').
> > >
> > > And what they will be running around with will be damagingly
> > > wrong, because they are really citing "Mr. (Mrs.) So-and-So's
> > > Personally Used Possibly One-Off Solution to a Particular