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.

## Relationships

### 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[1] 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.

## References

1. ↑ http://www.svilendobrev.com/rabota/orgpat/OrgPatterns-patlets.html