Reisinger.Tech
I was a fan of Shift Left before it was cool
Early in my programming career, I was lucky to work with a manager who was a champion of Scrum, Extreme Programming, and Test-Driven Development, and dogmatic in his approach to all three. The team was cross-functional, comprised of engineers with various skillsets and QA professionals. We defined the scope of our work with QA in the room, incorporating their feedback on how a feature would be tested and how long that might take into the scope of the task. As a team, we decided we were not done with a task until the QA members of the team signed off that it was working.
When a developer picked up a task, the final step after deploying the code to the test environment was to inform the assigned QA tester that it was ready to be tested. If she didn't like something about it, a short whiteboard entry would be created and we would have a conversation about what to do. We would make the necessary changes right then and there, re-deploying the code to the test environment as many times as it took to get it right. There was literally no delay between the tester's feedback and the code being fixed, because it wasn't done until the tester signed off on it, and we worked on tasks in a tight 2-week sprint cycle.
From this small team of 4 engineers and 2 testers came a ground-up rewrite of the company's flagship product. The team began migrating customers to the new application months after I joined, and we completed migrating customers a few years later - after we achieved enough feature parity for even the thorniest customer to be satisfied. It's no exaggeration to say that we delivered a product of the highest quality, and we did it in a fraction of the time it would have taken if we had not owned the quality of our output as a team.
Needless to say, the units of work had to be small enough to fit into a sprint - breaking down tasks like this was an art as much as a science; however, one clear necessity was that there needed to be something for a tester to interact with to test the output of our work. In other words, we were forced to focus on tasks that added user value, and they tended to be small vertical slices of functionality rather than large features that spanned multiple components of the application.
Years later, I heard this practice described as "shifting left," and it dawned on me that this particular Agile team was doing this practice before it was cool.