Re: Re: SIP is not Takt Time

Hi Ron,

This mail came as I left the office to do some real work. And so I thought 
about it for awhile as I painted windows. When I got home from work Kent's 
post had arrived. His post changes everything I had thought about writing 
in my reply to you.

> > Imagine XP software that is being built on the shortest possible SIP
> > cycles. Would that tell the buyer of software that the right software 
> being
> > built? It may, but I don't believe it necessarily does.
>
>Here is where I feel us separating. If SIP is time from feature defined to
>feature in hands of user, then in fact short SIP will tell us a lot about
>whether it's the right software: the user will say "No, wrong, not it".
>That's why the Customer Team in XP is supposed to include real users.

Bookkeeping has a built in test. That test is there to serve both the craft 
contributor writing the software and the business person as a customer 
buying a service. The customer needs the bookkeeping test just as much as 
anyone in the chain of commercial trades that is taking place.

This is where Kent's comments change things. Kent said: "Eventually I'd 
like to make SIP money-oriented--the time from when the money starts 
flowing out to the time when the money starts flowing in (really hits our 
bank account)."

Clearly Kent want bookkeeping. Kent doesn't seem to know yet that his 
stated goal is what bookkeeping is and has been for 600 years. Surely you 
see that Kent's concern for where the money is--a most natural concern--is 
every bit the concern that a customer suffers investing money in producing 
software.

> > Something more is
> > needed. My argument is that there is an issue of a greater whole that is
> > complementary to and an essential part of the XP and SIP facts.
>
>I'm not sure what greater whole you are mentioning. Feature idea to feature
>in hands of end user is pretty wide. What else are you trying to encompass?

The same issue that Kent has added to the context of our conversation when 
he said: "This brings the length of billing cycle and the length of the 
collection cycle into the picture".

Whether software contributors are aware of it or not, the money cycles that 
Kent is calling to mind are always happening. There is no reason that 
knowledge of these money cycles cannot be fully present in the day to day 
decision process that takes place between the software's craft contributor 
and the software's customer.

If your experience then is like mine, you will find that more often than 
not such knowledge will expose instances where too little money is being 
budged in one place and too much is being spent in another. The bookkeeping 
pattern, you will learn, is identical to the issue of documentation. You 
have told us that there is a right amount of documentation. And the craft 
person in the heat action, in many cases, is the best person to decide what 
should be documented.

The same pattern works for economics. If a contributor does not know where 
the requirements stand relative to a budgeted whole, some things are going 
to be rushed when they deserve more time, and other things are going to get 
wasted cycles because someone harbors a myth that there is value in a thing 
when in fact there is not. Knowledge is power.

> > A sound
> > bookkeeping framework creates a real time whole image of a project in 
> which
> > the story cards are elements of a language that in due time tell this
> > greater story. The stories that are not yet in process are represented by
> > estimates. There are many examples of this both from building and
> > manufacturing that I could share.
>
>You have driven into the weeds here by adding in your favorite pony, or
>some metaphor that works. Bookkeeping is a way, not a truth. What is the
>additional information about a software project that you'd like to track,
>outside of SIP?

I wracked my brain on at work wondering how I might reply to this. When I 
got home Kent had done the job for me by saying: "When I was at a 
supercomputer startup, everybody was aware the number of days receivables 
stayed outstanding, partly because of the cash flow implications (would our 
paychecks clear), but mostly because it was the most concrete feedback 
engineering got about whether we were doing a good job. If receivables went 
from 45 to 90 days, it was most often because we weren't delivering 
value--customers didn't have enough training to use the machine, the 
installation procedure was too hard, the hardware was flaky."

Bookkeeping, Ron, is more than just a way. Like all good tests it does 
deliver a truth. Once you understand the bookkeeping test, in all its 
simplicity, which gives it its power to know present states in the money 
cycles, you will feel differently toward what you are saying above. There 
is ignorance here to be transformed into knowledge.

> From the intelligible part of the above quoted para, I guess you are saying
>that the stories actually undertaken and their fate in the hands of users,
>as optimized according to SIP, are part of the story. Another part is the
>stories "contemplated": written on cards but not yet committed into detail.

Chinese philosophy places stories into two categories. One category is 
"yin," which translates as "the cloudy, or mysterious." Yin is day to day 
story cards that, once knitted together, produce a working system. Stories 
knitted together form the category the Chinese call "Yang." Yang translates 
as "something shone upon, as banners waving in the sun."

How individual software stories tie together to form a concise and seamless 
whole is a mystery for me, just as how bookkeeping stories may be a mystery 
for you. But once tied into the whole, we tend to take for granted how the 
magic came into being. Well, the reverse happens as well. For the customer 
requesting stories and the craft contributor programming them into a coded 
fabric, it is just as easy to take for granted that somehow the details 
will all fit together into the right seamless whole, the magic that we are 
looking for. In the yang category of stories of the system as a whole 
software has as large a graveyard--or Balls of Mud--as any other discipline.

>A product vision in story cards; a movie vision in storyboard, with scenes
>not yet shot and perhaps never to be; architectural sketches of home
>features or room treatments perhaps never to be built: these seem to me to
>be analogous.

Precisely, and in bookkeeping this is called a "budget." Some of the budget 
will be over spent, and some will be under-spent. A budget that is 15% 
disbursed and 20% off of the estimates, is a powerful indicator of where 
the final costs will land. In my own experience, once computer feedback 
made budgeting worth the effort, accuracies within 1 or 2% became 
commonplace. If working professionals are doing the ball-park estimates, 
and no one is stealing the money when costs run under budget (a common 
practice) balancing yin versus yang is quite simple to accomplish.

>Yet there may be an important difference as well. It is possible, some of
>us claim, to produce software effectively and well by taking the most
>important story and shipping it.

Correct. This is the meat and bones of what electronic computing has made 
possible.

>No one claims that for a movie or a house.

I bet such claims are made for a soap opera:) Relative to houses, I can 
tell you that bringing the customer into the design of iterative 
construction cycles is much easier than you might be imagining.

>It may be that bookkeeping will one day help us address the comparison of
>those things. Today, to me, bookkeeping is just a word with an odd
>complement of o's and k's and e's. You keep inviting us in, but your home
>has no path from the street, and no visible door. Until those are built, I
>can't stop over to your place. Yet I still seem to be able to think about
>these ideas somewhat effectively. Maybe we should continue to deal with the
>ideas and let the bookkeeping happen when it's ready?

Sort of how previous generations of software developers did documentation, 
Ron? Bookkeeping will come into software by using the iterative model, just 
as XP has come into software using that model. You are doing bookkeeping 
now, but very badly. Just as software was been documented in the past, but 
very badly. No software problem is going to be solved with a sweep of the 
hand. When XP professionals turn to bookkeeping, they will do so in the 
same way that the electronic computational model has always been 
implemented, on a piecemeal basis.

Dan