Having recently finished the above two heretical books on the undiscussable joke that is “the Annual Performance Review“, I coincidentally stumbled upon this recent FastCompany.com article: “Why Year-End Reviews Are A Big Fat Waste Of Time”.
Alas, even though author Denis Wilson plants some decent advice for managers in the blarticle, it still reeks of a slight “tweak” to the notoriously bad, but eerily unopposed, APR practice.
After posting the link to the blarticle on Twitter, I had this interesting exchange with Adam Yuret:
Upon reflection on why such a horrendously demeaning practice like the APR still exists in the 21st century, BD00 has come to the conclusion that the guild of management collectively thinks:
- The APR actually “works” or,
- They know it doesn’t work but they have no motivation to attempt such a big and scary change to the org, or
- They know it doesn’t work but they have no motivation to explore alternatives for achieving what the APR is actually supposed to do.
In the software development industry, going too slow can result in nothing getting done in an “acceptable” amount of time and thus, impatient managers cancelling projects. On the other hand, going too fast can result in hackneyed designs, halted downstream progress due to lots of rework on an unmanageable code base, and thus, frustrated managers cancelling projects.
As the figure below shows, the irony is that going too slow can result in less sunk cost due to earlier cancellation than going too fast – which gives a false illusion of great progress till the fit hits the shan.
So, how do you “objectively” know if you’re going too fast or too slow? It’s simple: you freakin’ don’t. However, in a world increasingly dominated by “agile” indoctrination, faster seems to be always equated with better and the tortoise vs. hare parable is heresy.
I don’t know where I read it, but I remember someone giving great advice about using “I-Speak” to present your case on a sensitive issue. Don’t go blasting away and saying stuff like “everyone thinks the system is a freakin’ disaster“. Instead, say “I have a hard time using the system as it’s designed“.
In really uptight and unresponsive groups, preface your concern with “I can only speak for myself, but…“. But don’t forget, in zero tolerance bureaucracies, keep your “I” trap totally shut tight and keep toiling along in quiet desperation.
The underlying assumptions harbored by executive decision-makers drive an org’s processes/policies. And those processes/policies influence an org’s social and financial performance. As a rule, assumptions based on Theory X thinking lead to mediocre performance and those based on Theory Y lead to stellar performance. Most org processes/policies (e.g. the annual “objective” performance appraisal ritual) are Theory X based constrictions cloaked in Theory Y rhetoric – regardless of what is espoused.
Since they generally increase operating costs, trigger “it’s not my job” myopia, and encourage us-vs-them friction, I’m not a fan of unions. Nevertheless, I found this article on TechCrunch.com amusingly interesting: “Want To Unionize Developers? Focus On Workplace Democracy”. This passage caught my eye and triggered a chuckle:
Developers want autonomy. They don’t want to be jerked around by stupid managers who impose unrealistic deadlines, make impossible promises to clients and just generally disrespect their employees. Historically developers have had two options for dealing with bad management: find a better job or found a startup. But worker self-management would offer a third options — give the developers control over their own work.
Alas, those managers that are stupid don’t know they’re stupid and those employees who are disrespected don’t know they’re disrespected. Between: 1) these two BD00 made-up facts; 2) management’s fear of loss of control and stature; 3) the declining reputation of unionization over the years – don’t expect the idea of software developer unions to take hold soon; if ever.
Scrum is an agile approach to software development, but it’s not the only agile approach. However, because of its runaway success of adoption compared to other agile approaches (e.g. XP, DSDM, Crystal, FDD), a lot of the pro and con material I read online seems to assume that Agile IS Scrum.
This nitpicking aside, until recently, I wondered why Scrum catapulted to the top of the agile heap over the other worthy agile candidates. Somewhere online, someone answered the question with something like:
“Scrum is king of the hill right now because it’s closer to being a management process than a geeky, code-centric set of practices. Thus, since enlightened executives can pseudo-understand it, they’re more likely to approve of its use over traditional prescriptive processes that only provide an illusion of control and a false sense of security.”
I think that whoever said that is correct. Why do you think Scrum is currently the king of the hill?
How many institutions are still being managed in accordance with the knowledge learned from 17th century physics? These days, its networks and relationships, not billiard balls and force.
The CMMI-DEV model for software development contains 20+ Key Process Areas (KPA) that are required to be addressed by an org in order to achieve a respectable level of compliance. With such complexity, one could think that L3+ orgs would sponsor periodic process refresher courses for their DICforces in order to minimize social friction between process enforcers and enforcees and reduce time-sucking rework resulting from innocent process execution errors made by the enforcees.
BD00 postulates that many CMMI L3+ orgs don’t hold periodic, rolling process refreshers for their cellar dwellers. The worst of the herd periodically retrains its technical management and process groups (enforcers) , but not its product development teams (enforcees). These (either clueless or innocently ignorant) orgs deserve what they get. Not only do they get blown budgets, busted schedules, and bug-riddled products, but they ratchet up the “us vs. them” social friction between the uninformed hands-on product dweebs and the informed PWCE elites.