Developer Controls Process

If you need to orchestrate the activities of a given location or feature, then put the developer role in control of the succession of activities. undefined

To be applied before

 * Developer Controls Process is based on Build Prototypes.
 * Community Of Trust provides a foundation for Developer Controls Process.
 * continued Informal Labor Plan leads to Developer Controls Process.

To be applied after

 * Developer Controls Process provides possible context for Programming Episode.
 * successful application of Developer Controls Process makes Work Flows Inward possible.

Alternatives

 * Developer Controls Process should be balanced with Mercenary Analyst.

Contents of following sections belong to the original Organizational Patterns website and have been divided into following parts: Context, Problem, Solution, Discussion.

Context
...an organization has come together to build software for a new market in an immature domain, or in a domain which is unfamiliar to the development team. Progress will be marked by an Informal Labor Plan. The necessary roles have been defined and initially staffed.

Problem
A development culture, like any culture, can benefit from recognizing a focal point of project direction and communication. Successful organizations work in an organic way with a minimum of centralized control. Yet there are important points of focus, embodied in roles, that tie together the ideas, requirements, and constraints into an artifact ready for testing, packaging, marketing, and delivery.

Totalitarian control is viewed by most development teams as a draconian measure. The right information must flow through the right roles. You need to support information flow across analysis, design, and implementation.

Because developers contribute directly to the end-user-visible artifact, they are in the best position to take accountability for the product. Of all roles, they have the largest stake in the largest number of phases of product development. And there should be no accountability without control. The manager role has some accountability as well, to the extent that it indirectly supports delivery of the user-visible artifacts. These are process issues.

Solution
Make the developer the focal point of process information. Place the developer role at a hub of the process for a given feature, in the spirit of Organization Follows Market. A feature is a unit of system functionality (implemented largely in software) that can be separately marketed, and for which customers are willing to pay. Responsibilities of developers include understanding requirements, reviewing the solution structure and algorithm with peers, building the implementation, and unit testing.

The developer is central to all activities of this end-to-end software development process.

Note that other hubs, such as the manager role, may exist as well, though they are less central than the developer.

Discussion
The developer should be at the communication hub of whatever process engages them in writing code for the customer. This pattern encourages a structure that supports its prime information consumer. The developer can be moved toward the center of the process using patterns Work Flows Inward and Move Responsibilities. Though developer should be a key role, care must be taken not to overburden it. This pattern should be balanced with Mercenary Analyst, Fire Walls, Gate Keeper, and more general load-balancing patterns like Hallway Chatter, Responsibilities Engage, and Move Responsibilities. Conflicts can be escalated to the Patron Role when consensus breaks down and the developer should enjoy particularly strong support from the Patron Role.

If the developer controls the process, then it’s possible to have Work Flows Inward.

Developers of course don’t “control” the process unilaterally, but as a collective group, starting with Developing In Pairs.

We have no role called designer because design is really the whole task. Managers fill a supporting role; empirically, they are rarely seen to control a process except during crises. While the developer controls the process, the architect controls the product. This communication is particularly important in domains that are not well understood, so that iteration can take place to explore the domain with the customer.

In a mature domain, consider Hub Spoke And Rim as an alternative.

You can still write down your process as part of a process improvement program. But keep the documentation light; many organizations have found that one page per process is good enough. And make sure each process step meets a need that you can tie to your organization’s value proposition. Most often, this value is or should be tied to the product you are producing for a paying customer. If it isn’t obvious how the process step helps achieve what you know the customer wants, the do the right thing instead.