We've emphasized the importance of getting everyone involved in automation. Here's how it works in my department. An integral part of each development team, the DevTester writes and executes manual test cases for the team's user stories. The tests are written using a methodology (see connect manual tests with automation using a clear methodology) that clarifies how to automate them later on. Once a feature is stable, the DevTester writes the actual automation tests. Then, there's the Developer. In addition to developing the application, the developer works with the DevTester to review both the test's design and the testing code itself. The developer's involvement in the automated tests increases his or her engagement in the automation efforts, which also means the DevTester can help with test maintenance should the need arise. The QA architect is an experienced QA professional who is instrumental in deciding which feature tests should be automated. This is the person with the higher-level view of the overall testing effort who can understand which test cases will yield the best ROI if automated. With a broader view of the application, the architect is also responsible for cross-feature and cross-team QA activities to make sure that end-to-end testing can also be automated.
I think we can all agree that automation is a critical part of any organization's software delivery pipeline, especially if you call yourself "agile." It's pretty intuitive that if you automate testing, your release cycles are going to get shorter. "So, if that's the case," you might say, "why don't we just automate everything?" There's a good reason: automation comes with a price.