As we continue to grind on making the Software Development Life Cycle a bit more useful to most folks we’ve been encountering a lot of positive validation from within and without our own networks.
The reality is that most (all?) technology companies just aren’t getting the throughput that they really need to maximize their tools, their systems, and perhaps most importantly, their people.
The sad truth is that much of the data is already available and ready to be consumed. What lacks, in many aspects, is the speed at which this data can be acquired and also the ability to understand the data in a meaningful way to make decisions.
In short (and to grossly oversimplify), there’s a significant lack of context for both the data and the people who have created the data, the developers, the managers, and the team as a whole.
Stealing from Steve Blank, a serial entrepreneur who’s best known for defining Customer Development and the Lean Startup movement recently recounted an experience one of his students had with the government and the military to help them solve problems:
Unlike businesses, government organizations don’t sell products, and they don’t earn revenue. Instead, they have missions to accomplish and very hard problems to solve.
There are almost too many parallels to software development, but, you’re a smart group so I’ll just continue the point; using the Mission Model Canvas, an iteration on the Business Model Canvas, Blank understands that the missing pieces are not really data but context for all of the moving parts that exist in an organization:
Unlike their commercial counterparts, government problem solvers are often faced with multiple beneficiaries associated with a problem, often with conflicting value propositions.
And so in this encounter they hypothesized that an increased amount of data would be the real solution. Instead, they realized something much more profound:
After further questioning, the team discovered the reason the divers were spending so much time underwater – they often did not know where they were.
I almost laughed aloud when I read this because I can think of near-countless times where I have thought the exact same thing when it came to my software team and where we “were” in the software development life cycle!
To make a long story short (and you can read the full post here) the medical director, when informed about the real issue that his divers were having, answered in the following way: “Never knew that’s why they spent all that time down there. Heck, yes, fix their problem first.”
The point is this: The data is there. It’s powerful and useful. The problem is that you don’t have the missing ingredient, which is contextual awareness of what the data means and who might be impacted.
And this goes all the way back to why the SDLC is fundamentally broken for so many teams and businesses. They have the data but they lack context. They know the data is there but they don’t know who’s necessarily involved or who the real “beneficiaries” are.
Another way of looking at this and stating it most simply is that the team(s) simply do not have the tool(s) to work together well and efficiently.
And, of course, we hope to change all of that.