What is the Value of Your Work?

An Agile maxim is that software in production has value.  Requirements and design documents have little to no value.  Ask, “Would the customer pay me to do this if they had a choice?”

But there are people in large organizations that work hard every day, making their contribution to the delivery of large systems.  They create things like Functional Requirements documents and Visio flow charts, and architecture design documents with associated review meetings and signoff collections.  These people have come to believe that these items have value in and of themselves.  They probably don’t.

What is the value of your work?There are two basic reactions when people hear this. One, they experience defensive disbelief.  They cannot imagine what would happen in the space between concept and coding without their efforts.  Their organizations have delivered software this way for a very long time and it works, they say, and of course their role was important.  They have limited visibility into how grossly inflated the costs associated with these activities were as compared to the value of these activities, and how much time and value was wasted in long delivery.  Ask what the value is and what purpose the activity serves: The goal of any document is communication. Then ask if there is a better way to communicate in the delivery of products and services.  Many organizations have even created audit police forces that demand these non-software artifacts, threatening managers with the bogeyman of jail time for executives if the documents are not created.*

The second reaction is to question their personal value and contribution.  These people did exactly what they were told, and were very diligent.  But when they see people using Agile principles to deliver code, rapidly and at lower costs, they are stunned. “Oh my, all that work had little value.  These people are delivering software all the time, with none of the artifacts we thought were important.” Some folks get re-energized and dive into the Agile teams, looking for how they may apply their experience and expertise.  Others leave to search for organizations where they can hide till they retire, ones still mired in silos and handoffs of large batches of non-value adding work.

Agile/Scrum teams need the domain knowledge and experience these people offer.  Teams need to understand the functionality of current systems, and how pieces of the organization work together.  But Scrum needs it in a lightweight manner, like a whiteboard session or a 30-minute discussion over doughnuts and coffee or some other more efficient mode of communication.  The Scrum Team can deliver high quality code frequently, but they need to work on the right things.  They can create their own architecture, but it is sure fun to have an architect that wants to get their hands dirty with code that implements a vision and is willing to do what teams do naturally when left to their own devices … experiment in small increments, learn, and deliver.  The Product Owner role needs support to help explain the business context, and to know where to challenge the status quo and when to leverage it.  The great thing about Scrum is that everyone can see their ideas in production quickly, and know how they contributed to the value of the organization.

So the next time you are asked to create some level of documentation, ask yourself if there is a better way to communicate what the document is attempting to convey.  And if you have to meet about the document or get the document approved, then ask if experimenting with a design and having a meeting about whether we are heading down the right path with working product is the better choice for communicating.

* The number of people who have gone to jail for SOX issues is zero. See the Wall Street Journal’s 7/29/12 article, Law’s Big Weapon Sits Idle. [Registration required.]

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.