On Programmers, Deadlines and Agile
A large part of the Agile development movement can be pinned down to self-evaluation of development practices – why did it even gain momentum as a movement if not to help evaluate and inform better workflow? Blogger Michael O. Church wrote a comprehensive post about the culture of programmers in Agile environments, particularly with respect to arbitrary or non-external deadlines.
Specifically, Church comments on the reality of estimates, especially when it comes to environments where continuous releases are favored.
Worth noting is that there are two types of deadlines in software: there are “this is important” deadlines (henceforth, “Type I”) and “this is not important” deadlines (“Type II”). Paradoxically, deadlines are assessed to the most urgent (mission critical) projects but also to the least important ones (to limit use of resources) while the projects of middling criticality tend to have relatively open timeframes.
In a field saturated by agile thinking and scrum mastering, Church holds the dissenting opinion that the organized "story points" and "standups" are actually harmful to programmers' work ethic.
This, by the way, is why I hate “Agile” so vehemently. It’s all about estimates and deadlines, simply couched in nicer terms (“story points”, “commitments”) and using the psychological manipulation of mandatory consensus. Ultimately, the Scrum process is a well-oiled machine for generating short-term deadlines on atomized microprojects. It also allows management to ask detailed questions about the work, reinforcing the sense of low social status that “conventional wisdom” says will keep the workers on their toes and most willing to work hard, but that actually has the opposite effect: depression and disengagement.
It's interesting to see this take on the tenets of agile development, as it is often taken for granted as the way to do things. Check out the full post here.