Software innovation, like almost every other kind of innovation, requires the ability to collaborate and share ideas with other people, and to sit down and talk with customers and get their feedback and understand their needs.
— Bill Gates
In my 29 years of building software, I’ve learned to view the Software Development process as a flow. I’m sure that this doesn’t seem particularly insightful, so bear with me. We all know that there is a standard flow from requirements to coding, testing and through to delivery to the customer. In my mind, the flow looks something like one of those water flow puzzles on the Internet [1]:
What’s important about this visualization is not the sequence, which we all know. It’s the fact that there is a certain threshold for each “container” before the work can flow to the next. Specifically, I’m not just talking about volume – we’re all familiar with projects where there were lots of requirements and the project still failed miserably.
The fundamental belief that has helped me turn around many projects and teams is that the quantity and – most importantly – the quality of the contents in each container is vital before the next step in the process can be started. What results is something of an Order of Operations for software development that looks something like this:
In this case, step #1 represents the process of direct interaction with the Customer – the most important stage of the process. Again, ignore the obvious interpretation that we do each step in sequence – that should be well understood, especially by anyone who has done Waterfall development [2]. What I’m talking about is that if you want to solve a problem in your Product Development organization or start a project off on the right foot, focus on the quality of each step in the sequence defined. Only proceed to the next stage when you’ve proven you have done the current stage with high quality.
Many will say that they already do this, but I can tell you from my personal experience that most Engineering teams start very quickly into stages 5 and 6 without much concern for whether steps 1 through 4 have been executed well. This is partly because it’s not their job (as a rule) to talk to Customers and create requirements, so they assume that “the business people” do that. It’s also because this is generally not interesting to them. As a Computer Scientist, I can attest to my love of code and the challenge of solving a technical problem – it’s what draws us to our craft and keeps us there. And lastly, if I’m being honest, most Engineers look down their noses at business types, since they often aren’t technical [3]. Programming prowess is the alpha quality for Engineers and those that don’t have it are viewed as inferior. I’ll talk later about how this is a major impediment to successful products.
Through using this flow analogy, if there is not enough water (or whatever liquid you choose to visualize) flowing into subsequent containers, there is nothing to work with. Alternately, if the quality of the water is deficient, all subsequent containers will be polluted.
Using the real world equivalent, let me say one of the most important (and obvious, but very frequently violated) conclusions of all this: no time spent on building software against a poor understanding of your Customer is time well spent. Let me restate:
All effort spent building the wrong thing is a waste.
The next post builds on the model outlined above and I look forward to sharing that with you. In the meantime, I’m looking forward to your comments.
This post is based on or excerpted from the upcoming book “De-Engineering the Corporation” by Darryl Ricker
Footnotes:
[1] I originally had a diagram that was a bunch of stacked rectangles. It made sense to me, but my wife said it wasn’t self-explanatory (and she was correct, as much as it pains me to say it), so I tried to think of a more visual model. I was really stuck, so as the Grinch did in 1957, 1966 and 2000, I puzzled and puzzled ’till my puzzler was sore. I finally decided upon one of those water puzzles you see from time to time in your social media feed – I am always amused by people’s answers. If you haven’t seen such a thing, here’s an example of a water flow puzzle – link
[2] This process still holds true even when you do it in rapid sequence using Scrum, for example.
[3] I should mention that I have been one of “the business people” over good portions of my career, so I don’t believe this myself. In my experience, when you combine great technical people with great business people and have them work as partners and teammates, incredible results ensue.
Leave a Reply