As usual, it takes me multiple attempts to figure out what I really want to say, and how to express myself. Here’s a bit more discussion of what I believe is implied by downstream testing:
The very fact that downstream testing occurs, and is heavily consuming resources, means that management haven’t understood that such activity is waste. (If management had understand that, then they would re-organise the process and put the testing up front — prevention of defects, instead of detection.) No amount of tinkering with analysis or development will alter that management perception, and therefore the process will always be wasteful and low in quality. So the constraint to progress is management’s belief that downstream testing has value.
This week I’ve been reflecting on why it is that some “agile” teams seem to really fly, while others never seem to get out of second gear. Part of the answer, at least in the teams I’ve looked at, lies in the abilities of their testers. I wrote about the phenomenon over three years ago:
The tester in Team 1 was very good at his job, whereas the tester in Team 2 wasn’t. And as a result, the developers in Team 1 produced significantly poorer code than those in Team 2!
Have you seen this effect? What did you do to harness the skills of your great testers so that they constructively support your great coders?
Everywhere I go I find managers complaining that some team or other is short of staff; and (so far) that has always turned out to be a mirage.
TOC’s 5 Focusing Steps say that adding resources to the bottleneck is the last thing one should do. Before that, a much more cost-effective step is to “exploit” the bottleneck — ie. to try to ensure that bottleneck resources are only employed in adding value. So in the case where testing is the bottleneck, perhaps one should begin by ensuring that testers only work on high quality software; because testing something that will be rejected is waste.
And from the Lean Manufacturing camp, Shigeo Shingo (I think) said something along the lines of “testing to find defects is waste; testing to prevent defects is value”. Which seems to imply that waterfall-style testing after development is (almost) always waste.
Which in turn implies (to me at least) that testing in a waterfall process can never be the bottleneck. The bottleneck must be the policy that put those testers at that point in the flow. Does that sound reasonable to those of you who know a lot more about this kind of stuff than I do?
In Oracle Fusion half way done? Pete Behrens is astounded that Oracle can claim to have Fusion “halfway” done. Me too. In the eweek article that Pete refers to, Oracle president Charles Phillips said:
“The hardest part — the requirements — have been done”
I do hope they will be able to present a project retrospective at Waterfall 2006…
I’m proud to announce that my experience report “Lean Waterfalling the Toyota Way – using Fagan Inspections to Stop the Line” has been accepted for the Waterfall 2006 conference!
I’ve just been working with a team which has a pairing policy: every item of code must have been seen by two pairs of eyes before it can be checked in. It doesn’t work.
The effect of the policy is to replace pair programming – instead developers do a “pair check-in” at the end of each development episode. So a developer will beaver away working on a feature for a day or so, getting it right, making it work, passing all the tests. And then he’ll call over to another team member to request a “pair check-in”. The other team member comes to the developer’s station and is walked through the changes in the version control tool. And then the code is checked in and the two team members part company again.
The problem here is that the process sets the two people up to be in opposition: the developer is effectively asking for approval, instead of asking for help. It’s natural for the developer to feel a sense of ownership, because he’s worked hard to get that code complete and correct. Not many people can graciously accept negative feedback after all that hard work.
It can also be hard for the reviewer – the “second pair of eyes” – to come up to speed quickly enough. The developer knows these changes intimately, but the reviewer is being asked to understand them cold. He has little chance of being effective in that situation.
So this process has all of the demerits of Inspections, with none of the advantages. The team would be more effective adopting true pair programming, I feel.
This week I started on my first proper project here. I’m coming in just after the completion of the bid, which was accepted last week by the GoldOwner. My job is to set up the project and run it on behalf of the supplier organisation.
Interestingly, the said supplier organisation has quoted to run a classical waterfall project, but the GoldOwner wants it run “iteratively.” My bosses have told him that’s too risky, and that we’ll stick to falling water, thank-you-very-much. I, on the other hand, told him we’ll do it iteratively. I suspect my tenure here may be short-lived…
Here’s a conflict cloud expressing the issue I have here: