Agile Otter Blog

Eric Ries has suggestions on why/how to move your engineering practice forward and gain speed and reliability while you're at it: So how can I help the engineering manager in pain? Here's my diagnosis of his problem: He has some automated tests, but his team doesn't have a continuous integration server or practice TDD. Hence, the tests tend to go stale, or are themselves intermittent. No amount of fixing is making any difference, because the fixes aren't pinned in place by tests, so they get dwarfed by the new defects being introduced with new features. It's a treadmill situation - they have to run faster and faster just to stay at the level of quality/features they're at today. The team can't get permission from the business leaders to get "extra time" for fixing. This is because the are constantly telling them that features are done as soon as they can see them in the product. Because there are no tests for new features (or operational...

Here's where I suspect things go wrong. I see a combination of two ideas at the core of a lot of corporate dysfunction. I can want things faster than you can build them. I believe that you can always do more if you really try. The former is obviously true. Wanting is cheap, instantaneous, and unencumbered. I want a car with a 500K mile all-inclusive warranty, Maserati looks and performance, moped operating costs, and a Hot Wheels sticker price. And I want it to drive itself. I am betting that the average reader had at least three improvements they would make to my wish list. None of us expect to see such a thing, of course. The engineering and design costs and material costs make this impossible. Wanting is cheap, but invention and production are expensive. There are material costs, costs of design, costs of errors and rework, costs of research, time and materials. There are human beings who do design, and they like to be paid. It takes them longer to work out the requir...