DevOps: The Key to Lean Development!

It cannot be overstated how important efficient software development tools are in improving the effectiveness and predictability of  a development team.  Small inefficiencies multiplied over the size of the team and the duration of the project add up to a significant negative impact. Time spent compiling, building, and deploying software is pure waste.   Waiting hours or days to have testable software has no place in a Lean organization.

The project hierarchy also dictates requirements for the build system.  Each level in the hierarchy shown below needs to have rapid access to the work products produce at their level or below.

Graphic 1

 

As work is produced, it needs to be promoted quickly.  However, it should not be promoted without passing the appropriate quality gate.  In the case of the developer, that would typically be unit tests.   In the case of the team, that would be acceptance tests for a story or epic.

Build Process

Shown below is a prototypical build process for a developer, team, and system project.

Graphic 2

Graphic 3

Graphic 4

Lean Build Principles

There are a few key principles that eliminate waste and reduce build/deploy times.  Here are a few of the most important:

  1. Only build what has changed.
  2. Avoid compiling any component twice. Once it has been compiled and built within the system, promote the executables downstream.
  3. Give developers and teams control over their build frequency.
  4. Use good dependency management to build efficiently and allow for parallelism in the build process.
  5. Do rapid validation at each step to avoid promoting and deploying builds that have obvious errors.  Deploying a bad build that can’t run any tests is 100% waste.

Service Level Requirements

For the three levels in our sample organization, each has some implied service level requirement for the build.  Developers require access to code within minutes.  Teams require builds within an hour or two, and system builds need to be available multiple times per day for all geographic locations.

Return on investment

It is tempting to avoid investing in the development process.  Some of the arguments are:

  1. Developers are resourceful and can resolve issues in the build process themselves.
  2. This will take away from capacity to build new features
  3. Teams will escalate build problems and get them resolved.

In my experience, development teams view it as the job of the program to resolve build issues.   How many of you have heard “Isn’t someone working on that?”? These problems are also very disruptive to “flow”.  It takes the teams out of their rhythm of building new function.  This waste is very hard to measure, like “dark matter” in the universe, but you know it is there.

Regarding taking capacity away from development, payback on investment is pretty easy to justify.

For a team size of 100 developers and 30 testers, the chart below shows that if it takes a developer 30 minutes to compile code for unit test, the project is wasting 200 hours per day.  That is a full staff month every day!  If a team build takes one day, 160 hours of developer time and 48 hours of tester time are potentially wasted.

Developer Build Time

30 min

10 min 5 min

1 min

Developer Waste Hours/Day =>

200

67 33

7

Tester Waste Hours/Day =>

0

0 0

0

Team Build Time
1 day 4 hours 2 hours

1 hour

Developer Waste Hours/Day =>

160

80 40

20

Tester Waste Hours/Day =>

48

24 12

6

Summary

If you are serious about improving your development efficiency, start with DevOps!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s