Patterns of Performance
dev team as a service
Process modeling in software development usually takes the product as the object of the model; there’s nothing wrong with that, as far as that goes, but rather than focus on what is being built, let’s explore the idea of how software is developed as a service.
Keeping in mind that a model is just a hypothesis, not an assertion of fact, let’s see if we can identify a small set of patterns that encompass the activities of a development team; just an exploration of the question.
Majid Iqbal proposes a spectrum of eight patterns which map the concepts to construct pretty much any service; four patterns for performance, and four for affordance.
The development team represents performance within a service, and we’ll focus on that aspect first. Performance patterns derive from the interplay between artifacts and capabilities.
The generic patterns are
- Examine-Evaluate
- Maintain-Protect
- Restore-Repair
- Transform-Translate
We’ll map the generics to the our domain context in the following way:
- Analysis and Estimation
- Technical Dept and Risk Management
- Bug Fixes and Remediation
- Feature Development
Now think about what the function and purpose of a dev team.
Certainly one of the things that the team has to do is to “Reducing fear, uncertainty or doubt about the condition or state of the artifact." That quote is from Majid’s proposal of the Examine-Evaluate pattern. We use the domain specific term “requirements” for the generic term “artifact”. Certainly this pattern is a key for any productive dev team.
Now consider the “Maintain-Protect” pattern: “Custodial care is part of the value proposition, as are low levels of ambient noise, disturbance and interference”, again, a quote from the generic pattern. The activities of a dev team that we attribute to risk management and technical debt fit nicely with this pattern. Stakeholders clammer for features, but they expect the Maintain-Protect aspect of the work to be handled as a matter of course.
“Restore-Repair” is an easy map to bug fixes and remediation. “The value comes from the artifact recovering or returning to its former self and resuming its role as an asset with few or no signs of damage." That expression certainly works well for the model of dev as a service.
Finally we have “Transform-Translate”, when we translate stories into code into releases, the releases are new artifacts. From the generic definition: “The translations create new artifacts that are themselves valuable. The value may depend not so much on the degree of difficulty but how profound the change." Again, I couldn’t express it any better than that. Transform-Translate is usually what is considered to be the primary function of the Dev team, often unfortunately at the expense of a healthy respect for the kinds of activities called for by the other patterns.
Most teams already make some kind of segmenting based on these and other attributes of work. Our purpose here is to see if this conception of service patterns can help reduce friction and realize higher throughput, by aligning the way we organize and schedule our work with the demands of all of the activities that need to be carried out.
If we accept that the function and purpose of a system is revealed through the observed behaviors, then all we’re doing with these patterns is setting some boundaries, to see if what’s actually going on from day to day maps to the patterns. If not, we could adapt the patterns to accomodate observation, or revise and reform behaviors to conform with the patterns. Either way, we should end up with less friction.
Remy Gieling — "Production line at the SodaStream factory in Israel"
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.