I just came out of an "Agile" team where the sprints are 3-weeks long, and during this same time, about 12 hours of that time is spent on exercises such as Scrum grooming, reviewing, Scrum, and retrospective, and the team works to develop and test within the time left.
Of course, this is the typical Agile implementation you find in many small/medium sized companies. You hear talks of avoiding code smells etc. in many of these settings, but the fact is many Agile teams I have worked with rarely spend more than 1 hour thinking of the design for the story/tasks on their plate. My question is, to ensure you do not end up with spagetti code, how much of the sprint-time should be allocated to ensuring that each and every new feature, new tweak,patch, passes the "good design" test?
I came across this article on Martin Fowler's blog, Is Design Dead?. I do believe that is an excellent read however, real-world implementation of these methodologies (XP, Scrum and Agile included) tend to throw design out the window. My question is, is there really room for good design in today's 2-3 week sprint "Agile" implementation world?
Maybe I should re-state that nowhere have I suggested that the Martin Fowler article included above says there is no room for good design. That article actually argues otherwise. My question here is simply to understand where 'good design' fits into real world implementations of the various "agile" methodologies. In a typical agile team, you may find that some of the stories where created long before many of the team members were brought on board. When you have a team of ,say, 10 developers that pick up 30 tasks to work on for the next sprint, how do they ensure that each piece is correctly designed to integrate and scale with the rest of the application?