This post originated from an RSS feed registered with .NET Buzz
by Jonathan Crossland.
Original Post: Agile vs Planning
Feed Title: Jonathan Crossland Weblog
Feed URL: http://www.jonathancrossland.com/syndication.axd
Feed Description: Design, Frameworks, Patterns and Idioms
I believe a lot of Agile Methods tend to flat-line in terms of benefits at some point in a project life-cycle. Perhaps due to the fact that it gets bogged down by lack of planning, refactoring and other quick turn-around activities.
I wish I had kept a decent record of the whens and whys, but one aspect that I know is always present is that object model, software architectures, design patterns or design in general never quite gets the respect it deserves.
Over time, as one focuses on stories and getting sprints out the way, getting demo software out the door, design becomes blurred. In environments like this, where I have been responsible for design on whatever level, my voice increasingly becomes drowned out by more 'pressing issues'.
The focus eventually becomes one of 'reaction' rather than 'prediction'.
I do think being responsive is a good agile business technique, and one has to respond quickly to change, but I have a problem with only living in that reactionary present tense world. I think predictive solutions can be a little risky, thus people steer away from it.
We can refactor it later - is a universal cry!.
Refactoring has become an excuse to the lazy characteristic summed up by 'I will do it later', instead of just being a proper way of evolution and change. Evolution without forethought can often be rather messy and time consuming. Eventually it can become a burden on agility.
I hope that proper respect to planning core areas of a system is made, proper respect to good analysis. I try to make sure that along with, being agile for today, we are also planning for tomorrow.
Previous Topic
