The harmonica schedule

Tom Breur

17 July 2016

Regardless of how “mature” your Agile practices are, when you have to fit them into a broad(er) corporate framework, you will be managing expectations with regards to delivery schedules, planning, interdependencies with other teams, etc. So in the grand scheme of things, delivery looks a lot like what we were used to in the good old Waterfall days.

A common problem with traditional projects is that much of the test case writing, test automation, and test plan execution is left to the end. And of course then problems can hide out until just before the release. That implies you become “victim” (by your own doing…) of a long delay between the introduction of a problem and the detection and fixing of that same problem.

Time after time, with traditional development, progress is measured based on progress against a plan. The problem with that is that customers don’t buy Gantt charts, they buy shipping software and the progress that is measured by Gantt charts is not directly connected to shippable software. It is almost impossible to see at a glance what the real project status and progress are. You know that you won’t start getting information about where you really are until sometime after code freeze.

When you aggregate work across many teams, as you do while you are “scaling” your Agile implementation, similar problems arise. You just can’t square a circle: either the teams are working independently and relatively autonomously, or you will get caught in a web of interdependencies and exponentially more expensive communication overhead.

As code gets written, it is integrated (technically or functionally, as part of the larger value chain). The product gets built and tested continuously, but still too many problems are found and fixed towards the end of the schedule. The “testing phase” (which really is the integration phase, if you think about it) gets squashed towards the end like a harmonica.

Remember: testers can never “guarantee” quality: they can report on findings (be transparent about what has been tested, and what the findings were), and signal some risks. But in the end it is management that needs to decide (take responsibility) when these risks (costs of early release) are bearable, and worth taking, given the need to get to market as early as possible.