Wouldn't it just make more sense to put our faith behind an existing, cohesive, well-vetted methodology invented and refined - in theory and in practice - by some of the most respected names in the history of software development?
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
This question came up a while back.
In software, one of the most common responses is "it depends".
Most of these things don't matter. At least, they don't matter to the degree that there's ALWAYS a single right answer.
However, we already agreed that there are some things... a small handful... that ARE always right.
If they're always right, we should always do them.
But wait... this felt wrong. Imbalanced. Sort of like inventing our own religion.
Wouldn't it just make more sense to put our faith behind an existing, cohesive, well-vetted methodology invented and refined - in theory and in practice - by some of the most respected names in the history of software development?
After all, one of our favorite phrases is "adopted bleeding edge". We like innovation as much as anybody, but our clients rely on us to build stable systems. If we simply follow the portion of the bleeding edge that has already achieved widespread adoption - especially by individuals and groups respected in the industry - we strike a healthy balance between power and trust.
Extreme Programming (XP) was invented by a few of the 17 signatories to the Agile Manifesto, with the first book on the subject written by the all-stars Kent Beck and Martin Fowler.
Before officially taking the plunge, we all read through the content on the original website (http://www.extremeprogramming.org/), and loved it all.
Scrum is an Agile project management methodology.
XP is an Agile software development methodology.
Both approach project management similarly, but XP has strong opinions on some of the software-specific values and practices that we have and follow ourselves, like automated testing, continuous integration, and more. Some of these are counterintuitive - some would say controversial - like pair programming (description), but there's literature supporting each one from the perspective of adding value to the software development process (and hence to the bottom lines of our clients).
Most literature mentions that pair programming results in roughly the same amount of code produced per developer hour (which means that with 2 developers, it gets done in half the time), but the code that is produced has significantly fewer bugs.
For enterprise clients that trust us to write software supporting core internals of their critical business processes, writing stable and bug-free systems is essential. Facebook may be able to "build fast and break things" while implementing a new post reaction option, but manufacturing companies can't afford to have hours of downtime due to poor quality code.
Oh, and automated tests add another important layer to bug protection.
There's a lot of great stuff online, and many of the books are old enough to be classics (classic because they're old AND still widely adopted/respected, so they must be really good) so that you can find them for $5-10 on thriftbooks.
In any case, here's a short list of some resources we've found helpful: