in

Ative at Work

Agile software development

Ative at Work

Why Going Faster Matters

I did a talk on Value Stream Mapping from Lean last Thursday at the Danish Agile User Group meeting (slides in Danish are available at http://tech.groups.yahoo.com/group/DanishAgileUserGroup/files/ (registration required)). 

One of the many interesting questions that came up was why faster is better - could it be that slower would be more efficient?

The context was that be that faster could be more expensive - ie. adding more people to fix the problem. In that case there is a chance that slower is in a sense better. Dogmatic software development even has it that resources, timeline, quality and feature set are interrelated. If you want to go faster or to increase the quality, it costs more.

The underlying assumption is that the process is perfect and therefore that all the work is essential and valuable.

That, however, is a myth.

From the perspective of the Seven Wastes that I blogged about recently I would like to rephrase the question to "is less waste always better?"

I think the reason that many people connect lean with faster is that the most obvious waste in value stream maps is the waste of waiting. So on first impression lean is all about eliminating that and keeping extra resources available to solve tasks immediately when they arise with with no delay.

That would be wonderful however but if we have a great variation in the workload we will take on a huge overhead to have peak capacity available at all times. Since this would be a waste when demand is slow lean has a practise of balancing work and capacity to keep the variation low.

In case there is extra capacity available we use it for kaizen - process improvement. In software, for example, we could spend it on refactoring a legacy system to a cleaner state so we can work faster in the future. This would enable us to take on extra demand with the same number of resources.

Now there are other wastes than waiting and it is by looking at them that we see that lean is actually not a cause of stress as many seem to belive. The aim is not working faster doing the same thing. The goal is to only do the work that is actually valuable.

This means getting to the goal faster by doing less. It does not mean burnout or overtime.

From this perspective I believe that lean is a more humane approach than the obvious alternative of status quo where speeding up is derived from the project manager pressuring and threatening employees to work overtime, cut quality etc. In that traditional context faster means evil, but in the agile world, where respect for people is the centerpiece faster also means better. It denotes less meaningless work. It means freeing up all the untapped human talent of the team and putting it to bear on doing exciting work - to spend our working hours creating something that will please the customer faster and at a better quality than ever before.

That is the essence of agile - and it's the source of great job satisfaction.

Comments

 

Ole Jepsen said:

Hi Martin

Great conclusion. On the surface it's "only brave" to conclude, that fast equals job satisfaction. It could sound like a shallow argument - and some may think, that it's not a valid business argument.

If anyone tells you so - send them my way. I will share my numorous experiences with clever, engaged, enthutiastic and busy developers. And also my storyes about frustrated developers from enviroments, where they feel, that they are wasting their TIME...

Ole Jepsen

februar 5, 2007 11:22
 

Jan Daniel Andersen said:

When people think that Lean leads to a more stressful workplace, I believe it's because they think that the efficiency of lean removes all the "rest" periods during the day.

When working, most people change their productivity up and down many times during a day. Sometimes we are super focused on a problem and delivering close to 100% of our capacity and then shortly after (typically, when a significant fragment of the problem is solved), we slow down and relax (getting coffee or surfing the internet for a short while).

This is in most cases an efficient approach to working and it IS sustainable for long periods. All Agile disciplins dictate that we must be able to work at a sustainable pace indefinately, so if Lean would dictate a process where people burned out, it would not be an Agile practice.

When Lean talks about efficiency, it's not about removing the natural brakes we take, but removing the "on"-time that is not producing value for the product, as Martin describes. In other words, we only spend our capacity on work that produce value.

This leads to a work day that is no different from our "normal" workday with regards to how much time we spend at peak performance and how many "brakes" we take. It just makes the peak performance times more efficient and creative and in most cases, a lot more fun. Since we only get to do important work that has high value, there's a good chance that we don't have to do boring and repetitious work (repetitious work should be automated whenever possible).

Just my 2 cents.

februar 7, 2007 9:48

About Martin Jul

Building better software faster is Martin's mission. He is a partner in Ative, and helps development teams implement lean/agile software development and improve their craftmanship teaching hands-on development practises such as iterative design and test-first. He is known to be a hardliner on quality and likes to get things done-done.
© Ative Consulting ApS