Continuous Quality

build to accept the functionality they specified earlier in the cycle. Without short time boxes, this cycle can take months or years to complete. Even with short time boxes, the challenge is to compress this cycle to the point where feedback is continuous enough that responding doesn't require the team to reconstruct context.

Why should we focus on cycles and batching? To deliver as fast as possible, queuing theory suggests that reducing batch sizes, evening out the arrival of work, and including slack can positively influence cycle times. As utilization goes toward 100%, the cycle times of large batches is considerably higher than for small batches. Translated for a development team, this means as a team tries to schedule 100% of their velocity into each time box, the size of the batches in the development cycle will greatly affect the time it takes for the work go through the cycle. The details behind this are beyond the scope of this article. If you are interested in learning more about queuing theory for software teams I would highly recommend reading at least chapter 4 of Lean Software Development by Mary and Tom Poppendieck[2].

Automation and Lean thinking are the keys to enabling quicker cycles and giving the team continuous feedback about quality in an actionable way. Let's look at the ‘why' and in Part 2 of this series I will address the ‘how'.

Unit Tests amp; Code Metrics

Unit tests and code metrics are a good place for a team to start. By implementing continuous integration, where the code is built and the unit tests run on a dedicated machine that is not a developer workstation, you are most of the way there on this level of automation. You'll need a scriptable way to create a build, a scriptable way to run unit tests, a dedicated machine, and the willingness to build with each atomic check-in. If we go back to the basic cycle of development, continuous integration alone can have an impact on batching patters and the quality feedback cycle.

{C}

The above graphic shows how continuous integration affects the feedback cycle. By doing a continuous integration build after each check-in, cycle times and batch sizes can be significantly reduced. Also, the continuous integration infrastructure is giving the team some continuous measures of quality. Specifically, the developers are getting constant feedback on the quality of the code in the SCM system - does the build pass and do the unit tests pass? Through the use of code coverage tools and static code analyzers, the development team can get a deeper understanding of the degree to which each check-in is affecting code level quality. The feedback from continuous builds along with the development discipline to integrate code regularly can help a team to even out the arrival of work, minimize the number of things-in-process, and minimize the size of things-in-process.

Automated Functional Tests

Automated functional testing involves having: a scriptable way to package a build into a deployable or installable package, an automated way to deploy or install that package, an automated was to run database migrations, a dedicated testing machine, and an automated functional testing framework. If we go back to the basic cycle of development, automated functional testing provides continuous quality feedback for developers and begins to remove batching between developers and the rest of the team.

{C}

The above graphic shows how automated functional testing affects the feedback cycle. Now the team is getting constant feedback about the functional quality of the code in the SCM system. By having an automated way to package and deploy/install a build,