Low Discipline Methodology
Low Discipline MethodologyThis question was asked in HighDisciplineMethodology... "Alistair, please tell us about LowDisciplineMethodology and whether they can work. Thanks! -- RonJeffries" ...This was followed by quite a long response by Alistair and a discussion... I think some of that response and discussion could very well belong on this page. -- OleAndersen.
p.s. See HighToleranceMethodology for discussion of tolerance as opposed to low discipline. --Alistair
''Is this the right stuff to copy over here? ... you who requested it should perhaps trim it to the smallish stuff to you want to seed this page with."
AlistairCockburn: My observation was and is that most software teams are really (astonishingly) sloppy in their habits. And yet, software has been coming out for 40 years. So what is there to do? One route is to get them to adopt better habits and, ergo, have a higher / faster delivery rate. The route I'm testing is to permit them to be their usual slapdash selves as much as possible, and try to detect the minimum discipline they need to get the software out. (I usually find the minimum I think is necessary is more than they are willing to do.)
LowDisciplineMethodology is what every project I have visited, with the possible exception of C3, has used, and what has been used by most groups that have shipped software (as well as by many groups that have not shipped software). It is just the norm. Discipline is one of the failure modes of humans. The way I usually break a declared methodology is to look for the discipline areas, then ask people if they do that part. They usually say, "no". So they don't actually use the methodology. They really just do whatever they feel like, with a few practices thrown in occasionally. Typically, the project leader or process owner is unaware of how the people circumvent whatever the declared practices are.
My goal is to create a space for medium-disciplined people to work, a HighToleranceMethodology. However, my best current guess at capturing a HighToleranceMethodology is in the CrystalClearMethodology. The CrystalOrangeMethodology? is sketched in my SurvivingObjectOrientedProjects book.
Do they work? Well, to the extent the people are skilled and cooperate, yes. To the extent they aren't and don't, no. To get a more consistent result you have to add training and collaboration-setting and disciplined practices and a mechanism to keep the practices consistently in use. --AlistairCockburn
Alistair - I'm having trouble grokking CrystalClearMethodology as medium discipline with its 20 required deliverables. Please say more. --Ron (See HighToleranceMethodology. --Alistair)
A developer's nature is to develop code, not to develop documentation. The best process is one that works with nature, not against it. (Tree-hugger theory of software development.) --Anonymous1
How about if I amend that to read, "A developer's nature is to develop code, alone, without unit tests, thinking up neat things along the way, and not documenting. The best process is one that works with nature, not against it. Tree-hugger theory of software development)." --Anonymous2
AlistairCockburn: OK, I'll give it go. At the risk of giving a dog a bad name, most (but not all) people are quite slovenly in their action habits... leaving the milk out, forgetting to recharge the video camera battery, flossing or exercising daily, cutting fat out of their diets, etc. To me, this is the way of the world. Not something to fix, merely is. Can software possibly be developed by people who run their lives this way? Well, yes, actually, has been happening for 50 years or something.
Can we count on it happening? Well, yes and no, exactly the same answer as "can we count on anything being responsible for developing software?"
What factors affect the yes and the no? I'll nominate a couple: The skills and abilities of the people involved. The level of motivation and caring of the people involved. The other personal habits of the people involved.
Simply allowing an average-discipline group to use any old software development habits is what RonJeffries refers to as the "random chance" outcome... sometimes you get software out, sometimes you don't. The interesting question, as he phrases it, is, ''"How can we get better-than-random-chance outcomes on our project?"
I nominate: shorten the delivery increments to 4-12 weeks. Give a small team a war room to share and a qualified technical leader. Keep distractions away. Get the team training as they need it, people to give them information and feedback on their work.
With these 6 changes from random, I claim the team will beat random-chance output. I have even made this recommendation, and had it followed, with successful results. The team did nothing else special, no XP or nothin'. This sort of result raises the bar on what any higher-discipline methodology must achieve to claim to be better.
(For the record, for the umteenth time, I offer that XP beats the raised bar criterion... if and only if the team "signs up" for the added discipline. Various of the practices can be used in isolation to improve anyone's work.)
Hmm. Although seeking out and stomping on license for laziness (use that as a buzz phrase, if you dare) all over this Wiki would be a life-long challenge, I find this particular subject a good place to chip away.
Alistair says (paraphrased) that laziness among people doing work just is, and we should accommodate that laziness with a methodology that makes people productive anyway.
I call bullshit.
Discipline is doing what you are supposed to do, when you need to do it, whether you want to or not. Low discipline is exactly that -- low discipline. Discipline is how work is accomplished. This isn't play time, nor beer slurping time, nor chatting it up time. This is work time. This is a job. You are here to work. You are gonna do what I tell you to do, the way I tell you to do it, when I tell you to get it done. If you don't like that then there's the door right over there. Don't let it slam your lazy, fat ass on the way out.
I expect fellow professionals to act professionally; to study and follow the methods, techniques, and processes called for by the team's development guidelines. I expect fellow teammates to write down what they are supposed to record; to plan ahead and let others know what those plans are; and to follow the directives of the team leader without moaning and sidestepping their duties.
Nothing good happens without discipline, and if you can't get a team of supposedly skilled, educated, and experienced developers to behave professionally then you might as well drop a satchel charge into the next group meeting and start over.
Let the flames commence.
ItDepends. If doing HighDisciplineMethodology is honored (respected, paid well, educated for, ...) then people will like to do it. If not, then people will avoid any extra work keeping them from the things they like to do for which they do earn respect or which is just fun. You can see that in all of society.
So in a company/society which honors HighDisciplineMethodology you will see many projects done that way. Look 50 years back and you will see more of this (depends on country).
Sure there are pockets where HighDisciplineMethodology is still valued and followed (obviously by Marty) - but I'm not surprised that Alistairs LowDisciplineMethodology is a good idea for many teams today.
-- GunnarZarncke (being lucky to have a medium discipline team).
HighDisciplineMethodology is the sort of thing valued by people who believe that any job worth doing is worth doing well. The reality is that some aren't worth doing well. Many aren't worth doing at all, but for various reasons have to be done. These aren't worth HighDisciplineMethodology, because that's more work than they're worth. They're not even worth LowDisciplineMethodology. At best, they're only worth getting out of the way as quickly and expeditiously as possible.
See, this is exactly what I was talking about. If I as a team leader can't depend on my staff to act professionally by complying with the established engineering process then I need to fire everybody who won't comply and get people who will. Otherwise, why bother? If I tell you to dig a ditch from here to there and you won't do it, then you're fired. Period. Get outa my face.
And, no -- it doesn't "depend." You are either committed to performing your job properly or you are a waste of valuable space on my team. If this team is using a process that demands that you do certain things in a certain order then that's what you are going to do, come what may. There is no fluff, no wiggle room, no wishy-washiness involved. You either do what the process demands of you or you hit the road. That's the whole point of having a process in the first place, eh?
Labour laws, political connections, and the ability of the generally-incompetent to be amazingly good at one thing -- staying employed -- will conspire against you. As a team leader, do you really have hire/fire power? Or, like in most organisations, is that controlled by a distant HR department, backed up by disinterested senior management, who couldn't care less whether your so-called "engineering process" is followed or not?
{You better make sure it's a good process, because if the project is late or "bad", then your process may end up being blamed and you will need to be able to defend every corner of it, including comparing it with alternatives. The more "annoying" developers find it, the heavier it will need to be defended.}
I am, of course, speaking in the abstract here. However, if a client were to put me into a position of authority over a development team I would make sure that said authority included being able to dump team members for cause, whether that meant firing them or just kicking them off the team and into lesser positions.
The point is that any manager/team leader needs to be able to depend on his team to perform to requirements. If you can't perform then you don't need to be on this team. Simple.
EditText of this page
(last edited February 11, 2013)
or FindPage with title or text search