On June 25th, Rally hosted the Atlanta swing of the Agile Success Tour, where local software and IT leaders met to share Agile implementation stories, ask for advice and participate in group breakout sessions.
Learn about upcoming dates in your area by visiting here. These events are free, but registration is required.
Below are 3 themes that developed at the event:
1. Executing as a distributed Agile organization almost requires a tool
Many of the discussions focused on best practices for Agile adoption in a globally distributed team. One of the points that gained consensus among the attendees was that a distributed Agile team should use a tool as an ‘information radiator’. The tool helps to provide visibility into the teams iteration and release status regardless of where each team member sits and in what time zone.
Using a tool in a distributed organization helps to overcome some of the collaborative issues the group would otherwise face in the form of daily standups, blocking issues, and team velocity. Also, the group agreed that nothing goes as far toward team building as getting the team together – even if it is just once a year at the beginning of a release or to do retrospectives.
2. Agile can help quantify the case for additional resources – and understand why they are needed
My personal favorite discussion was when one group member asked “Does the team have to be a certain size in order to adopt Agile?” We thought he was assuming that a large team or organization would have a difficult time adopting Agile. Actually his question was based on the fact that his team was just two individuals.
As the discussion progressed, we all agreed that building a product backlog, then prioritizing and sizing the stories would allow him to articulate exactly what the two-some was capable of committing to in any particular iteration. If that much value was not enough in the agreed upon timebox, perhaps the business should consider more resources for this team.
3. We’d like to adopt Agile – how do we ‘sell’ it internally?
Many of the folks participating were anxious to get started – even before they came to the event. Where they were often getting stuck was in how to articulate the ‘why’ to the business. Some great points that were shared were:
- Focus on the value of adopting Agile – and be specific. A recent study that was presented at the event highlights the fact that Agile teams are 50% faster to market and 25% more productive compared to industry averages.
- Agile represents a fundamental shift in our approach to resourcing. How the work is organized will depend on what software you are developing, but the key is the team will create greater visibility about priorities, and put those decisions back in the hands of the business.
- Avoid using Agile ‘jargon’. Many people who don’t understand Agile will associate negatives with the words we all know and love: Scrum, sprint, backlog, user story – these are all Greek to non-Agile folks, and should be avoided when trying to gain buy in. Create associations and use well known equivalents as you gain consensus to move forward.
- With Agile, we focus on the shippable increment. This point should resonate well with the business. When was the last time they got to see the product evolve every two weeks in demonstrations? One shared example from our executive panel was that the team would e-mail stakeholders an AVI demo every month. These folks could see the product demo (and it’s progress from one month to the next) on the plane, at their desk, on their own time. She knew success was at hand when the team didn’t send out a demo one time and an executive from the business called asking where his demo was – he was anxious to see it!



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 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…
nice answers i like it