The idea of a feature team that incrementally delivers vertical slices of application functionality is central to many “agile” software development organizations. A feature team possesses all the skills and resources necessary to deliver a customer-centric software feature end to end. How feasible is this model in a large corporate IT environment?
As a middle manager in a large corporate IT department, you feel as if
- you are in the middle of an accordion
- and the accordion is being played by a monkey
- and the monkey has taken some sort of unknown street drug
- and the strange music the monkey is playing makes no sense to you
- and your bosses think the monkey is a genius
- and your subordinates think it’s all your fault
- and you don’t see how it could possibly be your fault
- and you’re not even sure what “it” is.
You never know whether your job will survive the next re-org. Furthermore, you’re not even sure that your job adds much value to the organization: In a nutshell, you (a) take direction from above and disseminate it downward, and (b) collect data from below, compile it and report it upward. You don’t know how to run the business from the top. You don’t know how to do the hands-on work at the bottom. You have only a vague idea of what’s going on. You can’t trust any of your peers. What will happen to you if your present position is eliminated?
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.