I'm not an Agile zealot, but I'm also not a complete hater (of which there seem to be many, many nowadays). With that disclaimer out of the way, there's a part of Agile (specifically, Scrum), that I've always been fuzzy on.
The team goes through sprint planning, grooms the work, plays their little poker games, yada yada, and eventually gets to a set of work items that it endeavors to accomplish in the upcoming sprint. Great. Now what? Specifically, how do those work items get into the hands of individual developers? In other words, how does the work get assigned?
The simple solution is "central planning", and though this fundamentally contradicts the self-organization edict of Agile, it is, in my experience, the model which many teams use. The project manager/scrum master/tech lead has some intuition as to which developers would be best suited for which work, and goes about assigning stories/tasks based on that understanding. The end goal here is expedience - rather than a long drawn out discussion, let one person make the judgement call on who is the optimal person to complete a given piece of work.
The problem, of course, is that while this may optimize what's good for the project, it doesn't necessarily satisfy the goals of the individuals. A team may plod along with the "central" model for a few sprints, but it won't be long until some tension and resentment foments: "why does Jane get all the fun UI work?" or "I'm so f-ing sick of working with the accounting module", etc. Basically, we developers all want some degree of autonomy and self-direction, and so we'd like some choice in what we work on.
And this of course is why one of the pillars of Agile is self-organization. The problem is that there's no good, thoughtfully specified process for assigning work items, and so teams can instead end up adopting what amounts to a Hunger Games-style free-for-all. Planning is over, the work is ready, the horn blows, and the team rushes to their laptops to grab the work they want. This is probably an exaggeration - maybe instead there's a post-planning discussion where developers make dispassionate arguments as to why they should take the fun, new feature and someone else would be better off making a small enhancement to the registration form. In any case, the same tension and resentment can build, but this time directed at each other rather than the lead.
A solution that we've stumbled on (and have now used on a few projects) is the fantasy draft. At the risk of explaining the obvious, here's how it works:
- Sprint planning happens. Work for the sprint is identified, prioritized, and estimated (or not).
- Each person on the team picks a number out of a hat, bag, or container of preference.
- The team comes together for the draft.
- Starting with the first pick (duh), work items are chosen one-by-one until there is nothing left.
There are subtle refinements to this process, of course. We've instituted a clock (2 minutes per pick!), a looping scheme (2nd round goes in reverse from last pick to first), and a carry-over rule (work unfinished in a previous sprint is automatically carried over to the same developer). We've also considered "franchise players" and allowed draft pick trades.
In general, it works pretty well, and, if nothing else, is a lot of fun. Draft day comes with all the frivolity that you'd expect from a fantasy draft - someone wasted their first round pick on a trivial user story, someone couldn't pick in time, etc.
Beyond the fun though, the draft system has some other nice qualities, most notably fairness. People are in control of their own destinies. If they get the shaft this sprint with a shitty draft pick, well, next sprint they'll likely do better. It also distributes the "fun" work more equally. If the UI is the most desirable tier to work in, with the draft system it's more likely that most people will get an opportunity to get their hands in there in some capacity. This might come at the price of efficiency, but definitely aids maintainability and knowledge dispersion.
There are, of course, some downsides. The most obvious is that it gives no preference to seniority or capability. That complex integration piece can be picked up by the a junior UI developer if he so chooses. On the flip side, the most senior developer might get stuck writing the 93rd login form of their career (and be none too excited about it). As a "senior"-type person, admittedly, this can suck.
Anyway, I write this less to advocate the fantasy draft as the model that you should use, but more as a way to find out what others do on their teams. How is work assigned? What are the pros and cons?
Thanks to Handerson Gomes for the pictures!
