Note: This was originally published on the Scrum Alliance website, here: https://www.scrumalliance.org/community/articles/2014/september/choose-your-own-workflow
High-performing Scrum teams run like a hot knife through butter. They move so fast that job titles become a blur, and last week’s impediments seem like a distant, faded memory. I want to focus for a moment, though, on an impediment that many teams oversimplify — or, in some cases, ignore altogether: work flow.
A quick scan of most Agile literature will yield a common theme around work flow. Tasks or SBIs go from “to-do” to “in progress” to, finally, “done.” Simple as pie, right? While it sounds tempting, keeping your work flow so simplistic may result in missing out on some excellent opportunities to learn how to work together as a team.
A major principle of Scrum is the reduction or out-and-out removal of the concept of the “hand-off.” Many people who are new to Scrum will take this literally — no one should ever hand anything off to another person, ever. You take your bit of code all the way from your brain to production. This interpretation is actually quite anti-Agile!
Instead, adding some explicit steps in your work flow to act as “collaboration checkpoints” could be a great way to foster collaboration at the task level. An example:
Before your bit of code gets merged into the main branch, wouldn’t it make sense to grab a nearby tester or designer for a quick “quality review” right at your desk? I’m not talking about the usual kind of pair programming that all great teams should be doing. I’m talking about showing your working piece of software to some team members who can tell you just how well it’s “working” well before it ever hits a staging environment. Performing a quick collaborative check like this before you show the code to the rest of the developers for review will greatly reduce the amount of churn between coding and testing, especially if your automation testing isn’t quite where you’d like it to be.
This is just one example of an explicit work flow step that can have a powerful impact on your team’s ability to ship working software at the end of every sprint. What are some nontraditional work flow steps you’ve tried out with your teams?