test objects design

As I am reading Robert Martin’s old Engineering Notebooks on Iterative and Incremental Development I came across a business argument, perhaps the best non-engineering argument of which I have many; against following Waterfall software methodology. You are welcome to download all his PDF docs from ObjectMentor’s site via this googleq:

The iterative process is producing data about the schedule. The completion times of the slices are giving us unambiguous empirical measurements that help us predict when the project will be complete. There is a wonderful thing that mangers can do with these measurements – with this data managers can… manage. They can stop dictating, stop motivating, stop losing control Don’t let this article mislead you. If you follow the advice above and begin developing projects in an iterative and incremental way, bluebirds will not fill your sky. Schedules will still be missed, there will still be bugs, problems, and mis-aligned expectations. Software is, after all, software; and software is hard. However, what you will be doing is using a process that produces data; whereas waterfall produces none. With that data, managers can try to manage the project. (…)a process that produces data can be managed. A process that does not produce data, cannot be managed.

I dig this argument: producing data about the schedule. I can see why in Scrum you should be keeping track of past Sprints and why you should be looking at how many backlog items are “YET TO BE DONE” and not DONE VERSUS PLANNED as happens to be the model in Waterfall. I think this is an important distinction. - In traditional Waterfalll you Plan what will be done with the assumptions that no changes will occur - but what if you can produce data everyday about how many items are yet to be done? how many are planned? you can calculate your running conversion, hence burndown chart, hence velocity as a measure of effectiveness.

I don’t have much experience with Scrum since most of my work has been on Test Design in what I would call Waterfallish type of project, however I must admit that my engineering process for Testing software has been iterative. I devised plans that were based in uncertainty but I never tracked data about my schedule, partly because I never designed it nor have never been on teams that designed it. Since Test Management is about repeatablitlity let me make a strong recommendation to myself and my team now to implement such a measure.

Would it be worth for a software development projects to transition from Management-Intensive Process-Heavy style of creating software to Management-Intensive Inventory-heavy style of creating software.
I have been in many meetings where things being discussed are mainly about how things are to be done. Everybody has something to say like “Well, I think they (meaning some team) should be doing it this way” or “I can’t believe they are doing it. Just lust week they were doing it some other way” and so on.

It seems most conversations are management talking about process and how they are following it and how come some others are not following it or should be following it.

In contrast I would like to envision the same style of Management Intensive style of meetings but instead of process I would like to introduce a new conversation about managing inventory: items to be done, impediments to clear or overcome, promises of actions to take, milestones with dates and measurable results. WARNING: when I say measurable results it is results about about inventory, stuff to get rid of, process into something else and add value to it.