Mythical Agile Shortcuts
We write unit tests, but it doesn't matter if they pass or not
Writing unit tests and automating them into the build is an obvious best development practice. While many people are willing to write unit tests, they are not necessarily diligent about maintaining them.
We pair, but only when we have trouble
Pairing is often considered a "nice to have" rather than an absolute necessity. The reality is that pairing maintains consistent throughput of Agile teams, as well as the great team benefit of knowledge sharing.
The work we do doesn't lend itself to Agile "stories" so we track to technical tasks
Teams define work not as an end to end story but as a task. Requirements are structured as statements of technical activity for developers, not as user-valued features understood by the customer. Often its easier for technical teams to produce collections of technical tasks and try to pass them off as Agile stories.
Petit concludes: "A shortcut is the longest distance between two points." It seems half-done Agile may be even worse than the monolithic procedure it's aiming to replace.
Pair Programming required?
Also, we are constantly struggling to keep the stories from being technical stories, especially when our product owner is very technical himself. I still wonder though, how do Agile teams include all of the work that is required just to produce and maintain the build process? We constantly struggle with how to insert these items into the iteration and weigh these "maintenance and upkeep" tasks that the owner really doesn't see (other than they contribute to the overall production of the finished product) against the stories the product owner has already prioritized, .
Tim Ferguson, xaware.org
The implication "All or Nothing" is misleading
"half-done Agile may be even worse than the monolithic procedure it's aiming to replace"
If you are not doing Agile today and you start doing agile tomorrow, can you move from 0% Agile to 100% Agile all at once? The BIG BANG may work in physics, but human processes have to move more gradually on an evolutionary scale.
Read a book on Agile development, like Jim Shore's latest book...there is WAY TOO MUCH to do it all at once. By the time you get to everything in the book...there will be a new and better book...