I just read an interesting article from DZone called There’s No Such Thing As A “Devops Team”. Readers who have been around a while will know that a flippant title like that is neither going to be totally true, or even the real point of the article. And they would be right. The real point of the article is that silo groups are bad, and silo groups that don’t talk to each other are infinitely worse, and the bigger the [real or imagined] barrier to them communicating, the worse it is. The solution to two teams not working together (in this case the developers and the operations/release engineering group) is rarely to insert another group between them.
This message applies to communication, but also the workflow itself. Whenever you have one team “throwing it over the wall” to another team, you’re doing it wrong. In Agile, we try to avoid that, but even if you consider the develop and test workflow as cyclical, it’s still effectively throwing it over the wall if that’s the first QA has seen of it. Here’s another relevant article by Jurgen Appelo on how Lean/Agile will fail, just like so many other methodologies, if you don’t change how people communicate and work together.
In a recent “sprint 0” on a new project I’m leading at work, I tried an experiment. In addition to the normal planning meeting and story kickoff, I had another meeting about 3/4 of the way through the sprint for Testing Show And Tell. The QA team showed the developers their test plan, and the developers showed QA what they covered, or planned to cover, in their unit tests. This was to ensure both teams knew what to expect at the end of the sprint. It was a big success in my eyes, because it uncovered expectations QA had that the developers had not, and that the QA plan had missed some changes to the acceptance criteria. So much better to have that happen with a few days left than at the end of the sprint.