I wanted to expand a little more on a subtle and incredibly important point that has lead to the success we have been having. Our wall, as described by Greg, has only a single central delivery column "in progress". It is what happens here that makes our new team formation a kinky success.
Traditionally in perhaps an XP style team, you would have dev pairs assigned to a story, which is then handed off to a QA, who writes defects against the story, which the dev pair fix, and is retested and so on. We decided this doesn't work... well at least for very long anyway!! Before long (usually towards the end of a release) cards and defects get piled up into one big traffic accident of a story wall. Any "Individuals and Interactions" goes out the window, whilst we cling to the ceremony of raising defects, reading defects, closing defects, explaining defects, re-opening defects, explain what those changes to the acceptance criteria were you missed whilst at lunch. What is all this craziness? It shouldn't be this hard? Delivering software, should be sexy!
Sexy?
In our new team, we have Threesomes, some times several at once, and I'm not sure what that is even called (never was that adventurous)? No longer are there dev pairs, now there are only delivery threesomes, two developers and a QA. This is the subtle and overlooked part. It is only as this combined unit that a story is delivered.. together as one intertwined collaborative ball of sexiness.
So what are the logistics of this? Surely people will be sitting idle?
Firstly there is the story huddle, which I won't go into great detail as this deserves its own blog post. The acceptance criteria are read together as one team, we get the breaking news on the story and a shared idea of what will be done and expected.
Next the dev pair formulate a plan on how they will deliver the story to the QA. This is a valuable pairing technique, known as micro-tasking and usually involves a bunch of stickies. The stickies break the story up into more vertically sliced, micro end-to-end business functionality (not technical functionality), which can be individually showcased.
The dev pair continually share, showcase and communicate with the QA, who continually explores and probes the virgin behaviour that is just delivered. This continues until the the development work is complete.
Now the crux. If development has finished and QA has not, then the dev pair then submit to the QA, who instructs them at their will to do all that they desire and more. When and only when the QA's appetite is fully satisfied and final climatic showcase has ensued, can the dev pair return to the awaiting pile of stories.
Although, our new threesomes are not faithful within their new found relationships. If when a story is finally complete, there are no more stories to pick up, then attention is shift to new meat in the BA. The developers or QA, remove their current hats and get stuck in with the juicy task of analysis. (There's probably a metaphor in there somewhere, but I won't go there.)
Finally, if we find our dev pair has finished entirely too prematurely, and there is nothing more that can be done with our QA. Then we still do not pick up new stories, but go off to satisfy ourselves, with trusty old tech-debt cards.
Has this Ménage à Trois been successful?
As Greg pointed out, we have only yet raised one solitary defect since October. This was caught and fixed within the Sprint the story was played.
