Minimal sufficiency applies to tooling just as much as it does to documentation!

“Working software over comprehensive documentation”

This value statement from the Manifesto for Agile Software Development is a reminder to remain vigilant that the by-products of our product or project processes don’t distract us from delighting our customers and stakeholders. For organizations which have onerous, document-based delivery standards, it serves as a guiding principle to lean out methodologies focusing on the minimal set of information required to meet delivery and control needs. This is usually accomplished through elimination, consolidation and streamlining of documents.

But what about those companies who have implemented tooling to support delivery in place of documentation? Just because we have moved from standalone documents to one or more supporting applications doesn’t mean we should not apply the same principle of minimal sufficiency.

Here are three ways I’ve witnessed this principle ignored:

• Multiple point solutions with overlapping data elements, conflicting workflows, and differing nomenclature. This often occurs when delivery tooling is procured in a distributed manner. For example, a Business Analysis leader might select a requirements tool, a Quality Control manager has procured a test case and defect management tool and so on. Project teams get confused by how the different tools connect together and the likelihood of data accuracy, consistency and completeness defects increases. While detailed reporting can usually be managed easily, project/product-wide or portfolio-level reporting becomes extremely difficult.
• Not disabling the fields and features which are not required. You might ask who would fill out a field or use a feature which they don’t need to, but you’d be surprised at the creativity of teams at using unused fields as a means of ferreting away some information they believe is valuable. Beyond the potential for field or feature abuse, a bigger concern is team members getting distracted or overwhelmed by the complexity of a solution.
• Tooling which does not map to the information needs of team members. Its become a cliché, but one which continues to be ignored – don’t buy and implement a tool if you don’t understand the process it will be supporting! If the tooling does not help team members do delivery activities, then they will treat it as an afterthought and continue to use more useful, home-grown solutions.

I am not encouraging the development of delivery tooling in house or engaging in significant customizations to third-party applications as neither approach is appropriate for most organizations. It does mean you should be spending some effort up front to identify the key data elements which will be needed by different contributors to the delivery process, defining the minimal set of reporting and workflows required, involving an actual delivery team in the tools evaluation process, and working with vendors to safely disable or hide all non-essential features.

So before patting yourself on the back that you’ve migrated from delivery documentation to online information make sure that you haven’t just replaced one source of waste with another!