In traditional development we often make an assumption that it is impossible or to costly too test the software early and often. Many companies has proven that the opposite is true; if it hurts, do it more often is the key to success. Unfortunately traditional project-steering models do a lot to keep outdated assumptions in place.

The consequences of delivering and deploying late are for example:

  • We save costly tests and setups of test and delivery environments until the end of development
  • The time from check-in of the code until feedback reaches the developers is very long which means that they have a hard time remembering what they did
  • You see exponentially increasing costs and lead-times and deployments are late because of “Big-bang” behavior
  • The time at integration, final test and deployment is very stressful which causes coworkers to quit or burn out

It’s quite easy to put in KPIs to measure the hard and soft costs this creates, for example:

  • What is the cost of the different test setups and when do we use them?
  • How long is the feedback loop to developers?
  • How long is the “integration” time? What is the cost of the overtime it creates?
  • How much manual re-work is done during test and deployment? What is the ROI of that?
  • What is the cost of overtime related to deployments that didn’t go smoothly?
  • How big is the queue of work waiting to be deployed?
  • What is the value of our coworkers? How do they feel? What is the cost if they quit/burn out? What would we gain if we attracted talent?

Other Anti-Patterns

  Recommend this post
Emil Vikström

Emil Vikström

Agile management consultant at Avega Group
I work as advisor and coach to leaders and development teams.

My specialities are efficiency in IT, leadership, management innovation and people development
Emil Vikström

Copyright © 2014 Emil Vikström. All Rights Reserved.

%d bloggers like this: