ahdinosaur
commented
9 years ago :+1:, this is something i need to improve on.
an interesting facet of this is that if the commitment is vague (e.g. 'deliver a read-only interface of Holodex to Enspiral Services'), we may have differing interpretations about what completions means which may lead to different parties thinking they are committing to different amounts of work (e.g. i didn't expect we would deliver as much as @simontegg did, but that being said i still fell short of my own expectations for myself). probably means the tasks we commit to should be as small and focused as possible (i.e. individual patches) as opposed to large milestones, but then again we at some point do need to have some certainty on our ability to deliver on large milestones, so i don't know.
Value: signaling our availability and commitment to tasks reduces the uncertainties around who will do what by when This make communication with external stakeholder easier and increases trust within a team. In software development, as in any other pursuits, these commitments should be considered soft.
Tradeoff: Making a commitment to be available and to deliver particular things in a particular timeframes reduces the autonomy of the person performing the task. This may impact the intrinsic motivation for the task.
Note: In a scenario where a critical mass of developers swarm on tasks (as in large-scale open-source development ) this signalling will be less important than in small team scale development. (Competence to minimally complete a task will be available in the pool of developers, Developers will compete for the social proof for completing a socially valued task, reducing risks that important tasks will go uncompleted).
In a small scale project the dynamic is different: The long AWOL of a developer from important tasks will degrade trust within a team.
Potential conflict: http://hintjens.com/blog:23#toc10 'Task and Role assignment'