Software creation is inherently unpredictable. You can tell how actually agile an organization is by looking at who bears that risk.
-
-
I've been using a "every task/project is assigned to at *minimum* two developers" policy for a few years. It's amazing how even that small tweak changes things.
-
This is interesting. Is each developer assigned to a single task/project or are multiple concurrent assignments allowed?
-
The responsibility for the task is assigned to a pair; they can divide up the work however they want. Lots of pair programming in practice, but people are free to mix it up based on the demands of the problem.
-
I meant can I be simultaneously assigned to work on X with Alice and Y with Bob, or do I only have one active thing at a time? I guess this depends on project/task size. (Trying to figure out how to apply it to a team of 3-4.)
-
We typically queue up a few tasks at the beginning of the week and people do them one at a time. If it seems possible for the pair to finish them all before the end of the week, we find a few "stretch" tasks. It's never a big deal if people don't finish.
-
But we do try to talk about our estimates so that we do a good job of finding tasks that fit the available timing more regularly.
-
(Thanks for answering me. Too much team management advice doesn’t mention sizes of teams, tasks, etc.)
End of conversation
New conversation -
-
-
Dang, this really makes me rethink a number of conversations I’ve had at work lately. Single devs on everything + the lack of trust isn’t a connection I’d made before, but it sure is on point
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
this was my personal take on this from a couple years ago, such as it is https://storify.com/deadprogram/a-better-way-to-approach-development …
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.