Skill Sets, Flow, and Transformation

I’m going to repeat a mistake I often make, and harp on a word choice. I’m aware of the risks. The word of the day is: Developer.

This quote from Angie Jones, in a TechBeacon article, illustrates the problematic use of the word: “To become an automation engineer you had to possess the skill set of a developer and the mindset of a tester.”

I might re-phrase that to say “skill set of a programmer and mindset of a tester.” Why? Because IMO a “developer” is a person who has the skill sets and mindsets of a programmer, tester, and analyst. If your team has developers – I mean real ones, with the full range of skills and the ability to “change hats” at will – then you don’t need separate sets of individuals called “testers” and “analysts.”

And you definitely don’t need people who just sling code without thinking about what they’re doing, and without testing as they go.

Confusing the Parts for the Whole

I’m not picking on Angie. This is common usage. I don’t like the common usage. To say “skill set of a developer and mindset of a tester” is a synecdoche: A comparison of two things at different levels of abstraction. It’s like saying, “I like both apples and fruit.”

According to Merriam-Webster, a synecdoche is “a figure of speech by which a part is put for the whole (such as fifty sail for fifty ships), the whole for a part (such as society for high society), the species for the genus (such as cutthroat for assassin), the genus for the species (such as a creature for a man), or the name of the material for the thing made (such as boards for stage).”

You can’t be a “developer” or a “tester.” A “developer” is a “tester,” among other things. All apples are fruits. All fruits are not apples.

Skill Sets, not People

Programming, testing, and analysis are skill sets, not people. While they are genuine skill sets that require learning and practice, they aren’t so complicated or arcane that they require completely separate sub-professions within the discipline of software development. They are things to do, like feeding Vaal (see Star Trek TOS: The Apple).

People often misunderstand me when I say that. They think I’m saying testing isn’t important. No. Testing is central to software development. It should be taught as part of university and technical college curricula. It’s a failure of our educational system that this fundamental skill is ignored or glossed over in schools. The idea of testing software should not generate all the circular debates and angst that it seems to produce.

Boundaries to Generalization

That isn’t to say a single individual ought to be able to do everything with a high degree of expertise. Technical environments are too complicated for a generalist developer to handle everything. Agilists like to talk about the “generalizing specialist” or “T-shaped person.” Web developers like to talk about “full stack engineers.” There are limits to how far those ideas can go. The larger and more heterogeneous the environment, the harder the boundaries become.

The boundaries to generalization aren’t between activities. They are between discrete and complicated technical areas, like “front end,” “mobile,” “machine learning,” and “mainframe.” Within each area of technical specialization, each developer can possess and apply skills across programming, testing, and analysis activities. Otherwise, they shouldn’t be called “developers.” They should be called “programmers” or “testers” or “analysts,” depending on which fundamental skills they have and which they lack. That’s my two cents, anyway.

Organizational Transformation

Lest you get the impression this is all just about personal preferences regarding word choices, let me put some context around it. Consider the LeadingAgile compass model:

Let’s say your organization has moved from the Predictive-Emergent (PE) quadrant into the Predictive-Convergent (PC) quadrant. You successfully visualized, measured, and gained control of your delivery process to achieve planning predictability. You’ve established cross-functional delivery teams aligned with product lines. You’ve improved your process and proficiency to the level of Basecamp 2, where you have operated successfully for a time.

The next level of improvement is to begin taking advantage of the promise of adaptability; Basecamp 3 lies in the Adaptive-Convergent (AC quadrant, where software delivery activities convergeon identified solutions in a way that adapts to new learnings and unexpected twists in the road. It’s a different business operating model than those that work on the Predictive side of the diagram. This is the real beginning of your “agile” transformation; everything through Basecamp 2 has been laying the foundation for it.

This will involve changing the way you collaborate with internal stakeholders and the way the company interacts with its market. Among other things, this requires a certain degree of smoothness in software delivery. Anything in your team structure, delivery pipeline, or governance procedures that introduces a “speed bump” to software delivery may be reconsidered.

This corresponds in a general way with the Lean notion of focusing on flow. Are there aspects of the canonical Scrum model that work very well at Basecamp 2, but that interfere with flow once we try to operate at the Basecamp 3 level? Now that we’ve solved the delivery issues we had when we were operating in the PE quadrant and learned to deliver predictably in the PC quadrant, might some of the very same solutions turn into problems in the AC quadrant?

I suggest the existence of functional silos or “hard” specializations within each delivery team introduces a “speed bump” to delivery. Your programmers, testers, and analysts may be collaborating effectively and delivering predictably within the operational limits of a Basecamp 2 organization, and that is a Good Thing. You’ve become proficient with novice-level Scrum, running two-week Sprints and delivering predictably against your Product Backlog. But continuing with the same model will not take you far into the AC quadrant. You will hit a ceiling.

Many things may have to change in the organization’s structure, governance, and technical practices. One of those changes must be to smooth out any built-in delay in the software development and delivery process. That will include things like finalizing your automated continuous delivery pipeline and automating your infrastructure management. It will also include eliminating any remaining “waits” between specialists on delivery teams.

Back to the Future

Do you remember the Rational Unified Process (RUP)? It was the Big Thing before Agile came along. It was an iterative process model based on the idea that software delivery comprised four distinct lifecycle phases: Inception, Elaboration, Construction, and Transition. The iterations could be any length, and were typically 3 to 6 months long. Each iteration could include more than one of the four phases, or multiple successive iterations could be dedicated to just one phase.

You can see how this approach resembles contemporary “agile” approaches, only at longer time scales. Another difference is that RUP accepted the traditional notion of “phases” in software delivery that occur in sequence; hence the names and goals of the four lifecycle phases.

One of the most valuable insights in RUP was the understanding that the specific demands on a delivery team shift in the normal course of work. Consider this canonical RUP diagram (public domain):

The varying thicknesses of the regions depicting different activities reflect the shifting demands on the development team. Sometimes, most of the day’s work comprises analysis; sometimes, testing; sometimes other tasks. When the team comprises specialists in analysis, testing, and programming, whenever the bulk of the demand lies in one of those areas, the other two sets of specialists are idle. That’s a “speed bump.”

RUP is no longer a popular model for software delivery, as the state of the art has continued to evolve since then. But the shifting demand on teams is still a reality. With contemporary methods, the shifts occur multiple times per day rather than over the course of a three-month Construction iteration. Every hand-off or collaboration point affects flow.

Smoothing Out the Speed Bumps

A solution is to cultivate developers in the full sense of the word, rather than merely to improve the collaboration skills of the various specialists on the team. Improvement in collaboration skills was the right thing to do on the journey toward Basecamp 1 and Basecamp 2, but we need to go beyond that if we are to reach Basecamp 3 or further. We need team members who can pick up “any” task and run with it.

That’s the kind of team member I’m thinking of when I use the word, developer.

Not the Only Solution

As with many challenges in life, cultivating individual developers isn’t the only way to smooth out the speed bumps caused by specialization at the delivery team level. Mob Programming has proven to be an effective way to eliminate “waits” during software development. As problems and questions arise during the day, the person who has the answer to each one is already in the room and already engaged with producing the solution. There are no communication delays.

It turns out the communication delays for getting small questions answered add up. Eliminating them results in substantial improvement in delivery performance, although each single instance of question-and-answer delay might be of very short duration.

So, Mob Programming (or mobbing) is an effective approach even in cases when the specialists would rather not learn additional skill sets. An interesting side-effect is that they end up learning additional skill sets anyway, as a natural consequence of working in a “mob.” You almost can’t avoid learning. Ultimately, then, we end up with a team of “true” developers, even if the individuals involved didn’t particularly want to become generalists.

Conclusion

If there’s a point to all this, there are two:

• The words we use influence the way we conceive of problems and solutions. For instance, calling someone a “developer” when they are really less than that will make it harder for us to perceive potential improvements in our work. When we say “developer” we think, “someone who can develop a solution.” When we say “programmer” we think, “someone who can write code.” The word programmer makes it easier to visualize what’s missing – all the other skills necessary to develop a solution.
• We should focus on maintaining continuous flow, regardless of exactly how we do so – mobbing, cultivating generalists, or any other practical steps. “Doing Scrum well” could be a starting point, but it isn’t the end game. Rather than verifying you’re performing defined process steps “by the book,” look instead for “speed bumps.”