In the spirit of end-of-year top 10 list I thought I'd try my hand at one of my one. Changing a culture is all about changing behaviors so here is my take on where to start and the baby steps down the road towards transformation.

1. Establish Release Authority - Sadly, this most fundemental of points still needs to be explained in many organizations. Even if you already have a Build System, it's important to remember why that's important as well. This idea I learned pretty early on from Anti-Patterns and Patterns in Software Configuration Management. If you still have developers building localy and emailing artifacts, then you are indeed starting from scratch. Release Authority is the most foundational of concepts upon which everything else is built.
2. Build Your Code with Every Commit - I'm avoiding saying CI here intentionaly since I'm trying to build in baby steps. Be it polling or triggers you need to know that code still, at least, compiles. Keeping the build *green* at this stage is an important cultural norm to establish. Once the build it broke, deal with it. Stop commiting until it is fixed or rolled out. Bring shame to anyone who commits broken code.
3. Unit Test - It is simply too easy to turn on automated unit testing to not be doing it. Be very clear about what is, and isn't, unit testing. The term is all-to-frequently missused. Always ask if unit testing is being done and if the answer is *yes* make them explain exactly what they mean by that. Too often it means a local build was done and they clicked a few things to test there functionality/widget/fix which is NOT unit testing. Unit testing is one more small bit of assurance and not a silver bullet by any means. It is also another level of pre-commit validation and as such folks whose commits break the build should be publicaly embarrased and ridiculed ;-)
4. Scan Your Code - Much like unit testing it is simply too easy to do this these days not to be doing it. The richness of these tools vary by language but find what your language offers and leverage it. Static and Dynamic analysis, like unit testing, is not a silver bullet but then quality is like security and needs to happen at every step along the way (read Caper Jones if your not familiar with this idea). Java shops should look into Sonar if you haven't heard of it. These tools are a lot like the cockpits of an airplane, they wont fly the plane for you but they provide lots of feedback to help you make informed decisions.
5. Get Control of your BOM - If you cannot easily show your Bill-of-Materials you're probably not in control of your product. Putting third party liberaries into you SCC tools doesn't count either since you can't prove what is actualy used or not or where they came from or if they've been tampered with. There isn't really just one thing to do to get control of this so the next couple of items on the list will try to identify the 'How'.
6. Setup a Binary Repository -  I can still remember a time when not everyone was using SCC but it didn't take too much convincing to get everyone on board. Today, binary repositories occupy that distinction. Checking your binaries back into your SCC tool is not the answer either. Tools like Artifactory and Nexus do the job well and can be had for free.
7. Manage your Dependencies at Build Time - Maven paved the way here but there are several alternatives these days. If your an Ant shop, look at Gradle as the way forward. I'm still a big fan of Maven but Buildr has got my attention as well.  Either way modern build tools can help you manage your dependencies with the Binary Repository. At this point we have a basic CI system.
8. Automate Deplyment to Dev - Much like #1 was foundational to every else after it this item is the foundation upon which we can build a Continuous Deployment/Delivery system. By focusing on one environment and driving toward zero-touch, self servicable deployments we can pave the way for everything to follow. It's a huge task so stay focused on Dev. Up until now we could have done most everything for free but this is where we'll likely need to spend some money. With that in mind get in touch with your companies budget cycle and give yourself lots of time to make the case and garner support. Much like getting control of the BOM was a huge task, this one is even bigger, much more complex and varried. To that end the next couple of items will shed some light on the 'How'.
9. Think About the Functional Decomposition of your App - Continuous Delivery taught me that we can functionaly decompose an into 4 pieces: Code, Configuration, Data, and Environment. The first 7 items in this list focused on the code and now that we want to deploy it's time to think about the rest. A deployment pipline tool like UrbanDeploy or DeployIt can help a lot with middle tier configuration and even DB changes.
10. Think About How Every Can Collaborate on Testing - Automated testing has a long and not so rich history in software development. Virtualy any enterprise that has tried will tell you that it doesn't work, I'm here to tell you they were doing it wrong! Tools like QTP and testing through the UI are simply the wrong aproach. What's really needed is a tool(s) that everyone can use so that we can think about the life-cycle of a test. How do new test get written? and more importantly, how are they shared? How does a defect become a test become a regression test? We also need to think about more than just functional testing. We need to consider Smoke Test and Performance Test and how we bake these into that automated deployment. We need to think about which test get run when and how long they take.. I'm going to read Agile Testing in the hopes that it can help me here as this is precisely where I am today.
11. Specification by Example - Ok, I said 10 and really this is a part of #10 but worth it's own entry. Specification by Example is quite possibly the most important advancement in Software Engineering since OO was introduced, at least in my opinion anyway. And while I'm no fan of Silver Bullets this may well come the closest to being one. If 2012 is the year of breaking down silo's then Spec by Example is one example of how to do that when the Business and Developers learn to write the spec together, derive scope from that spec and ultimately turn it into an executable scenario/test.