This post is a response to Liz’s post on Mocks, outside-in, swarming features and guesswork, specifically the bit about swarming. I was telling her how swarming tended to work on the Inkubook.com team when I was there and she asked me to make my comments public… here they are.
How we swarmed an MMF:
1.a – Eric (as architect) and Jacob (as UI/graphics guy) pair on getting the rough shape of the UI doing what it ought to – shaped right, primary interactions at least identified.
1.b – Jeff (dev) and Byron (dev) code the last bits of feature n-1.
1.c – Cathy (test) and Ken (marketing director) provide real-time acceptance of their work both at their workstation and in the pre-deploy environment.
2.a – Eric & Jeff start working on the next layer of collaborators down for the primary UI story, pushing sequentially through the thick client, into the service layer, and when needed pulling in Matt (DB arch, shared across teams) to help with the database scripting bits
2.b – Jacob and Byron start fleshing out the UI and getting the primary interactions working better.
2.c – Cathy finishes validation of the feature n-1 and pushes it to production with Ken’s approval, then starts talking to the devs about what how she’s going to test bits and provides early feedback of how things feel, letting us know where things aren’t right.
2.d – Ken works on the marketing around feature n-1 and provides early feedback to the team about how it looks and what he thinks.
3.a – With the first full pass complete, Eric, Bryon, Jeff, and Jacob work in various combinations to broaden out the feature, generally starting at the UI layer and pushing back towards the DB through the service layer, although we will often pause to design the DB interaction and service layer for consistency with previous work and foreknowledge of likely needs from the current MMF.
3.b – Cathy provides feedback on intermediate builds (multiple/day) while Ken gets demos of the UI at least daily, often nearly continuously during the early stages of complicated UI features.
4.a – When the feature’s nearly ready (based on Ken’s opinion of “market ready” and the team’s opinion of “production/quality ready”), Eric and Jacob spin off to start the next effort with Ken’s deep input.
4.b – Jeff and Bryon finish up the feature with Cathy’s help and the cycle starts anew.
5.! – Every week or two, James (director of IT) brings in a decent (not just pizza) lunch to celebrate how things are going.
That’s generally how things flow, but not always, and since I’ve been gone a few months I’m sure it’s an idealized version of how things actually worked, but that’s my memory. The names and roles where what things were, but they weren’t strict by any means, and people filled the roles that were needed at a given time.
The important part from a flow perspective is that a pair gets into the feature a half-day or day ahead of the rest of the team. Thus, instead of a single “point” (the UI) preventing parallel development, we can instead create the skeleton of that first feature and then continually tie more work onto it. We rarely attempted to declare what “done” meant before starting the feature, instead starting with a vague goal and developing it in collaboration with Ken, who spoke for the broad customer base.
Please note that it took quite a long time to get to the point I described, and we tried a number of variations as team, which I speak about here. I imagine things have changed since then, as the team was generally very good about adapting the process to fit what needed done.