Have you maintained software whose code bears little resemblance to its design docs and comments? How many times have you seen a detailed and diligently maintained schedule, which is regularly presented to management with lots of green and red highlighting, but which no one in the trenches thinks has much to do with the work they are accomplishing? Have you had a release sail through testing with flying colors, only to be rejected by customers because it wasn't what they wanted?

These are all examples of a lack of "ground truth". Ground truth is a key to successful software development. What the heck is ground truth and why should you care? 

Creating software is difficult because we are building complex, abstract systems using highly flexible and largely unbounded mediums (e.g., napkin sketches, screenshots and stories, designs, code, content, data, project schedules, etc.). To manage the complexity and abstract nature of building software, we create all sorts of models to help us move from conceptual idea to concrete software. Requirements model what the system will be. Designs model how we we will put it together. Project plans model how we will get the work done. Test plans model how we will test it. Code, data, content, although arguably concrete, are often themselves modeling an abstraction of the real world (e.g., a user account).

All this modeling is critical for allowing us lowly humans (who can't keep more than 7 things in our heads at one time) to build complex systems. However, we need to make sure that our models do not drift from the reality they are intended to represent. This idea that models and reality should stay in sync is captured succinctly by the term "ground truth". 

Ground truth came from cartography and is also used in the military. In cartography, ground truth comes from the idea that a map is an abstract model of terrain, often focused on particular attributes (e.g., terrain type, political boundaries, elevation, etc.). Saying a map has ground truth means that although it doesn't show all the detail of the real world, what it does show accurately reflects the real world. This is nicely summarized by the following advice for navigating: "when the map and terrain disagree, believe the terrain".

In the military, ground truth is expanded to mean accurate situational awareness. A commander directing a battle from HQ has information available that creates a model of the details occurring in the battle. It is critical that the model created at HQ reasonably reflects the ground truth of the battlefield -- otherwise poor decisions will be made and lives may be lost. For software development, our situational awareness encompasses what we are building, how we're building and validating it, and how we are getting all of that work done. If we lack accurate situational awareness, we will make poor decisions (e.g., leaving out a critical feature) and lose time on useless tasks (e.g., updating a schedule that no one is using to coordinate their work).

The notion of ground truth is a great concept, especially for work that relies on abstract modeling as much as software development. When I encountered the term in the (highly recommended) book Corps Business: The 30 Management Principles of the US Marines, it immediately resonated with my software development experiences. There were so many times I had seem efficiency and effectiveness suffer because models had drifted too far from reality, whether it was a fairy-tale project schedule, requirements docs that no one understood, or an architecture that could never be implemented. 

How do you ensure ground truth for your software development? Using good development practices helps significantly, but there is also art involved. Open your eyes and ears to as many sources of information as you can; don't rely on your models (requirements, designs, plans) as the sole source of information. Constantly cross check information in the models to ensure both internal consistency and consistency with the real world. If you are managing work don't rely on status reports, make sure you talk informally to people doing the work about how things are going -- if you hear grumbling, investigate. If you are doing requirements don't rely on document sign-offs, informally talk through tricky details with different stakeholders (end users, customers, developers, testers, etc.) to spot check understanding. If you are designing, create functional prototypes to prove ideas and make sure the people using the design understand it. If you are testing, don't just rely on equivalence cases for written requirements, understand the operational context and be creative about what might go wrong. 

Software development ground truth ultimately means building what is needed without wasting effort and time on unnecessary activities.

Well, maybe not all of them. Some are so pretty, that uniform cascading of well ordered tasks trickling downhill to perfectly coincide with the deadline. Get color prints made, frame them, and hang them as abstract art. Don’t use them to manage your software development.

Balance is an important part of life, so I plan to add some perspective to the inflammatory opening remarks (so I can keep my PMP certification). First though, let's bludgeon the hot air out of the Gantt chart culture that inflicts many software organizations. Included in this category are the so called “activity network” models (primarily Gantt and PERT) and the tools that propagate their widespread use. Unfortunately this is pretty much every project/work management tool out there from Microsoft Project and other scheduling tools to the many group-ware collaboration websites. No matter how many pretty pictures are created, relying on these techniques to manage software work just isn't very effective.

Where does this hostility come from? Was I abused by project managers as a child? No, that came later. And then the cycle of violence continued for a time as I inflicted Gantt charts on others. Eventually it became apparent that the model of work created in the scheduling tool, with its ubiquitous Gantt chart view, usually lacked ground truth. Energy would be invested by all creating, reviewing, presenting, updating, and wringing hands over the Microsoft Project file. Then people would go and get the work done without any regard to the Gantt chart. What to do to avoid this waste?

A valid approach is to adopt task-driven methodologies such as Scrum. I’ve never been a fan of adopting methodologies though. Although there are benefits in being told exactly how to do something, customizing a simple set of principles and practices often leads to a better optimized solution.

What is the purpose of Gantt charts? They provide visibility, predictability, coordination, and control of work. These seem like important things, at least to the pointy-haired managers. Why do scheduling tools often fail to provide good visibility, predictability, coordination, and control of software work? Because they focus on time-based management of the “critical path”, i.e., dependencies and ordering of work. Most software work runs into trouble not because the critical path was mismanaged, but because EFFORT was underestimated. If you do not have high confidence in your estimates, building elaborate Gantt charts based on those estimates will not increase your ability to manage work effectively.

What are some basic principles you can incorporate into your planning and management of work? Regardless of lifecycle and methodology all software work boils down to deliverables people need to create. Focus on these deliverables. Have individuals and teams define the deliverables for a release (sprint, milestone, whatever). Have them estimate effort ranges (not time or dates) for the deliverables. Use a simple spreadsheet to track effort expended on and completion of deliverables (and/or use work queues and burn-down charts). Let the team work out the fine-grain details and dependencies of the work on their own, whether formally with a methodology like Scrum or informally. Look at the big picture on a regular basis and see where adjustments may need to made.   

Gantt chart views are important for managing a complex series of work, for instance, a team with lots of dependencies on other teams. They work best when focused on deliverable milestones rather than task details. Just as different views of a design (e.g., physical and logical decomposition, database, UI screens) increase the understanding of the software to be built, multiple views into software work increase the understanding of how that work is going.

Thus you may not need to throw your Gantt charts out, but you should only rely on them for what they are good at. And that is not for planning what task Tom and Susie will be working on at 2:30 pm this Wednesday.