begin quoting Lan Barnes as of Fri, Feb 16, 2007 at 11:13:12AM -0800: > This is almost an "Ask Slashdot" post, except I think this list has more > wisdom. > > I'm doing a lot of professional reading on my own that is challenging my > core beliefs. I'm trying to be open and less judgemental, looking for > what's good in different current movements. But this leads to dichotomies > -- pieces that don't seem to fit together. Like trying to make Maxwell, > quantum theory, and relativity all play nice. Or something ...
The advantage of Maxell, quantum theory, and relativity, is that there's a working reference implementation staring you in the face. :) > So here is my quandry. On the one hand I'm reading a lot about six sigma > and quality processes like IEEE 828 (SCM). On the other, I'm reading about > SCRUM and other agile processes. > > At their best, these should (I would think) be able to coexist. But as > usually practiced, standards and processes degenerate into rigid > constrictions, and agile techniques collapse into uncontrolled chaos. I think you have the tail of something important here... You've summed up my objection to "process" and my fears of "agile programming", and phrased it wonderfully well. > So how can these things be made to work together? Specifically with SCM, > can self-directed teams be trusted to honor the imperatives of > traceability, repeatability, and accountability? How do self-directed > teams fare in a regulated environment where a government auditor might > demand a path connecting requirements through issue tracking to code > changes and on through to testing and resolution (more code changes)? As a friend of mine says: Hire good people. In the case of trying to blend with, say, XP, I'd say that you'd want your coach to be someone with strong beliefs in the importance of the benefits of "process", and who would have the ability to spend their time making sure the path you describe is recorded, without dumping a load of useless overhead on the whole team. (I bring up XP as that's the agile method I've read most about, and the "task card" model just seems like the obvious place to hook in to the traceability requirements or a more formal process system.) Unfortunately, this often is dismissed as "requiring heroes". :( > Does anyone have any experience in a shop where these things coexisted > without abuse? Is there a book, a guru, a discipline that blends these > impulses? My experience with process-oriented projects is that they get rigid and produce voluminious crap, and non-process-oriented projects either fall into chaos, or rise up to the challenge to deliver something worthwhile, but probably not repeatable in the sense of "can hand off to a team of mediocre programmers and expect anything nearly as good". I'd be very interested in a shop where these things could be combined without abuse. :) -- The big problem with process is the people who see *it* as the goal above all else; the problem without is the people who use it as an excuse for sloppiness. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
