My book on software development metrics is in the final stages of editing. The editor made a kind comment about one section of the book. She wrote: “This section is marvelous. I wish all management everywhere would read this and pay attention.” Me, too. This is the section:
This may be the mother of all management anti-patterns. Management science has treated human beings as interchangeable machine parts at least since the time of Frederick Taylor’s “scientific management” in the early 20th century, and possibly much longer than that. Even today, many managers loosely refer to workers as “resources” without realizing the implications of the word.
People who’ve been in the IT field for some years tell tales of the bad old days when every project ended in a Death March. Well, actually, no one died. Truth be told, no one marched, either. But we called it a Death March. Some call it the Death March Antipattern. It was, in fact, one of the reasons people became interested in exploring alternative approaches to software development.
Younger professionals have managed to avoid the Death March Antipattern, for the most part. When oldtimers tell their tales, many of the younger folk react as if they were hearing Monty Python’s Four Yorkshiremen sketch, in which four retired gentlement reminisce about the difficulties of their youth: “There were a hundred and sixty of us living in a small shoebox in the middle of the road.” “You were lucky. We lived for three months in a brown paper bag in a septic tank.” “But you try and tell the young people today that…and they won’t believe ya’.” “Nope, nope.”
But it was real. On a typical 12-month software development project, the first ten months would be spent preparing useless documents and snoring through useless meetings. With the deadline looming, the team would scramble to get as much of the work done as possible in the remaining few weeks. It meant working 24×7 until you delivered, and then crashing for a few days. That was the Death March. And it had much in common with modern-day “agile” development practices.
What skills does a technical coach need?
One of the goals of my present coaching engagement is sustainability, defined as the ability to continue with the improvements after the coaches are gone. To that end, we’ve been identifying internal people who have the potential to become effective technical coaches. One manager asked us for a short list of key skills that a technical coach ought to have. Answering that question has been quite a challenge. It occurs to me that other people may be asking the same question, so it might be useful to discuss it publicly.
This post by Thomas Schranz caught my attention: Why SCRUM Backlogs lead to bad Product Decisions. One finds numerous articles against Scrum on Thomas’ site. I think he misunderstands Scrum fundamentally.
Is my purpose here to defend Scrum? Friends and colleagues will know that I’m not a Scrum salesperson. I see Scrum as a tool, and not as the answer to the ultimate question of life, the universe, and everything. So, why defend it? My purpose in this post is to caution against blaming one’s tools for one’s results, and to suggest that we try to understand a thing before we criticize it. (I don’t claim to be a flawless practitioner of my own advice.)
I’m planning to delete several github repositories. If you want any code from them, please take it before the end of March, 2015.
There’s a huge interest in failure these days. People are clamoring to be the first to fail, to be the one who fails most frequently, gleefully to fail and fail and fail. Question: Why do you want to adopt [popular method]? Answer: So that we can fail more!
Nadie habrá dejado de observar que con frecuencia marcos del proceso se aplican mecánicamente.
Maybe Julio Cortázar, whose 100th birthday we celebrate this year, would have begun a set of instructions for implementing a process framework with similar words. No one will have failed to observe that many individuals, teams, and organizations are quite befuddled by the process framework they are trying to use. They struggle mightily to follow every “rule” the framework “requires,” even when their goals are ill served by those rules.
Indeed, it is typical for such individuals, teams, and organizations to lose sight of their original goals altogether in their attempts to satisfy the real or perceived “rules” of the process framework. No matter how haphazard their previous mode of work may have been, many conclude that the framework “doesn’t work,” and revert to their former methods.