Requirements Come Second - What Comes First?

Doing the "The Whole Enchilada" is likely the worst, worst thing you can do.

What you must do to achieve good results is very dependent upon the results you must achieve. There is no such thing as a universal solution for all problems nor a universal best way to solve them - ie no Silver Bullet. Its as simple as, if you don't know what must be achieved, you can't know the right things to do nor the right way to do them.

Its the right problem, correctly identified, and clearly understood in context that is the starting point. Without that, you are doing nothing but thrashing about and spouting bullshit. Maybe that is the best you can do. If so, admit it rather than pretending. You really don't know what you are doing.

Its the right problem, correctly identified, and clearly understood in context that is the starting point.

If you don't have the right problem, correctly identified, and clearly understood in context, you are not at the starting point. You are still back in the barn mucking out stalls. You have a lot of work to do before you can start. In fact, you don't even know which horse you are going to ride (ie you can't know what technical capability will be needed). The most you can do is guess.

Doing development by guess by golly accident is not very effective at solving the real problem. Especially when you don't know what the real problem actually is. You might accidentally stumble onto it but could you recognize it if you did?

Its much too early to apply any particular "The Whole Enchilada" except perhaps the scientific method. The scientific method is a truck load of whole enchiladas from which all "Whole Enchiladas" that work are derived.

The reason the numbers are so bad, the fundamentals were not addressed in any coherent and rigorous way - ie by the scientific method. A particular "Whole Enchilada" was used without concern with it actually being applicable to the problem or context at hand. It was largely a religious exercise of following prescribed dogma. This simply does not work except by accident.

Basically I agree with Lionell, you have to know what your doing.

But, in the context of the Sloan piece, and the in which I wrote the Agile Journal piece is different.

The starting point is not a blank sheet of paper, the starting point is a dysfunctional IT group and you want to fix it. The group is doing something and the options are to either to improve what they do, or how they do it. Which do you do first? - do it right, or do the right thing?

In the long term requirements are more important than ever (as I say in my article) but in the short term, when you are fixing things the first thing to fix is how things are done.

Another way of thinking about this is from the iterative view. You start with a general goal, e.g. "build a payroll system" and rather than get into the details you build an effective team to tackle that problem. Over time the team will zero in on the details.

I always vote for doing the right thing. Then and only then, focus on doing it right. Most likely by incremental improvement. Doing the wrong things superbly well does not help. It doesn't even help you discover the right thing to do. It simply burns time and effort and keeps your focus off of what you really need to do.

This is true even for an dysfunctional (aka incompetent) team. However, if your team is in fact incompetent, you are hosed before you start mucking the stalls. They would have a hard time finding the stalls let alone know how to muck them.

As I have said in other contexts, if you want to evolve a Cindy Crawford (or your super model choice) at least start with the same specie and not an alligator. An incompetent team is that alligator.

An interesting collection of metaphors Lionell. Indeed, If you don't know where you're going...any road will get you there.

Perhaps I am missing the point here, but alignment evolves, as does elegance in design, through iteration. You know you have an incompetent team if that does not occur. It's like Jazz, you know it when you see it.