Re: Re: SIP is not Takt Time

Hi Ron

> > 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.
>
>Yes, I'm sure we all agree with that.

Good, this is a place to begin. Kent's proposed goal to "make SIP 
money-oriented" gives us a real problem space in which to define a 
bookkeeping model. We can define a solution on a theoretical basis. 
Bookkeeping records its history from the perspective of an entity. Ken 
describes programmers contributing to a supercomputer company and being 
concerned about their paychecks clearing the bank. The supercomuter company 
is one entity perspective and the programmers contracted to generated the 
saleable code is another entity perspective.

I propose a model where an XP team of programmers has been contracted to 
complete stories for a program the supercomputer company (SCC) is selling 
to the public. Bookkeeping is recorded from one entity perspective. The 
entity I suggest that we create the bookkeeping model from is the XP Team 
(XPT). XPT has a contract with SCC to deliver a new iteration once a month. 
The next issue is how XPT will be paid for portions of the contract, so 
that XPT can pay its expenses and payroll.

In order to do bookkeeping XPT must form a business entity of a particular 
type. The type of entity decides who makes the rules. For example, if Kent 
formed a proprietorship Kent would hire the programmers and control the 
business rules. In a partnership, partners would work out an agreement 
telling how entity's rules are to be decided. In a corporation equity 
owners make the rules. An LLC (legal liability company) is a partnership 
with the benefit of a corporate shield, where partners make rules, again 
subject to a constitution, as operating agreement.

Laying out a business pattern is the first step in creating a bookkeeping 
application. Every recorded transaction depends upon the underlying 
business model.

To fulfill Kent's wish control valid paychecks he, or the team, must have 
control of the billing and payment cycles. This is usually controlled 
through a contract with the customer. I recommend we use the LLC pattern as 
the theory model of ownership. The XPT members will own their entity, and 
make the rules by which their bookkeeping history will be recorded.

> > 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.
>
>Yes, I'm sure we would find that.

I will pass over this now, but when a well formed bookkeeping plan gives a 
team the power to control the balance of expenditure it becomes the 
professional craft persons best friend. Most present bookkeeping 
applications hide facts from workers in the interest of undeserved 
administrators. (Polite words for "Thieves.")

> > The bookkeeping pattern, you will learn, is identical to the issue of
> > documentation.
>
>Identical? Are you sure it's identical? I know a lot about documentation.
>Does that mean that I know a lot about bookkeeping?

Yes, in fact, it does. Bookkeeping is documentation. And so, yes, you do 
know a lot about bookkeeping.

I break the bookkeeping document into four categories: (1) the individual 
contributors to each contract, typical of a programmer negotiating a rate 
of pay and responsible for documenting where that individual's contracted 
time has been contributed on the company's behalf, via the timesheet; (2) 
coordinator is a person (one or less per team[s]) who validates the coding 
of  individual contributions typical found in the book of memorandum; (3) 
administrator is the accounting level person who manages the financial 
aspect of contract relations by managing journal of data company wide; (4) 
policy group is concerned with the technical language issues that guarantee 
that the bookkeeping framework will always scale to the needs of XPT.

When you want to know more about a particular category of the bookkeeping 
document we can talk about each individually as the differences are quite 
distinct. And not everyone will want to invest the time to know them all.

> > 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.
>
>Oh ... I guess you meant "analogous", not "identical" ...

In fact I did mean identical. I am pleased to have this opportunity to 
clarify my beliefs.

> > 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.
>
>Actually, probably not. Knowledge and power are, in my experience, almost
>independent variables.

You might feel differently once you see the two brought together with 
accurate accountability. In the past few years of bringing my building work 
into the pattern of iterative design, typical of XP, and greatly helped by 
reading the XP list, I have found that in knowing precise details about 
quality and their accurate cost has put my relation to my customer into an 
extremely powerful position. The relation has become a genuine friendship, 
something unheard of in the past.

Craft people, and I'm sure this is true for programmers, are not the 
dreamers that marketing and sales teams often are when setting budgets. 
Customers like budgets that work. They also like to know that an 
opportunity to increase scope in order to capitalize on unforeseen 
possibilities of adding value is being treated fairly. There are huge 
issues here that come out of experience alone.

> > 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."
>
>But Dan. The people in question didn't know bookkeeping. They didn't use
>bookkeeping. They knew the number of days receivables stayed outstanding,
>and why.

Understood. My argument is that they are better positioned to deal fairly 
with documented facts than venture capitalists, equity bankers, and the 
rest of the people who are now in exclusive administrative control. 
Administration today, you will learn, is not being practiced fairly and 
everyone involved is being hurt by the error in the administration's ways.

> > 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.
>
>I am so sure of that. I keep hoping that you'll quit selling the
>bookkeeping product and deliver a demo copy.

There is no demo copy. Bookkeeping documents what really happened--a 
history. The best we can do is create a speculative model to decide whether 
an XPT could and should be formed. What the four levels of documentation do 
in my own framework is take time contributed on timesheets and convert it 
into actual $ drawn from the contract, or contracts. It is done the way all 
bookkeeping is done, except that in my case I can differentiate entity 
interests within entity interests, teams within teams, to almost any degree 
of detail This is not possible in the bookkeeping link Oli provided.

http://www.accounting-and-bookkeeping-tips.com/learning-accounting/accounting-basics-credit.htm

I don't know of a way to teach you how my model differs from their's except 
by creating at least a speculative example.

>I am really sure that a product vision is not a budget. I am really sure
>that a movie storyboard is not a budget. I am really sure that a sketch of
>a new building is not a budget for its production. A budget is a low-level
>list of items and costs, probably in time and dollars, perhaps laid against
>the calendar or perhaps just as a list. The budget is a particular detailed
>view, not of the movie, but of the potential making of the movie. I
>wouldn't go to the theater to see a budget.

Once a team tracks a detailed history, you might be pleasantly surprised by 
how helpful actual expenditures are in forecasting the financial 
possibilities essential to achieving a next order dream for your team. 
Setting a budget is the first order of business in every building contract 
I do, regardless of what the customer dreams may be. If I can't agree on a 
reasonable budget then I know that I am wasting valuable time. Budgets in a 
happy life have become extremely important to me.

>Are you suggesting that you can come over to my house, install one cabinet
>in my kitchen, and smoothly transition me to a complete, well-organized,
>beautiful kitchen? I /am/ suggesting that we can do the equivalent in
>software.

Did I say somewhere that software is a kitchen ? :)

>Implement one ******* bookkeeping story for me, Dan. Just one. Please quit
>selling and start installing.

If what I have said above is of no help toward that end, then let me know 
and I will sign off.

Dan