Comment by fsloth | Hacker News Reader

Comment by fsloth | Hacker News Reader

Personally I find that this line "Responding to Change over Following a Plan" does much more harm than good. It should read "You should have a plan but should rather be prepared to change it constantly than stick with it dogmatically".

I would say that when you are within a project team it should emphasize the agile values but once you are on an organizational level where several project teams need to co-operate to deliver a product the constraints given to teams should be formalized over the right hand side, strongly, but in a way that is ready to take immediate feedback from the realities. Preferably, my dream system would be formed of strong spec based contracts between teams, enforced by automatic tools and architects, who work as part of feature teams implementing features and have the ownership of the spec-framework and can swiftly change it to respond to changes.

Completely forgoing specs and plans leads to anarchy and headache where the only two-channel communication with developers is facilitated by broken unit tests and system-test or (the horror) customer side regressions.

Good software systems are composed through a firmly kept set of as strong constraints as possible, IMO, and someone needs to own the constraints.

> Personally I find that this line "Responding to Change over Following a Plan" does much more harm than good. It should read "You should have a plan but should rather be prepared to change it constantly than stick with it dogmatically".

For all the points in the Agile Manifesto, the right hand term isn't bad at all. It's a good and important thing, but the left hand term is even more important. Plans and processes (in a large organization) are definitely important, but they should never trump change and people. Documentation is also important, just not as important as working code. Contract negotiation is unavoidably important in any business environment, but don't let it get in the way of cooperation.

Yes. I think this is one of the most important and yet misunderstood aspects of agile. You aren't throwing out the right terms, just re-prioritizing them.

>> "Under 2.4, can we have more jobs in the jobstore and is the console more optimized?"

I agree with this. You create a plan so you have an idea when the project will finish, when resources will become free, when you deliver to other dependent teams etc. That doesn't mean the plan is cast in stone and once the Gantt Chart is finished, it never changes.

Obviously, you do what you can with scope, resource moving, etc to keep to original dates but if you can't, then the plan should be updated to reflect reality.

I think this hits the most interesting point. Personally I agree with the article that the best way to develop efficiently is to continually take small steps in the right direction and reevaluate where you are after each one - you save a lot of time by not planning things you don't need that way and it's much easier to maintain focus. But against that, people need estimates for how long projects will take and how much they will cost, and that demands a plan.

"you save a lot of time by not planning things you don't need that way" Yes, but on the other hand you will lose time if you do not plan those things ahead of time that you can plan ahead of time. It's much cheaper to catch ill defined requirements while planning on paper than once the constraints reach production and people start implementing features and tests based on them. Although you cannot plan _everything_ there is always _something_ you can plan - and should plan. Unless you have a spec or a plan at day 0, you do not have a documentation platform available when the shit invariably does hit the fan and you need to do the learning-organization-disco and facilitate a change to your product because some real world constraints were not known or acknowledged before hand.

I am not sure I agree with that first point, having been involved in a short project, that just became one monstrous exercise in feature creep. That was essentially taking small steps in the right direction, but it never finished.

I think it is beneficial to have a plan in certain situations.

I think they worded it correctly. Notice it doesn't say, "Responding to Change over Making a Plan." Your version is horribly ugly. Theirs is succinct and poetic.

I agree that my version is horribly ugly :).

However, if you are not going to Follow a Plan, and while you're at it, you are attempting to Eliminate Waste as per the lean thinking movement, one may quickly follow with the conclusion that plans that are not followed are wasteful, and therefore unnecessary.

My experience has shown me that this is the interpretation people very often make. YMMV as always, though.

Preferring to Respond to Change over Follow a Plan doesn't mean you never follow the plan. It means that when changing circumstances conflict with your plan, then you respond to the change rather than blindly follow your plan.

I think what the Manifesto was targeting was "blindly" following a plan. In those days, reqs were drawn up, a design spec'd, a plan written out and there tended to be considerable resistance to changing the plan. That's what they were aiming at.

> It should read "You should have a plan but should rather be prepared to change it constantly than stick with it dogmatically".

I'm going to steal this. Spot on.

I believe Eisenhower said it best:

"Plans are worthless, but planning is everything"

Reply on news.ycombinator.com