Folded Zippered Process
Folded Zippered ProcessRenamed from "Folded Process" because I've seen processes that were folded but not zippered together, and they missed the key improvement, zippering. -- AlistairCockburn
In my travels, collecting ProjectManagementPatterns, I have run across some interesting ideas. ProcessMiniature is one, as exemplified by ExtremeHour. Most recently (April, 2000) I ran across my second instance of a FoldedZipperedProcess. -- AlistairCockburn
FoldedZipperedProcess is daring and non-intuitive to the new practitioner, wildly effective, and eventually becomes CommonSense to the practitioner, who can't understand why everyone else in the world is walking backwards instead of forwards (they ask the reverse question, of course). XP is an example. Since it was the first example, I didn't know what I was looking at. Just ran into my second example last weekend.
My brilliant friend Mho was hired to help a medical device team get their new product out the door faster - it was looking to be way late and over budget. He cut the time from over a year to 3 months, cutting the staff from 30 to 15 in the process. He thinks of himself as a process engineer, so he performed a pure process transformation. The product had to pass FDA regulations, so he did the unimaginable: he downloaded the FDA process and approval regulations into Excel, turned every sentence into a numbered requirement, converted to active verb form, and then asked: How would we show the FDA that this sentence was met?
He then constructed a process in which every move by the team fit some sentence in the regulations. Oddly, what it called for was to get the test and QA specialists in early - which he did. They generated requirements for the product that could easily be shown to meet FDA requirements. The architects, working with the QA people, took those as just more constraints on the design. Following the regulations, he also broke up all the departments (marketing, test, design, etc.) and mixed the people so they sat next to the people they had to coordinate with! There was more, he is really a polymath, so he did other brilliant things along the way to simplify their development (like tell them to buy chips from the video game industry instead of designing their own circuits). But this is the process change he made. Result: passing FDA was simple, since the entire process was directed to that goal. Communication was higher, etc., etc., etc.
What then is a FoldedZipperedProcess?
It is when you clearly identify the exit criteria, and put those early in the process, then run the process explicitly to meet the exit criteria.
I hope that by putting this note here, someone else will write in with another example of the FoldedZipperedProcess in practice. I am sure there are many, from all fields (I have run meetings this way, but we'll ignore that). --AlistairCockburn
We used to put our contract requirements onto a task list in Excel. Only tasks on the task list were done. New "whizbang ideas" got put onto a "future" task list that would be considered for the next contract. We did, however, add new tasks that fell out of the contract requirements, like engineering tasks and bug fixes. Is this kind of what you meant? There is also the notion of a UserStoryShield.
This is the process I use to write conference papers. First, I think of a place I'd like to visit, then I look for a conference being held there, then I think of an idea for a paper I could contribute, then I write and submit the paper, then I show the acceptance to my boss and say, "Can I go?"
This sounds like the story of the guy who started picking up women in the waiting room of a V.D. clinic. This enabled him to identify women who were:
I have it in my head that this is one of RichardFeynman's stories... is it?
Why is it called "folded"?
In the "normal" process, people put acceptance testing last, and hope they'll make it. Instead, fold the process sheet in half (think of the ValidationVee here), so that Acceptance Testing and Requirements coincide. Now zipper the V together... Acceptance Testing informs Requirements, and every testing or acceptance test is paired with its corresponding generating activity. The process only achieves its real effectiveness when the pairs are zippered together. Like XP's writing unit tests first then coding just that much. Like Mho's QA specs being part of the architectural requirements. He said that acceptance test was a non-event, because everyone's work had already all passed the tests before leaving the developers' hands.
Most incremental and iterative developments are really miniature waterfalls from requirements through design to test, even when using GoldRush and other overlapping processes. A FoldedZipperedProcess is different in how it uses the testing criteria.
If a FoldedZipperedProcess means
Whatever -- it works for me, in many different parts of my life.
-- DickBotting
I did something like this a while ago - while working on some code, I snaffled the test spec for it from the QA department, and spent some time making sure that it would pass the QA tests.
When I told people what I'd done, they looked at me like I'd cheated. I felt guilty for a while, too. XpGuilt strikes again!
Interesting about the feeling guilty part. Imagine - you actually designed the system so it would do what it was supposed to do!
I think this will work well in an XP context (where you test everything that could break) but might bite you in a less rigorous environment, or any BlackBoxTesting environment. These tests are often more like spot checks. The guilt you felt might be an indication that the tests weren't thorough enough. -- JeremyCromwell
This is probably too obvious to even rate a mention here - but maybe not. If you apply FoldedZipperedProcess, but lose view of the non-formal goals (i.e. that which achieving the exit criteria is an observable measure of), you will end up doing a form of MethodologyCargoCult.
For instance, consider the school years leading up to the Baccalaureat. (If you don't know what that is, you have just been the victim of a FrenchCulturalAssumption?. You probably call it a high school diploma.) The last year before is entirely and explicitly dedicated to getting as many pupils as possible in a shape to "meet the exit criteria", i.e. achieve the highest possible score in the end of year examination.
This would be fine, except that the year before that is also pretty much dedicated to getting pupils in shape to face the final year, and so on. The whole time I was in high school (your mileage may have varied), I couldn't help but think - "I thought I'd come here to learn things ?". As far as I could tell, high school was so concerned with "meeting the exit criteria" that it had completely punted on what should surely have been the primary goal - giving kids an education.
The problem is that when the "exit criteria" start to "drift", so to speak, you need to adjust the criteria, not the process.
Good point. Thanks for bringing it up.
That is very close to the managerial AntiPattern (or whatever) called "the folly of rewarding A, while hoping for B." Consider the case of the Soviet farm supervisor who was paid by the number of hectares planted. Instead of planting the grain 6cm deep, he ordered the workers to plant them at only 3cm, thus increasing the number of hectares planted from 4 to 10 per day. While the workers couldn't care less, the supervisor would be paid more and possibly even earn a bonus. Of course, come harvest, all the grain had died, but that was long after the cheques had been cashed.
On the other hand, when you don't worry about some artificial test like the Bac, but instead worry about what is necessary first, then you're going to do ok. Not ecstatically good, but at least you will avoid failure (maybe that is ecstatically good in software; after all, SoftwareIsReallyPointless).
Let's assume that there is some optimal set of steps O that will solve the problem in the given resource constraints for maximum value. Then, there must be some subset N of O that is the set of all necessary steps to solve the problem in the given resource constraints, but for sub-maximal value. Since you have to do N anyway, no matter what, if you do N first, you will guarantee success. Also, N has the added benefit of being much easier to know than O - N. Wasting time making guesses at what might be good may exhaust your resources prematurely.
Thus, stick with the obvious next step always. Avoid cleverness unless you can afford the risk of failure (and desire the chance of megarewards). -- SunirShah
I talked with Alistair about this after his talk at XpImmersionFive. He felt that the important part was the folding (matching requirements to design) and the zippering (automated testing to cement the match-up in place). I felt that the important part was delivering precisely what the requirements call for, and not a jot more. Thoughts? -- JohnBrewer
I agree with Alistair - the folding and zippering are vital, because without that, the process has a greater chance to degenerate into the linear process. Even in the typical linear process, there can be strict adherence to delivering precisely the spec (I have lived through one such case, where we had to deliver a feature that everyone knew was not going to be used, but the customer did not want removed for fear that opening the spec to revision would allow us to remove other features he did not want to lose.) So the folding, etc is more important, in my view. -- PeteHardie
EditText of this page
(last edited September 12, 2004)
or FindPage with title or text search