While visiting the CONQUEST 2010 in Dresden, Germany, I noticed something while wandering the large pavements in this city. Each time I had to cross the streets at traffic lights, I noticed that I had to stop, press the button for the lights to turn green – after some time. This morning on my way from the hotel to the conference place, it struck me, that this steadily slowed down my own progress. Each time I had to stop at the traffic lights, I was considering what needed to be improved in order for me to make more progress on my way to the conference building.

That was when I realized that the buttons on the traffic lights needed to be pressed each time. If I didn’t press it, the lights for the walkers wouldn’t turn green. This is a clear difference to some of the lights I know from home in Bielefeld (which does exist, just saying). There were pseudo-buttons which you could press or not press, but the lights still turning green. The difference to Dresden now is, that as I was approaching another traffic light, I needed to stop, press the button and wait for the lights to switch, if there wasn’t already someone waiting for it – which turned out to be rarely the case; thus the waiting.

Then I realized, that the button in fact is a similar to a quality gate in more traditional processes. At each gate you have to wait, you have to synchronize back with other parts which are then integrated. But in either case, you seem to have to wait. Then I asked, how would a pseudo-button for quality gates look like? Well, that’s easy, if you do small steps, tiny improvements, and integrate early, often, or even continuously, then you have a pseudo-button. In fact this is the case on Agile projects. You get the feedback from the unit tests during test-driven design. You get the feedback from the story-tests before checking in your changes to the code base. You then get the feedback from the CI-server which runs the tests. On another step you get the feedback from Product Owner and stakeholders during the iteration demonstration or sprint review meeting.

Now, all these feedback loops exist as an automated quality gate. You get the feedback, that you broke something, and you immediately know on what you have focus your immediate attention. On the other hand, when you don’t get any feedback, you also know that everything might be fine, and can continue your work. (This should be the case most of the time.) Quality Gates are automated to large extends in Agile development for good.