Four Levels of Delivering Software (For Enterprise Software Teams)

The ability to deliver software (physically turn ideas into working software that a customer can use) has different levels, and before trying to improve your team, it helps to know where you are. These levels are focused on Enterprise Software Teams (EST). Product Teams have a similar track with a different focus (they’re focused on revenue generation as an indicator of success). These levels are ranked from emergent to established:

1: Can turn a written specification into working software reliably
2: Can turn not-well-specified ideas into working software reliably
3: Can work with customer to elicit ideas to turn into working software reliably
4: Can challenge established norms and focus on delivering value over writing software according to customer’s stated needs

Agile, and Scrum specifically, work at levels 3 and 4. Most ESTs are at 1 or 2, and they believe that adopting agile (or Scrum) will get them to level 3 and 4.

If you look closely, there’s a precursor step before being able to adopt any agile methodology (like Scrum): The software team must be able to focus on the needs of the customer and be able to make the decisions necessary to improve the customer’s experience. Not a VP of Delivery, not a project manager, but the team itself.

Five ways to Go faster as a Software Team (That have nothing to do with Skill)

There are lots of ways to deliver software faster that have nothing to do with the skill of your software team. Here are five:

1. Tighten and clarify the vision
2. Choose well trodden, simple technologies (No one went broke choosing IBM*)
3. Remove the number of people involved in making a decision
4. Build the software to be disposable (no future proofing allowed)
5. Tighten execution focus to one thing at a time (no context switching)

*Switch this to your favorite well-trodden stack if you’re a programmer: Ruby on Rails, .NET, J2EE, Django. This is also known as the “You don’t need Cassandra” rule.

Literal Problems

Them: “We do scrum, we have 2 hour planning and a standup once a week for two hours.”

Developer: 🤔

And in that moment, the developer decided the company was clueless about software development processes.

Why? Because the Project Manager used words that did no mean what they thought they meant. Developers are finicky literal creatures. Their worldviews can tend towards black and white because to a computer there isn’t such a thing as ‘figuratively true’. A state is either true or it’s false, there is no in-between (this will not age well if Quantum Computing becomes mainstream).

Scrum has four ceremonies held at very specific intervals; and even the End Note in the Scrum guide says,

“Scrum is free and offered in this Guide. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.”

This is a rigidness a developer loves and a business person hates. For things a developer ‘knows’ about, they judge others competencies on using words as their meaning states. It’s an interesting profession, to be sure, and developers are so much fun at parties. The concept of “Nerd Sniping” is predicated entirely on developers exposing some incongruity in the world and sucking others in to the problem to think about.

But, if you want for your developers to respect and listen to you, you may have to give a little bit on some of these points.

There are two ways out if you care what your developers think of you:

  1. Don’t call what you’re doing Scrum if you’re not following the guide to a T;
  2. Risk alienating your developers and calling your process “scrum”

One Grade’s worth of Progress

We spend a fair amount of time in Software Development focusing on the big players. We focus on Netflix’s chaos engineering, the “Spotify Model” for software development, Microsoft’s (now defunct, sadly) private office layout for software developers, or Stack Overflow’s architectural approach to operating at their scale (Stack Overflow is a top 50 website in the world, and likely the #1 developer destination in the world).


We focus on them and we grade ourselves against them. Microservices migration failing? I guess we’re not as good as Netflix. Why has scrum failed for us when it worked for <big name here?> Why do we have so many bugs? Why can’t we do what Microsoft did and launch a “Zero Bugs” campaign?

One of the (many) lessons I’ve gleaned from following my wife’s career in education is the idea that each child learns at a different pace. We pay lip service to it as non-educators, but differentiated education really makes it a central thesis: Every child is different, why would every child learn at the same pace or in the same fashion?

Every software team is a single being, and that being knows, learns, and operates at a different pace and level than any other software team out there. Our methodologies and “best practices” are tailored after what we see the biggest and ‘best’ doing, but much like teaching a child to read or learn multiplication, what works for one won’t work for another.

To combat this feeling of ‘being left behind’, if all children aren’t evaluated to the same ‘standard’ (I’m using ‘standard’ here to refer to standardized tests), educators that use differentiated learning will evaluate each child against their own progress. Has this child made one grade’s worth of progress from where they were when they came into the classroom?

Has your software team has made progress against itself? Has it improved how it delivers value to your organization over the past year?

Is Pair Programming + TDD worth it?

I’ve seen three types of companies when it comes to pair programming:

1. We pair program on EVERYTHING.
2. No, we don’t pair program.
3. We pair when we need to.

Of course, it also helps to define what I mean by pair programming, because there are multiple definitions.

For teams that practice the classic definition of Pair Programming from the agile practice Extreme Programming (XP):

Pair Programming is a method of developing software where one programmer sits and the keyboard and “drives”; starting by creating a unit test, and then the other programmer takes over and writes the failing/passing code for the test. In this definition, the act of switching for every unit test is key.

In teams that do not practice TDD, Pair programming is two sitting in front of a computer with one keyboard and mouse for 30 minutes – 6 hours trying to solve a problem.

Pair programming paired with TDD is a great practice when you have people who are trained in TDD that can guide new programmers. Being able to teach TDD is key — there are lots of wrong ways to do it, and they end in frustration with the practice of TDD in general.

Pair Programming to solve a problem without TDD is how most programmers interact, and opinions range from ‘great!’, to ‘meh’, to ‘omg do we ever have to do this again?’

Recently I spent about a week on a problem that with a pair took me about 6 hours to fix and if the entire component had been created through TDD would have never occurred. It’s also taken me many years of practicing TDD and pairing to know that it wouldn’t have occurred had our team used a TDD+Pairing process.

So why didn’t I TDD that component? In a phrase, because the culture doesn’t support it. There’s no mechanism to get buy-in for something that is arguably akin to wearing a safety harness on a job site. (If wearing said harness caused everyone on the site to have to learn how to work in safety harnesses)

If you’re trying to deliver software for a project where the code isn’t going to last several years, maybe TDD and pairing isn’t worth it. If the domain isn’t complex and deep, maybe pairing isn’t worth it. But if the code is going to last at least 3 years, it may just be, provided you’re willing to train your programmers on TDD and pairing together.