My friends know me to be skeptical of “studies” about software development techniques. The main reason for my skepticism is that such studies are rarely undertaken by people who have any understanding of what they are studying. They combine data points from different sets of observations as a way to try and accumulate sufficient information to make charts and trend lines, but often the data points aren’t consistent enough for the aggregated data to be meaningful. I wonder whether many studies of programming techniques are based on enough observations to be meaningful, and whether the researchers’ analysis of the results is based on any direct knowledge of the subject at hand.
In episode 79 of Dave Saboe’s excellent podcast series, “Mastering Business Analysis,” Dave interviews Paula Bell about effective collaboration. Here’s the link: http://masteringbusinessanalysis.com/mba079-effective-collaboration/
One point in particular stood out for me in this episode: “It can be challenging to collaborate under the pressure of deadlines. It’s worth taking the time to get to know one another and to some team building.”
It reminded me of situations that were common in the 1980s in corporate IT work: The “sweatshop” environment, in which working life comprised an unending series of death marches punctuated by physical/mental/emotional crashes.
- Agile: It’s only a model
- Keep trying until you find a way that works
- We tried agile, and it didn’t work
- Scrum: The Three Questions
- Self-organizing teams
- The coach knows all
- We’re not ready to try [insert practice here]
- Alignment and communication of requirements
- The value of comprehensive documentation
As an agile/lean coach and “change agent,” I often find myself working with dozens of individuals at the same time at any given client. I’m not a great fan of “assessments,” but I do need some practical way to keep track of where everyone stands and how they tend to think and collaborate. To do that, I consider the following factors.
Do people resist change? The consensus appears to be that they do.
- Changing Minds (many articles)
- Prosci (models, tools, training)
- Harvard Business Review, “How to deal with resistance to change”
- Forbes, “Overcome the 5 main reasons people resist change”
- Human Resources at about.com, “How to reduce resistance to change”
- Small Business Chron, “How to overcome resistance to change in an organization”
- Computer Weekly, “How do I overcome resistance to change?”
- Paycor, “Change management in the workplace: Why do employees resist it?”
- “Overcoming resistance to change – isn’t it obvious?” (Video, script by Eliayu Goldratt and Ilan Eshkoli)
Well, with all that consensus floating around, I guess resistance to change must be a Thing. It’s hard to argue with a million articles that all say the same things.
On the other hand…not everyone sees it that way.
So, there’s this idea floating around of technical debt. There are some nuanced definitions, but in general it means bad design baked into the code. The “nuance” has to do with why bad design is baked into the code. There are a lot of debates about this, and you might wonder why, as it isn’t intuitively obvious how anyone could argue in favor of baking bad design into their code.
Yet, they do.
Different people have different ideas about the current status of the “agile” movement in software development. Different people have different ideas about what “agile” even means. Having been involved with “agile” development since 2002, I’ve had the opportunity to observe an interesting trend: We’ve been gluing a lot of things onto “agile.” Now it may be time to pry some of those things off and get back to basics.
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.
Continue reading The mother of all management anti-patterns
It’s a familiar adage among engineers, often posted in work areas. Does it pertain to software development? The seemingly endless circular debates about software delivery methods lead me to think so. The latest chapter in the ongoing drama is the recent schism between Lean Kanban University’s flavor of Kanban Method and the rest of the lean/kanban community. And the paint hasn’t yet dried on the sumo match between Kanban and Scrum. A few years ago (mid-00’s, as memory serves) the same debate (except for the names of the methods) raged between proponents of Evolutionary Project Management (Evo) and Extreme Programming (XP). Prior to that, we kept ourselves entertained by debating whether RUP was Agile. Before we could do that, we had to settle the debate about the relative merits of Spiral and RUP, of course. And Spiral vs. linear SDLC processes. Tomorrow, next week, or next month, it will be something else. Important questions, all.
Yet, I can’t help noticing, as Ron Jeffries puts it, it’s all the same elephant. When I stopped arguing and started listening to the elephant, I heard it say "Don’t do anything stupid on purpose." What does the phrase mean in the context of software development and delivery? To explore the question, I think it would be helpful to define the terms stupid and on purpose for that context. Continue reading Don’t do anything stupid on purpose
From time to time, something happens that reminds me that our espoused theories aren’t always congruent with our theories in use (see this summary for some quick background info on those terms). The author of an article I had cited as an example of "binary thinking" posted a comment asking how I had gotten the idea that he was pro- or anti- anything. I took the question literally, and started thinking about how any of us might get the idea that another practitioner was pro- or anti- any given software development practice. Continue reading What development methods and practices do you support?