http://www.rallydev.com/agileblog/2009/07/does-distributed-agile-require-a-tool-and-2-other-threads-from-atlanta/ Adopt, Scale and Succeed with Agile Development Wed, 17 Mar 2010 14:33:06 -0600 http://wordpress.org/?v=2.8.4 hourly 1 http://www.rallydev.com/agileblog/2009/07/does-distributed-agile-require-a-tool-and-2-other-threads-from-atlanta/#comment-4978 Rinoanack Tue, 05 Jan 2010 16:03:48 +0000 http://www.rallydev.com/agileblog/?p=2576#comment-4978 nice answers i like it nice answers i like it

]]> http://www.rallydev.com/agileblog/2009/07/does-distributed-agile-require-a-tool-and-2-other-threads-from-atlanta/#comment-4916 Phillip Wendell Tue, 15 Dec 2009 12:54:16 +0000 http://www.rallydev.com/agileblog/?p=2576#comment-4916 I disagree and think that an Agile team would not be able to affect delivery times or feature shrinkage in a timely fashion. I have never been able to put together a simple Daily Scrum report in under 15 minutes so that point is also a falacy. We all know that the Burndown chart is overrated as it does not show all the data. Just give me my Gantt chart and Highlight Report any day... I disagree and think that an Agile team would not be able to affect delivery times or feature shrinkage in a timely fashion. I have never been able to put together a simple Daily Scrum report in under 15 minutes so that point is also a falacy. We all know that the Burndown chart is overrated as it does not show all the data. Just give me my Gantt chart and Highlight Report any day…

]]> http://www.rallydev.com/agileblog/2009/07/does-distributed-agile-require-a-tool-and-2-other-threads-from-atlanta/#comment-3542 Paul Jackson Fri, 03 Jul 2009 07:56:00 +0000 http://www.rallydev.com/agileblog/?p=2576#comment-3542 I'd agree that a distributed Agile team need some form of collaborative tool to improve the communication flow. Collaborative chat is relatively easy to do now. But the really valuable data is in the Product Backlog and the Burndown Chart. My team are distributed over 4 continents in a variety of time-zones - getting everyone to the phone for a Daily Scrum is really difficult. So we use an electronic version of the burndown chart and a simple Daily Scrum report (takes 10 mins to put together) - but at the moment I've only found one web-based tool out there that is simple enough to encourage the teams to use it on a daily basis, and provides the global visibility that the client demands. Providing access to the burndown to clients is important; it's a really useful way to show progress and provide them with some "what if" scenarios if they start talking about changing the scope of the Sprint or pulling resources from the team - when they see the burndown forecast a flat-line and it crosses over the estimated velocity line, they soon get to see how their planned actions might affect delivery times or feature shrinkage. I think this last point can also help address points 2 & 3 above - use the burndown to persuade management that Agile methods do have planning and progress reporting, far better in my opinion than a wordy Highlight Report and a (already out of date) Gantt chart. Great article by the way! I’d agree that a distributed Agile team need some form of collaborative tool to improve the communication flow. Collaborative chat is relatively easy to do now. But the really valuable data is in the Product Backlog and the Burndown Chart. My team are distributed over 4 continents in a variety of time-zones – getting everyone to the phone for a Daily Scrum is really difficult. So we use an electronic version of the burndown chart and a simple Daily Scrum report (takes 10 mins to put together) – but at the moment I’ve only found one web-based tool out there that is simple enough to encourage the teams to use it on a daily basis, and provides the global visibility that the client demands. Providing access to the burndown to clients is important; it’s a really useful way to show progress and provide them with some “what if” scenarios if they start talking about changing the scope of the Sprint or pulling resources from the team – when they see the burndown forecast a flat-line and it crosses over the estimated velocity line, they soon get to see how their planned actions might affect delivery times or feature shrinkage. I think this last point can also help address points 2 & 3 above – use the burndown to persuade management that Agile methods do have planning and progress reporting, far better in my opinion than a wordy Highlight Report and a (already out of date) Gantt chart.
Great article by the way!

]]>