3 ms·

But... that's not agile!

• DanielBMarkham 17y ago
  Assuming you're not making a joke, I think these things get blown way out of proportion. You're always going to design before you code, even if you just take ten seconds before starting to type your tests into the IDE. The question is "how much design is too much?" The reason we have to ask that question is that for some folks design is supposed to eliminate all uncertainty and control execution. When design is taken to this extreme, bad things happen. But bad things happen when no forethought is put into work as well. High-performing teams use design as a way of getting common understanding about a general plan of attack on the problem domain -- which can include things like initial data models. But the general idea is to do simple, easy things repetitively. So whatever you do for design, make it something that's easy enough to do every sprint. Perhaps that means an hour or two at the beginning of each sprint -- perhaps a day or two. But thinking ahead and getting group buy-in is always a good idea when there's more than just one of you. Heck, it's a good idea even when there's only one of you. Good design can try out and throw away ideas really quickly. Designing from code is a lot more painful.
  • hajrice 17y ago
    Thanks for the feedback guys, I appreciate it. I agree with you Daniel, you have a very good point. Although, I still think we should do the entire design before we do the cause: a) It's very easy and fast to get feedback. b) You're not creating any diversion with your team members. c) As a development guide(if you have a status update going on in every page of the website, that'll definitely make you think differently while developing the product).