The Pattern Language
This pattern language offers patterns to strengthen and tune an organization using feedback and insight. It is essentially a process of repair. Here are the patterns and their connections to each other:
Note, perhaps surprisingly, that none of these patterns have fundamental ties to software development. They are applicable to any design activity: any activity where a group of people is building something to solve a problem. They are equally applicable to software services as to building product; to hardware development as to software development. They are patterns about human nature and human organizations, about the ways that people come together to solve problems.
A Story About Piecemeal Growth
When I started to plan the Q project, I wanted small core team of architects, so I employed SizeTheOrganization with an eye to PhasingItIn through ApprenticeShip with other staff later on. The project was too large for a SoloVirtuoso approach -- though we would use that pattern later to flesh out a prototype. I put forward the opportunity and made it possible for people to sign up; there was no corporate or management compunction to join. Hence, it was a purely SelfSelectingTeam, started as a SkunkWorks under management radar.
My main job as project coordinator was to put up the FireWalls to management until we had our act together. But my second job was to make sure we got a good group of people to the end of HolisticDiversity. We brought in Lalita for her work in scripting languages and their environments; Peter for his architectural expertise. Later we decided we needed market domain knowledge, and that's when we brought on Jim and Beki in the interest of having DomainExpertiseInRoles. The recruitment strategy was always one of ferreting out matches of interest that would excite the players, amplified by the new nature and somewhat subversive approach of the opportunity. Team pride was an emergent property of this process. We also had our own value system and model of rewards: all team members would share credit for any patents that were issued, and we would seize a leadership role in the organization. We also knew we were catering to the organization's product interests, and that would be rewarded: CompensateSuccess.
Beki served as the GateKeeper, bringing in ideas from the AOL Instant Messenger world, interviewing (child!) users of the system, and bringing in knowledge of the organization and market opportunities. She and I split duties of PublicCharacter and MatronRole.
We moved forward on design using CRC cards to formulate an architecture, employing ScenariosDefineProblem and GroupValidation. The goal was to get the project "running" on CRC cards and then to implement a first, simple cut in a one- or two-day programming session, all together in one room, doing DevelopingInPairs. The CRC cards were given to individuals best suited to those areas, exemplifying both DomainExpertiseInRoles and, to the degree one could talk about subsystems at that point, SubsystemBySkill.
At our (frequent) meetings we made sure that work was spread around evenly. We did most things in a group to make sure that the specialization didn't get out of hand. We occasionally traded off CRC cards, all in the interest of having a ModerateTruckNumber.
At some point in the process, people felt that the CRC cards weren't enough and that we needed to document the scenarios. We used ping-pong diagrams to do this, first on whiteboards, then using a formal documentation tool (ScenariosDefineProblem). But this was done in a SacrificeOnePerson mentality, shades of MercenaryAnalyst (we were too small to enlist a full fledged MercenaryAnalyst, but we faked it).
Lalita went away as a SoloVirtuoso to BuildPrototypes. The prototype ended not being terribly gee-whiz and it failed to energize the team to take the next steps forward, and things came to an impasse, particularly in light of competing priorities on other development projects.
Dysfunction struck the organization in the untimely departure of Beki and Peter from the project, and afterwards, in Lalita's promotion out of the project. Jim took the ideas forward into another project but took no other people with him. We did not have a FailedProjectWake — perhaps we should have. We didn't get so far as to run the development exercise as a team in a room, at which point InterruptsUnjamBlocking and DontInterruptAnInterrupt would have become important.