Wiki Pages About Say What You Do

Describing what you really do is really difficult.

Say What You Do (Have Quality Procedures)
Do What You Say (Follow the Procedures)
Record What You Did (Keep Quality Records)
Prove It (Check the Results)
Improve It (Act on the Differences)

1) Initial. The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics.

2) Repeatable. Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.

3) Defined. The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software.

4) Managed. Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.

5) Optimizing. Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.

(from http://www.xprogramming.com/Practices/justrule.htm, written by Ron Jeffries)

XP, to the extent that there is such a thing, doesn't say "Do it My Way or Get Out". Quite the contrary ... the XP-like rules we use on C3 are rules the Team chose to live by, and the Team says "Do it OUR way, or get out". And within the team's rules, there is individual variation. In some areas (you will write unit tests, you will run the unit tests before releasing), there is very little variation. In others, there's more. But there's never much because the team has an internal social contract to do it the way we do it.

This is the way of it: the rules expressed so strongly here aren't my rules or Kent's rules. They are the rules that the team embraces. We do require everyone to follow them, because we believe that they make us more effective. When the situation changes, or we get a better idea, we discuss possible changes and often change the rules. After all, "They're just rules" is one of our rules.

A friend from an organization that is ISO 9000 certified tells me that what they really do is to write down what they think they should do in a notebook, then put the notebook on the shelf and ignore it, until just before the auditors' next visit.

One of the worst places I ever worked and another which was one of the best places I ever worked were both IS0 certified. The difference was that best place practiced what they described as process, while the worst place selectively and arbitrarily ignored and continualy invented new and ineffective ways to do things different from what they described as process. The turnover at the worst place was high, the turnover at the best place was low. There was much overtime at the worst place and 40 hour weeks at the best. This is proof in the putting that it is best to Do what you Say. -- DonaldNoyes 200080106

I once discussed the CMM with a 65-year-old aerospace engineer who had worked on software for the Apollo missions. He told me that in his opinion, the CMM was backwards.

How about...

Initial
Optimizing
Managed
Repeatable
Defined

I can't remember his exact explanation, but I'm guessing it went something like this:

The first thing you need is an ad hoc process. The second thing you need is a way to improve your process. Then you need a way to judge your improvements. Once you have these, your process will get better. When your process is good enough, it will start being used by others. When enough people use it, you can observe what they are all doing and write it down on paper.

If you don't use continuous improvement to get to your process, you have to do big design up front to get to your process. If you do this, chances are the process won't be usable, and will just sit on the shelf in a notebook.

In other words, you have to figure out the process first, by trial and error, before you can write it down. (And then it will sit on the shelf in a notebook, or will be hidden in the source code which will be lost. Personally I prefer things which are visible and organized. Even if that means a ThreeRingBinder.)

CategoryManufacturing