Re: "Bah! Scrumbug!" (Lessons from the scrap-bin)

Scrum actually addresses this. It's called a burn down chart. Every day, the team estimates how much work in the current sprint needs to be done (expressed in some unit). An easy way to do this is to sum the estimates of the tasks that haven't been started and to add to this the partials of the tasks in progress. Estimates on tasks may be adjusted. New tasks (but no new user stories) may be added. Tasks may even disappear. At the end of the sprint, the team looks back. It will also look at the burn-down chart. If it doesn't look "normal", you're supposed to adjust your way of working. Note also that the burn-down chart estimates miles to destination, and specifically not miles run over the sea. (the latter is too trivial to measure, it's the average number of work units/per day/per person x length of sprint so far (in days) x number of team members). But I bet you know all of this.

“we’ll meet for exactly fifteen minutes, then we’re going to spend the rest of the day cutting metal, because cutting metal is what we do!”

I fail to see the point of this remark. If you think that scrum advocates to have a 15 minute meeting at the beginning of the day, and no communication (and just code) for the rest of the day, you're mistaken.

Perhaps the “scrap rate” is the actual metric that we should be infatuating about. And we might be able to obtain such a metric right from our version-control system logs. Look at the total “surface area” of a source-file that gets changed over time. Particularly observe when a large chunk of code is first added, then either replaced or extensively modified a short time later. If there is a defect-tracking system, try to correlate this “source-code volatility metric” with those defects. Do the same thing with the activity that is being generated by the “scrums.”

Wrong on different points. First of all, bits aren't a precious commodity. Code is cheap. It doesn't involve tons of rock and dirt to be moved and crushed to extract a few fragments of ore. A small error doesn't mean a days work is scrapped and we'll have to start all over again. Even code that is written, tested, and then discarded has value: we have learned something (this feature isn't "working" - where "working" typically means "making money for the company").

Once again, I want to remind the reader I'm not advocating scrum. But I think it's being misrepresented, and I don't think the "scrap metal" analogy is valid.

Comment on Re: "Bah! Scrumbug!" (Lessons from the scrap-bin)

Replies are listed 'Best First'.
Re^2: "Bah! Scrumbug!" (Lessons from the scrap-bin) by locked_user sundialsvc4 (Abbot) on Dec 15, 2010 at 17:58 UTC
Bits aren't a precious commodity. Code is cheap. It doesn't involve tons of rock and dirt to be moved and crushed to extract a few fragments of ore. A small error doesn't mean a days work is scrapped and we'll have to start all over again. Even code that is written, tested, and then discarded has value: we have learned something (this feature isn't "working" - where "working" typically means "making money for the company") It is truly impossible for me to dis-agree with that comment more vociferously than I do. “Bits,” as you call them, are in fact one of the most-expensive work products that exist. And sloppy business practices are one of the big reasons why. What would you think about a building contractor who showed up with his crew and started furiously cutting boards and nailing them up and, about half an hour later, the foreman walked over to you and said, “now, what exactly do you want to build here?” Let’s say that you do not grab the nearest two-by-four and club the guy, as he so richly deserves to be clubbed. Let’s say, instead, that you play along (“he’s an expert, after all”), and so you tell him. And so he tells his men to rip down all the stuff they’re building and to put up something else, instead. Which they promptly do, with just as much energy as before. The foreman points at the pile of broken wood and says, “but it has value. It was a good learning experience. My boys just learned something...” You suddenly put two-and-two together. He’s expecting you to pay for all of that wasted wood! Are you grabbing for that two-by-four now? You should be. And yet, here we are, telling upper management types that they should be paying whatever bill we send them, “because we are obviously so busy.” I can tell you a business practice that works, because I have done it for years: You will start by signing an eight-page contract. Everything that is done, is done under the auspices of a “task order” which is part of the contract. “Task #1” consists of “creating Tasks #2-n.” You will pay for this service. In fact, you should not be alarmed if several specification-tasks are conducted, possibly consuming one-third to one-half of the project’s contemplated costs, before any code is written by anyone anywhere. A definite price will be attached to each task-order; 50% down, 50% on completion. Acceptance of one task order does not obligate acceptance of any other. The terms must be mutually acceptable to both parties. If you change your mind ... that’s a new task-order that amends the first, and we don’t have to consent to it. You are interested in the results obtained, not where the work is done or exactly how the work is done. “Results will be obtained” only after (you pay for...) a very rigorous definition of what those “results” shall be. And you will do that, and we will compel you to do that, because . . . The completed work is guaranteed against defects in workmanship for a period of 30 days following delivery. If any defect against the stated task-order specifications is found, you do not pay for the direct costs of the remedy. I contract for all sorts of services under similar terms put forth by the professionals that I deal with. In fact, I really do not choose to deal with anyone who does not pursue their business with such rigor. I have waited in line for weeks to have work done by those trustworthy contractors, and I will continue to do so. I have a careful file of business cards, and plenty of extras. The expectations of internal and external business customers are no different. A single computer programmer, within a team of dozens, might represent a capital outlay of several thousand US Dollars a week, as that person pursues a mission critical undertaking. “Code is cheap?!?!”
Re^3: "Bah! Scrumbug!" (Lessons from the scrap-bin) by chromatic (Archbishop) on Dec 15, 2010 at 19:13 UTC
What would you think about a building contractor... Having worked in both construction and software, I can tell you that construction is more like software than software should be like some mythical view of construction that doesn't actually work in practice, either. Q: What do you call a construction project where the crew shows up on the first Monday morning at 7 am to a two-inch pile of change requests? A: Normal.	[reply]