Have you ever heard someone say “You don’t know what you don’t know.”? That’s the worst kind of situation. What you don’t know represents risk and it can severely harm your project. Let’s take a closer look.
There are basically three types of knowledge available to a software development team:
- Knowledge the team has — “You know what you know.”
- Knowledge the team is missing and aware of — “You know what you don’t know.”
- Knowledge the team is missing and unaware of — “You don’t know what you don’t know.”
#1 is the easy stuff. There’s a lot of work to do on the project and all of it can be planned and estimated. The team has reviewed the backlogs and knows what needs to be done. There are surely countless details to be ironed out during the project but that’s to be expected. With time and brain-power, the team will figure it out and deliver the software.
#2 is tougher. This is represented by items that the team knows need to be done but not necessarily how to do them. These items can be planned but not estimated. For example, the team knows that the data it needs is located in a remote, secure database. However, they don’t know how to access the database, what it’s table structures look like, or how fast it can provide the data. Additional analysis will be needed to fill in the missing knowledge.
#3 can be a killer. This represents items that the team is unaware of. These items cannot be planned or estimated. For example, late in the project a key stakeholder who has been unavailable until now, comes forward and casually mentions that due to security constraints, the software has to run on local servers across the country. It cannot be run from a single server location meaning distributed databases will need to be synchronized. Looks like time and cost just increased … a lot!
Every form of knowledge carries risk.
Each of these groupings involves risk. In #1, some of the assumptions will be proven wrong. In #2, the analysis could prove to be far more complex than envisioned. In #3, well, anything could happen and none of it is good.
For these reasons (and many others), you need to stop planning and start delivering. In many situations, no amount of analysis and planning will guarantee success. Let me tell you a story from the automobile industry.
When Ford was redesigning its Windstar minivan in the 1990’s, it conducted extensive focus group testing. One of the ideas being tested was a driver’s side sliding door for passenger use. Back then minivans had a sliding door on the passenger side only. The focus groups weren’t impressed by the idea and Ford decided not to include one on the new Windstar.
Meanwhile, Chrysler was redesigning its minivans and added dual sliding doors. The doors went on to become so popular that all minivans now have dual sliders. Ford had to hastily re-design it’s Windstar.
“You don’t know what you don’t know.” Talking about an idea and interacting with a prototype are not enough. Most of us need to use the idea in real-life situations. Only then can we derive knowledge and articulate it clearly.
That’s why agile approaches to software development are superior. Scrum, Kanban, Lean, XP, etc. get working software into people hands sooner. The software will be incomplete, but as long as there’s enough functionality to derive new knowledge, the stakeholders and end users will be able to offer better information and the final software release will benefit.
Agile approaches work because they help software development teams do the following:
- Validate what they know.
- Build their knowledge base to fill in things they don’t know.
- Discover the things they didn’t know they needed to know.
That’s why I’ve said many times that software development teams need to — Plan Less. Deliver more. By doing so they’ll learn a lot and produce better quality software.