Over a million developers have joined DZone.

Tools for Disciplined Thinking

DZone's Guide to

Tools for Disciplined Thinking

· Agile Zone ·
Free Resource

Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap. Brought to you in partnership with Techtown.

There is nothing in the manifesto that says we can’t write documentation if we think it’s a valuable contribution the the product. That line in the Agile Manifesto about working software over comprehensive documentation means is that we can’t use our documentation as a measure of progress.

Documentation says little about how the product is actually progressing.

That’s because documentation is a transient product. It’s an intermediate artifact of the software creation process, and not what our customer pays us to build. We get into trouble when we start thinking the project is 60% done because we’ve written a stack of design docs. Documents are full of assumptions and unrealized risk.

That said, I think my tolerance for documentation is higher than most… and certainly higher than that of many folks new to agile, and excited to cast off the chains of more traditional software development life cycles. Most of the time I have to convince folks that it is actually okay to write things down. It is okay to capture your thoughts on paper or in a tool.

Word documents can be okay… so can Powerpoint… and even <gasp>  MS-Project plans. I’m even okay in some context with standard templates and checklists. Granted, not every project… not every team… needs this much structure. What I find though, is that many of the forms we used to fill out, actually contributed to the level of disciplined thinking.

Those forms gave us a framework for discussion, and a list of stuff that we probably shouldn’t forget to consider. Somewhere along the way… likely some project manager type … came along and lost sight of the goal. When templates were filled out, projects were more successful, so therefore the existence of the filled-out template must have been the reason why.

Somewhere along the way, the focus became getting the document filled out rather than the thought that went into creating it.

I’ve got examples of Marketing teams that use a MS-Project doc to guide their tradeoff decisions during sprint planning. I’ve got business analysts that use their traditional requirements format to guide their creation of the prioritized product backlog. I’ve got project managers writing vision documents and charters used to communicate project intent to their stakeholders.

In and of themselves, there is nothing wrong with these documents. There is nothing wrong with templates and checklists. The teams these folks work on are fully agile and using these documents for their intended purpose… to think through the problem and to document what they learned collaborating with their teams. The documents are not the end product, but a means to help us get to the end product.

Take Agile to the next level with DevOps. Learn practical tools and techniques in the three-day DevOps Implementation Boot Camp. Brought to you in partnership with Techtown.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}