Comments on: What does Scrum look like to you? http://jeremiahx.com/2008/05/02/what-does-scrum-look-like-to-you/ The Blog of J.J. Merrick Wed, 24 Feb 2010 09:55:25 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: J.J. Merrick http://jeremiahx.com/2008/05/02/what-does-scrum-look-like-to-you/comment-page-1/#comment-2993 J.J. Merrick Fri, 02 May 2008 19:49:05 +0000 http://jeremiahx.com/?p=139#comment-2993 @doug Now does everyone you work for in your same office? Any remote people? @doug Now does everyone you work for in your same office? Any remote people?

]]> By: doug sims http://jeremiahx.com/2008/05/02/what-does-scrum-look-like-to-you/comment-page-1/#comment-2984 doug sims Fri, 02 May 2008 16:30:07 +0000 http://jeremiahx.com/?p=139#comment-2984 We have been using scrum very successfully too, using 2 week sprints. we do the stand-up meeting, then we also do a code review of all code commited to our svn trunk the day before. We meet every 2 weeks for a planning session for the next sprint and prioritize our backlog of issues for that sprint. then we self- assign tasks, determining requirements along the way. The biggest advantage I see to an agile approach is that rather than make all the decisions at the beginning(when we know the least-in the traditional waterfall approach), we make decisions as we need too, sometimes waiting until the last "smart" moment to decide. another important aspect is to approach the 'must' items first. if there is a piece that will cause the whole project to fail if it is not achieved, we want to know at the beginning, so the plan can adjust. In traditional approaches, you lay out all that needs to be done, and often start at the beginning (for example with user log on) rather than the core functionality that will determine if the project fails or succeeds. if this means that we spend 5 minutes now simulating login with a hardcoded password, rather than a day to really implement a solution. its ok. no one wants a project to fail, but why waste time on incidentals if a 'must' item can not be completed. If the project is going to fail, its better to fail as early as possible. We have been using scrum very successfully too, using 2 week sprints. we do the stand-up meeting, then we also do a code review of all code commited to our svn trunk the day before. We meet every 2 weeks for a planning session for the next sprint and prioritize our backlog of issues for that sprint. then we self- assign tasks, determining requirements along the way.

The biggest advantage I see to an agile approach is that rather than make all the decisions at the beginning(when we know the least-in the traditional waterfall approach), we make decisions as we need too, sometimes waiting until the last “smart” moment to decide.

another important aspect is to approach the ‘must’ items first. if there is a piece that will cause the whole project to fail if it is not achieved, we want to know at the beginning, so the plan can adjust. In traditional approaches, you lay out all that needs to be done, and often start at the beginning (for example with user log on) rather than the core functionality that will determine if the project fails or succeeds. if this means that we spend 5 minutes now simulating login with a hardcoded password, rather than a day to really implement a solution. its ok.
no one wants a project to fail, but why waste time on incidentals if a ‘must’ item can not be completed.
If the project is going to fail, its better to fail as early as possible.

]]>