So after talking about different post-agile aspects of software, lets get very conservative, and potentially more constructive, as it's sometimes easy to forget that many people aren't at that point. If you start out, or are stuck, stop the line and do two things:
Implement Extreme Programming by the book.
Extreme Programming has many counterintuitive aspects to it, but you can remove them later. Don't underestimate the Customer role and how much time and involvement is required, as this is often a place where wasteful documentation may pile up - or, even worse, no useful communication - it's surprising how many people are prepared to spend money on teams lacking direction. I spent several years of my life trying to solve this exact problem by participating in building Twist, call it BDD, ATDD or Specification by Example - actually, reading Gojko's Key Ideas could be the best thing you do today, or even this year - see also Dan's post Who's Domain is it anyway. I had the pleasure of seeing Twist again for the first time in over a year and it has come a long way now.
The reason why I would recommend such an prescriptive process that is more than 10 years old is that a lot of the meta debate about agile is not what the focus should be on. Starting with XP is as good as any other, or let's be frank, probably the best, point and it will save you loads of time by not trying to avoid some of the more inconvenient parts of delivering software. Fail fast and have fun doing it. Pairing gets lots of bad rep these days, and pairing all the time will do you in, as it's very intense and not suitable for all kinds of tasks. It's extremely useful as a learning tool though and it naturally counters attempts at headphone-driven-development and builds the team spirit.
Implement Continuous Delivery by this other book.
This is a very important book as it actually talks about delivering software and not how to optimise your card wall. I was somewhat surprised when reading it that thinking "surely this book must already been written?" But no, instead it tells you things that only working on good teams for a long time can teach you. Talk about misunderstanding the scope of the problem and how much you learned to take for granted by working with people like Jez and Dave (and many others at ThoughtWorks). This is an awesome book, and unlike Extreme Programming it doesn't really contain many pieces you will eventually want to remove having once implemented them. On the other hand it covers loads of ground, so certain pieces won't be applicable to your situation.
I recently used the phrase "programming is like a fractal tree of feedback loops", to which Vivek (the tech lead of Twist) replied, "I don't have any idea what that looks like" and my only reply was "I know, but it sure is what it feels like!" If you want a better explanation without my attempts to understand software, read this book, written in clear English by native speakers of the language.
Courage is one of XP's values, and actually doing the "right" things and avoid fighting broken processes are actually easier. The most important piece of XP is to eventually safely dare to move away from its rules. This can take years. I have long avoided entering any debates about agile, and that's still my plan. I will just keep posting some of my ground rules on this blog to keep it DRY. My natural answer to most of these things is "it totally depends", but in reality that's not true when you break the build and I have to deal with it.
So I admit it, there are some rules. And break rules, not builds.