The first gets you moving, the second is the test of the
system design. Yes, I know we delayed the possibly really bad news by one month, but if we did the worst thing first, and failed, we wouldn't know what was at fault - the problem, the thinking, the communication, etc. I like to debug our development system first before taking on a nasty. --AlistairCockburn
Somewhere in this hypertext we describe that on C3 we started with a one-week project that actually went through the entire process, end-to-end, of creating a check with our proposed architecture. Then we threw it all away and got down to actual cases.
Maybe that was EasiestThingFirstHardestSecond
My own opinion, though, is that WorstThingsFirst
, with DoTheSimplestThingThatCouldPossiblyWork
, is the way to work day to day. In any case ItsJustaRule
Easiest Thing First is a good way for a newly-formed
team to share a low-risk "shake-down cruise" to gain
comfort in working with one another.
Crank up the pressure right away, and people will often
fall back on behaviors that worked in their last team,
but which aren't (or aren't yet) part of the current
team's culture, and may seem mysterious (and provoke
anxiety) in other team members. --DaveSmith
Two arguments have been given for using this process instead of WorstThingsFirst
: 1) building project momentum, and 2) debugging the development team (and/or process).
To address the first argument ask yourself - What builds more project momentum having the easy task done, or having the worst task done?
uses the possibility of attempting the worst task and failing, as justification for using EasiestThingFirstHardestSecond
. I don't think this is a good enough for the following reason - even if you attempt to select the easiest thing, you might still fail.
So another question you might want to ask is - If I were going to attempt a task and fail, would I learn more about the system (and debugging the team) by attempting the easy task, or by attempting the worst task?
The previous paragraphs discussed the same outcome for both the easy and the hard task - and ignored the possibility that WorstThingsFirst
is more likely to fail than EasiestThingFirstHardestSecond
. So, consider that the easy task would succeed, and the worst task would fail. Both processes have the same result (i.e. failure on the worst task), but EasiestThingFirstHardestSecond
has it later. The success of the easy task gave you momentum, but you still aren't going anywhere unless you can solve the worst task.
As for the second argument I think it is possible to debug the team using either EasiestThingFirstHardestSecond
. However, I think the difference between the two is similar to the difference between dating and marriage. If you are doing something easy there is no struggle or conflict; it is easy to be reasonable, and everyone is on their best behavior (just like dating). On the other hand,if you are doing something harder, there is the potential for disagreement and conflict (like marriage, for better or worse). Since conflict is sure to arise at some time on every project, the team cannot be considered debugged until it can handle conflict.
also makes the point that people behave differently under pressure. What better time to crank the pressure up than right at the beginning? After the hardest thing is done, the pressure will probably easy up. If you have done something easy, the pressure is still waiting to build. And you still don't know how your team will react to stress. --AnnAnderson
People do behave differently under pressure, and until those differences
are understood and appreciated by others on the team,
cranking up the pressure leads to perceptions of bizarre behaviors
among folks who haven't yet worked together.
The team may form
but it probably won't norm
Once team members are comfortable
with one another, and have developed some agreements on how
to behave (procedures, etc.)
then by all means take on the difficult stuff. --DaveSmith
Starting with an easy thing first to build the team is not contradictory to WorstThingsFirst
doesn't say "work on the most difficult technical problem first". It says to work on your worst, most pressing, most likely to cause trouble, most restricting problem first.
Early in a project, getting people talking is far and away the worst problem. Doing some easy technical task, whose real purpose is teambuilding, is a great way to address it. When getting people talking is no longer the worst problem, move on to whatever is. So the two ideas are not in contradiction at all. Do an easy thing first because the worst problem is team-building.
If you think about it, even the WaterfallModel
sort of follows WorstThingsFirst
, it just doesn't know when to quit. It starts with RequirementsAnalysis
. That really is
the worst problem at the beginning(*). However, WaterfallModel
would have you do RequirementsAnalysis
until done. On most typical IT projects, a few weeks of analysis will reduce the requirements risk. It's not worst any more. Now the worst problem is that you don't know the cost of implementing the requirements. The best thing to do is stop doing more requirements and scope out cost for a while. Etc, etc.
(*) TeamBuilding? might really be the first worst. Waterfall, like many methodologies, doesn't acknowledge that there are humans and feelings involved in the process.
requires that you do two things at once. First (this is the hard part) you must be aware, in a very broad sense, of what your worst problem is. Second (and this is the harder part), you must be aware of when it is no longer your worst problem and have the courage to stop working on it on start working on something else.
In a programming course, your first assignment is typically to print "Hello world!"
You do this, not because it's hard.
Quite the contrary; you do it because it's easy:
Having printed "Hello world!", you've demonstrated that you can log on, edit a file, compile it, and successfully run it.
Now that you're "rolling," you can start to put some weight on the cart, and do real work.
For guidance that doesn't have anything to do with difficulty, think about FirstThingsFirst
Exactly the contrary advice EasyThingsFirst