This post originated from an RSS feed registered with Agile Buzz
by Keith Ray.
Original Post: Stop The Line
Feed Title: MemoRanda
Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html
Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics.
Speaking assembly lines, Toyota stops its line when a problem is detected (my emphasis added):
A [one-minute] production line warning can be given as often as 400 times during a shift if members are uncertain about the quality of the part they have received, the performance of a piece of equipment, poor fitting or the member cannot keep up with the cycle time of the job. [...]
During this one-minute period the team leader or engineer who goes to the side of the member who has sounded the alarm must resolve the issue at hand or that part of the line will halt its operations.
This emphasis on quality is considered a Lean Principle. Even though software development is far away from an assembly line, people ask what the equivalent is on Lean/Agile methods like Extreme Programming. Here's the answer: it's the unit tests and acceptance tests. Specifically, unit tests must be passing at all times, and a story is not considered "complete" until it passes all its tests.
If the unit tests are failing, an XP team will stop new development in order to find out why the tests are failing and fix them. This is not just the "stop the line" equivalent, it's also necessary because XP's test-driven-development requires a cycle of write-a-failing-test, write-just-enough-code, see-all-the-tests-pass. If you start with multiple failing tests (not just the one you just wrote), that messes up that cycle. If you can't get all the tests passing with a small amount of coding, that also disrupts the cycle. Those unit tests are there to help you detect bugs -- ignoring them when they fail is letting the bugs breed.
In the case of acceptance tests, the counting of a story as "done" or "not done" when all the tests are passing (or not) has a regulating effect when the "yesterday's weather" rule is enforced. If your team tried to implement 20 stories in one iteration (velocity = 20), and only got 15 stories "done" (passing all their tests, velocity = 15), then the team can only sign up for 15 stories in the next iteration. This gives them time to finish the unfinished tests, and time to make sure the next batch of stories are fully tested as well. This ends up "stopping the line" entirely if zero stories were implemented, otherwise it just slows down the process. The team is responsible for requesting more stories to do if time becomes available, so it's possible for increasing the velocity as decreasing it. (For the sake of simplifying the wording of this paragraph, let's assume that all the stories in this example are the same 'size' -- 1 story-point each.)
Previous Topic
