Uncharted Waters

May 11 2016   7:57AM GMT

How Much Standardization Do We Need

Justin Rohrman Justin Rohrman Profile: Justin Rohrman


How important is standardization to software work, and how much of it do we need?

I spend a lot of time reading about Lean principles, trying to apply them to my own work, and helping to teach the rare class so that others can take these ideas and find ways to work more efficiently. The basics are easy, remove waste from the process so that the only thing coming out of the end of the line is value. The stuff that the customer cares about and is willing to pay for, nothing else.

Like most simple ideas (I’m looking at you, agile) it is easy to misunderstand and go completely off the rails. There are some unfortunate overlapping areas between Lean and Frederick Taylor’s scientific management that might be worth thinking about.

The foundations of Scientific Management were settled in the early 1900s by Frederick Taylor. Taylor thought that most workers were at their core lazy and dumb. Left on their own, these folks would spend most of the day goofing off and causing the company to lose money. At least that is what Frederick thought. So Scientific Management swoops in to the rescue. Under this method, every task and every movement is standardized so that a regular employee doesn’t have to make any decisions.

Here is the weirdness.

Lean, an idea or philosophy for improvement, has a significant focus on standardization. Take sprint planning for example. In most pre-sprint work I have been involved in, there is a voice in the back of the room driving anyone making an estimate to give more detail. Exactly how long will it take to build that feature? Exactly what libraries will you be using. What methods will you be changing?


Knowing these details up front, and being able to standardize the chunks of work and process, is a tool for control and prediction. It gets much easier to figure out what will fit into a sprint and when it will be delivered when the timing is standard. Unfortunately, it is also easier to keep watch over the teams progress and complain when it doesn’t match the spreadsheet.

The Scientific Management roots get much more obvious when I start looking at software work most managers don’t understand, like testing and design work. Testing is especially victim to this. Most companies require that the testing document every ‘step’ of every test idea into some sort of documentation system. The idea is that the work must be planned ahead of time, and that management can’t understand how much work is done and how much is remaining without that documentation. This is a crude form of standardization. In return, the team gets inflexible and standard work.

There might be a place for standardization in software, but creative work probably isn’t the place.

Companies may not mean to introduce the Scientific Management version of standardizing and removing choice, but that seems to be the easiest misinterpretation to jump to. Giving the employees freedom, usually means trusting them and walking a political tight rope. If the employees are right, they get credit. If them employees are wrong, the manager doesn’t look so hot. The illusion of understanding we get with Scientific Management removes trust from the equation. All work is equal, so all that needs to be reported on is the numbers.

I’m starting to see the light in approaches like no estimates that encourage creativity and choice. I’m also seeing why there is so much push back. Allowing employees to discover the work by jumping in is a threat to management. If teams can work with out dissecting tasks, how much traditional management and direction is really needed?

2  Comments on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • AndrewGravett
    I think if you look at the issue from a security and support perspective there should be more focus on standardisation of sw components and coding throughout the lifecycle of the project to ensure security is tested and documented prior to code release and ongoing support simplified and should lower costs via both process and reusable code.
    10 pointsBadges:
  • soyoun
    very good article. I see that it depends on the company size and work load and how much standardization is needed. At the end of the day every employee should document his work to protect him self and every manager will request a progress report to monitor employee performance.
    10 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: