Focus And Invent

Copied from WardAtIbm ...

... IvarJacobson's methodology is one of inclusion, mine, exclusion. He assumes that one must forage for requirements and that the use case is the best basket for carrying them. When you've got your baskets filled, you can start organizing all that you've collected. Somewhere downstream in that process objects emerge. In other words, He suggests we CollectAndOrganize?.

I prefer to FocusAndInvent. I assume that sufficient wisdom and experience can be assembled in a room such that only a vague requirement is needed to get the process moving. A typical requirement goes something like: We need a better way to handle out-of-sequence endorsements. When everyone in the room knows what an endorsement is, and everyone also knows a hundred things that can go wrong when they are entered out of order, the problem is not one of collecting more information. The problem is one of progressively narrowing the focus of the group until the pieces of a solution fall into place, until invention happens.

---

This distinction sounds to me like a MyersBriggs conflict. It sounds like what happens when an NJ, who prefers to make a plan first, is reacting to an SP, who prefers to gather data, then make a plan. (I apologize if this sounds like amateur psychoanalysis; I am trying to describe a pattern, not to analyze any particular person.)

I pulled this out to a separate page, because it reminded me of a conflict I once had on a contract. We were building a large online help system. I wanted to build a few help screens, see how they worked, then design the system. My partner wanted to create a detailed design, then do some prototypes. We got really annoyed at one another before we realized that this was a type-conflict issue, not Right vs. Wrong; I'm a P, my partner is a J. After we'd figured that out, designing and delivering the help system was easy. (We solved the problem by doing prototypes both before and after the design.) --BetsyHanesPerry

---

The distinction I report was made clear to me when we alternated between the two methods. A colleague of mine at IBM facilitated UseCase(s) in the morning while I facilitated CrcCards in the afternoon. The client felt that use cases were more aligned with what they were supposed to do while the crc work got them excited and kept them going through the weeks. -- WardCunningham

---

Invention often is the result of a process initiated by "requirements". Ward pointed out the distinction of "facilitation", which is common in both approaches. When one is in the beginning phases of a development process, confusion and lack of focus is often preceded by emphasizing not solutions driven by needs, but process driven by approaches. There are in fact many facets to requirements, and the real possibility that what is initially a requirement may in later phases fade by being found to be less important, or in fact counter-productive to a "complete" solution. Facilitation is a method which will improve the "focus". What is important, is not necessarily the rank and order of possible solutions, but rather discovering what one may "focus" upon in the subsequent invention process. -- Donald Noyes 20070816

---

Related;

• PairThings

---

CategoryFocus