Rhythms as Agile Diagnostics

• get feedback at this rate. So if our team takes three cycles to learn from a mistake, that is a learning cycle of twelve weeks. As a result, we, the team, are less agile.
• Developers' estimates are inaccurate and thus they are likely to miss task completion with longer iterations. The most common solution here is to change velocity, but remember that velocity can only be adjusted every cycle (which is our iteration length).

Daily Stand-Up Meeting
Daily stand up meetings are the control for a healthy iteration. They give the team members an opportunity to get a complete picture of the current state of the project within the iteration. They also provide the chance to catch impediments early and have them removed in order to assure successful completion of the iteration goals. With the exception of the initial stand up meetings (not beyond the first iteration of a project) these meetings should be short and to the point. They should be reports of progress made and impediments encountered or removed.

So when do you know you have a problem? Firstly, the most notable indication is a lengthy meeting - more than 15 minutes should get you wondering, past 30 minutes should have you worried, a full hour and the stand up meeting is broken. Secondly, we find that many people revert to standard meetings where design is discussed or planning for the future. This is not the time or the place for these things to be discussed. Thirdly, if the chickens are talking or leading the meeting then the value of the meeting as a status and control meeting is compromised [1].

Story Task - Continuous Integration Cycle
The continuous integration cycle is very dependent on the check-in rate of the developers. A continuous integration build needs to be fast enough that a build can be run before too many developers check in. If the build is not fast enough and breaks then several developers may have checked in since the last good build. Of course, each one of them assumes that he or she did not break the build. They will therefore not fix the build since their belief is that one of the other five developers broke it. The build will therefore remain broken.

This is the beginning of a long, slippery and dangerous slope. Broken builds and broken tests should never be tolerated. They not only let small problems, indicated by a simple broken test, to become larger problems by having more tests break but they also desensitize the development team to broken tests. Moving from 0 broken tests to 1 broken test is much more traumatic than moving from 100 broken tests to 101 broken tests.

Broken builds and broken tests usually point to one of two possible problems: either the build is too slow, or the team's discipline with respect to failing tests needs to be improved.

Red-Green-Red Loop
The red-green-red test cycle is only present during test-first development. When it is present it should be extremely short, on the order of a couple of minutes to 15 minutes on average. If tests cycles are consistently taking 30 minutes or more to write and execute then this is a possible indication that the development steps being taken are not granular enough or that the system under test has an unhealthy degree of coupling. We have seen (and sometimes participated in) test cycles of 4-12 hours - these definitely indicate that there is a problem. In many cases unit tests have grown into system integration tests and trying to juggle an inordinate amount