I have never seen this problem solved. The only way, in my opinion, to make this work is to do as little as possible. But firstly, lets see why we need estimation:

The only valid reason for doing this is to give Business an indication of how much the product is going to cost them. Its for an investment decision and of course the variation in estimates has a huge impact on ROI. What makes it tricky is that an estimate is most accurate when there are no unknowns. Practically this is impossible. The more complex the project, the more unknowns there are.

(for tracking purposes I have seen PMs ask developers to break a story into tasks and then provide estimates for that. This is waste, in my experience)

We can’t hold engineering to a number if we don’t provide sufficient details to them.

If we try to pound this problem to submission we might ask Business to spend months in clearly articulating what they need. The costs associated with this is fairly clear. Every day you spend in pushing your product out to market, is a day you waste in earning revenue, a day you allow a competitor to go a step ahead and a day you spend in not changing your mind.

Its not uncommon to have people spend 6 months and more in trying to nail the requirements down. No technology or tool will help you do this better to the extent that you can make this go away.

My experience is that in most projects that I have been, ROI is not really calculated in detail. Most projects start as a Go and then are scrapped midway. This problem is a different one.

Agile with its iterative development tries to solve this in a multi-pronged approach. If we were to break the project into features and then stories, we might be able to provide a relative estimate (points vs hours) at a high-level and elicit sufficient interest to start. As each iteration goes by, the team’s velocity is measured and can be used to project dates when features can be released.

Business can prioritize features and stories so that they get the biggest bang for their buck. Business can also freely change their minds.

With an experienced, talented, sincere team in place (all three are requirements for agile to work) its a fair assumption that velocity will go up, and that the team will do their best. With the teams I have worked on, the meaning of doing their best is really taking on more work mid-sprint even if they pass their historic velocity numbers. “We need more stories” is beautiful to listen to. You do that a few times and velocity is no longer that important as a metric. Maybe it is for releases, but most definitely not to showcase your excellence.

In terms of effort spent into estimating, you really dont want 7 developers 2 hours every 2 weeks. Thats $3000 at $200 an hour. If you remember that an estimate is not held against a developer, maybe even a couple of them can run through this list on behalf of others.

I am aware of the many reasons for making it more rigorous. I have tried that and I don’t think its worth the effort. I might change my mind, but till then, let me enjoy some lightweight estimation.

In short:

1. Keep it simple (no multipliers) and high-level
2. Like there is no perfect story, there is no perfect estimate
3. An estimate is best used to figure out when the features will release
4. An experienced, talented, sincere team will quell any fears of underwork
5. Historical velocity is the best indicator of future velocity

Whenever I quote from books, or at times copy passages whole, I do it with a great degree of trepidation. I feel I lack original thinking. Actually this might be more than a feeling. I felt a lot better after reading this:

“Nothing has been said that was not said previously by somebody else who themselves did not say it first”

I picked up the Learning To See book by the Lean Institute, authored by Mike Rother and John Shook. This book was a Shingo Prize recipient.

“A value stream is all the actions currently required to bring the product through the main flows essential to every product” including “design flow” and “production flow”; this book focuses on the latter.

Material flow and information flow are what needs to be mapped. Material flow is self explanatory, but information flow is what tells each process what to do next.

Some lean measurements:

Cycle Time: How often a part or product actually is completed by a process

Value Creating Time: Time of those work elements that actually transform the product in a way that the customer is willing to pay for

Lead Time: The time is takes one piece to move all the way through a process from start to finish

From a software development perspective, its probably wrong to use stories to draw the value-stream map if a story by itself doesnt add value.

In general the book is useful for someone who needs to be on the factory floor. It tutors you indepth on Value Stream Analysis. Useful, not so much for me, at the moment . . .

Quoting Deming:

14 points for management for the transformation of American industry

1. Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs.

2. Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change

3. Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.

4. End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust.

5. Improve constantly and forever the system of production and service, to improve quality and productivity, and thus decrease costs.

6. Institute training on the job.

7. Institute leadership. The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of overhaul, as well as supervision of production workers.

8. Drive out fear, so that everyone may work effectively for the company.

9. Break down barriers between departments

10. Eliminate slogans, exhortations, and targets for the workforce asking for zero defects and new levels of productivity.

11a. Eliminate work standards (quotas)

11b. Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.

12a Remove barriers that rob the hourly worker os his right to pride of workmanship.

12b Remove barriers that rob people in management and in engineering the right to price of workmanship. This means, inter alia, abolishment of the annual or merit rating and management by objective.

13. Institute a vigorous program of education and self improvement.

14. Put everybody in the company to work to accomplish this transformation. The transformation is everybody’s job.

I started reading Out of Crisis. Its an incredible book, whose ideas are pretty much neglected by business (or so I think)

“Why is it that productivity increases as quality improves?”

Less Rework

“What is the world’s most underdeveloped nation?”

With the storehouse of skills and knowledge contained in its millions of unemployed, and with even more appalling underuse, misuse and abuse of skills and knowledge in its army of employed people in all ranks in all industries, The United States may be the most underdeveloped nation in the world.

Matt Buckland has an interesting post on salaries, and if they ought to be publicized. When I first read Maverick, I thought it was a good idea. This was ten years back.

Thinking about this problem, my comment was that the solution that people ask for, i.e. publicizing salaries might not be the right one. And this is because the problem is sometimes forgotten, in my opinion. Why do people ask for salaries to be made public in a company?

1. Its difficult to know what an individual is worth.

This is easier in consulting because if I were billing at $100 an hour the absolute maximum I could earn would be $100 X 2000 or whatever. Unless of course  I was adding value beyond that. But consulting is sort of like a pyramid scheme. You can’t afford to pay some people huge salaries unless you are paying others small ones.

2. Many organizations have people who are perceived to not add value, but they earn a lot of money

As a company grows, this is inevitable. But its also unfair. Making work transparent (using wall reports, with story cards) provides a good indication on what an individual has achieved. There is usually a lot of reluctance to adopt these simple techniques by management for their work.

3. Many organizations don’t take the effort to ensure that there aren’t huge variations in salary within a range

As part of the annual raise it is quite important that we take a look at people’s salaries and make sure there aren’t huge variations. You can’t penalize someone for staying in your company. Newcomers tend to be paid more.

4. Many organizations don’t take the effort to ensure that there aren’t huge variations in salary between the highest paying and the lowest paying employees

There’s something perverse about one person earning 200 times another. But thats just me.

5. The person with the best negotiation skills tend to earn more

Some people are good at it and others aren’t. If an organization keeps this in mind when recruiting, it helps solve some problems. I once was asked what my expectations were and I responded that I was looking for something equitable. I was offered a salary less than what I was earning!

My contention is that the call to publicize salaries will be muted if an organization understands the above problems and works hard at it.

But should salaries be made known to others in the company? There are many firms that run perfectly well by doing this. It works well in some industries than others.

Its easier in manufacturing than in consulting.

Its more complicated in consulting because your salary is tied to what you bring in, sort of.  For the non-billable resources, how do we determine their value? If you aren’t paid what you bring in where does the rest of the money go? If you get a raise every year, and your billing rates don’t go up, does the company lose an incentive to keep you? Does the company hire cheap labour to offset your cost? Does it make sense to manage a consulting firm the same way you would a manufacturing or a product firm?

I used to have this habit of buying books and then not reading them. I vowed not to buy anymore, but to borrow from the library. The Woodbridge Library isnt that great; I sort of need to get books on an inter-library loan, especially some non-fictions ones. And I got into the habit of using coins collected in a bottle (my father says its about $75 worth when full) to order for books. There’s a childish pleasure in this that can’t be explained.

I plan to ask Smitha to get me some books too.

Here’s what I got:

Maverick: The Success Story Behind the World’s Most Unusual Workplace

(i lost a copy that I had, its out of print)

Breaking the Constraints to World-Class Performance

A New Kind of Science

Out of the Crisis

Against the Gods: The Remarkable Story of Risk

And what I want to get:

Godel, Escher, Bach: An Eternal Golden Braid

(i tried reading this and it was a mighty tough read, which means i didnt read it)

The Pencil: A History of Design and Circumstance

The Soul Of A New Machine

The Making of the Atomic Bomb

Longitude: The True Story of a Lone Genius Who Solved the Greatest Scientific Problem of His Time

We-think: The Power of Mass Creativity

Some of them were forwarded to me by Tom from this IEEE list.

So many books to not read . . .

My understanding, which could be wrong of course, is that to have kanban in place, you need to have stories that are similar sized.

Is this right?

It takes a lot of effort to size stories like so. I wonder if the “talented” developers will get bored with such an approach.

I tried to watch a few infoq presentations from Agile 2008. I’ve watched Tim Mackinnon’s presentation and then Dave Anderson’s. Dave’s was fiesty in his discussion of Agile vs. Lean and it makes one think that there is some pushback for Lean in the Agile community. Dave spoke about Agile and CMMi and how we can scale Agile to the enterprise. Suggests that Lean is a way of doing this. He also says “Re-use will drive the next wave of lean productivity improvements and enable the next wave of fast response development methods that power business agility”. Hmmm. Re-use and lean. Like re-use and OOP? A bit sceptical of that I am.

He says that businesses wont be able to get the talent that gains a firm the productivity they need, but “10 X improvement through re-use”?

Hard to buy that . . .

Jeff Sutherland gave a talk at google yesterday. The title “Self-Organization: The Secret Sauce for Improving your Scrum team” was alluring. The talk failed to live up to the title. In his slides he failed to talk about self-organizing and its implications. He stuck to an account of how Scrum was implemented at myspace by Scott Downey.

The three themes he spoke about:

1. Shock therapy as a strategy for booting up teams.
2. The Cosmic Stopping Problem, otherwise known as the choice uncertainty principle.
3. Punctuated equilibrium - how software systems evolve.

The first one "shock therapy" was interesting but not new. The second and third was to me addition of unnecessary jargon into already overloaded profession. Google should have the video up soon, I will update this page as soon as I see it. 

I would have like to have seen something more about self-organizing teams.