Bad Habits (and More Than a Little Marketing)
Posted by Greg Wilson on 2009/08/15
Following up the theme of the previous post on habits, this article discusses ten habits developers have to break in order to be successful with Scrum (a popular agile development methodology). A lot of the author’s points are good ones, but others are straw men set up just to be knocked over. For example, “Traditional project management is very stubborn about setting the project plan and sticking to it no matter what,” is a caricature of engineering-style project management. Or take his very first rule:
Often, on traditional projects , team members create trails—written proof to cover themselves. Scrum…values communication and collaboration among team members. Individuals are encouraged to pair with other team members, discuss the story or task at hand, and drive it to completion (and not worry about getting it in writing). Team members must unlearn the mentality of creating a trail and learn to trust and depend on their teammates
Let’s take that one apart:
- People working in traditionally-managed projects also value communication and collaboration—implying that they don’t (without actually saying so) is just marketing spin.
- People working in agile projects who have problems with colleagues or partnering organizations also often keep records, and for good reason: if you ever have to go to your boss (or a lawyer) and say, “It’s their fault,” you have to be able to back it up.
- People working in both kinds of projects should keep records of what was said, by whom, and why, so that newcomers to the project can find out why things are the way they are. Remember, you can’t google a verbal conversation six months later when you’re trying to remember why the highest and lowest values in the array have to be discarded before calculating the average…
The most important thing in this article for me, though, is the complete absence of what anyone in business or science would accept as evidence. If someone tells you that a particular medicine reduces the risk of heart attack in diabetics, you expect them to be able to back that claim up—in fact, you expect them to present their evidence along with their claim without being asked.
Similarly, if I tell you that we’ll sell more candy if we put it near the front of the store, your first question ought to be, “How do you know?” If I say, “Well, it’s obvious,” you’re perfectly within your rights to ignore me from then on. On the other hand, if I say, “We tried it in eight of our nineteen stores and sales went up 22%,” that shows that I’m doing more than blowing hot air.
We’ll be looking at this issue more closely during the course. In particular, we’ll be looking at what constitutes evidence in software engineering, and what we actually know about what works and what doesn’t. If you’d like to get a jump on this, check out Facts and Fallacies of Software Engineering, and then ask yourself how the information in it should shape the way we build programs.