Some people think that they can only be Agile with small, co-located teams, and where there are no political constraints. Yes, that's ideal, but most teams aren't lucky enough to be in that situation. Does that mean they should give up on Agile techniques? Scott Ambler's answer is "No!"
Ambler's article in the October issue of Dr Dobb's Journal is entitled "Imperfectly Agile: You Too Can Be Agile!" What these constraints do mean is that teams need to be smart about how they apply Agile concepts, and be as Agile as possible given their current situation. Agile thinking is a great opportunity to incrementally improve even the most constrained process situation.
Ambler talks about how Agilists overcome common challenges which others use as excuses for not being Agile. Here are the excuses cited by Ambler, with some of the points he makes:
To back his claims, in the sidebar entitled "Large, Dispersed, Complex, And Political—Yet Still Agile" Ambler talks about the Eclipse Foundation, whose success with deliveries, for example delivering the large and challenging Callisto project earlier this year, is attributed at least in part to the adoption of Agile practices.
Related news on InfoQ: SirsiDynix Case Study: Jeff Sutherland on Highly Productive Distributed Scrum
Ambler's article in the October issue of Dr Dobb's Journal is entitled "Imperfectly Agile: You Too Can Be Agile!" What these constraints do mean is that teams need to be smart about how they apply Agile concepts, and be as Agile as possible given their current situation. Agile thinking is a great opportunity to incrementally improve even the most constrained process situation.
Ambler talks about how Agilists overcome common challenges which others use as excuses for not being Agile. Here are the excuses cited by Ambler, with some of the points he makes:
1. Our team isn't co-located.
3. The problem is complex.
5. We're in a regulated environment.
6. We're a CMMI organization.
7. This is an outsourcing project.
8. We're building a data warehouse.
With proper application, there are practices and tools to help compensate for distance.
2. It's a large project.The first Feature Driven Development (FDD) team had 50 people and the second 150—and both projects were a success.
3. The problem is complex.
Wouldn't greater complexity actually imply a need for greater agility?
4. If we get it wrong, it's expensive if not impossible to redeploy.Doesn't an extensive end of a lifecycle-testing effort imply an inherent lack of faith in traditional processes?
5. We're in a regulated environment.
Not only is it possible to take an agile approach within a regulatory environment, it may even be preferable.
6. We're a CMMI organization.
It's not impossible, but you'll be fighting against a lot of prejudices.
7. This is an outsourcing project.
The biggest challenge in an outsourcing situation is the propensity towards fixed bids, but Agile Outsourcing does exist.
8. We're building a data warehouse.
There's nothing special about data warehousing projects—they can be Agile, too.
To back his claims, in the sidebar entitled "Large, Dispersed, Complex, And Political—Yet Still Agile" Ambler talks about the Eclipse Foundation, whose success with deliveries, for example delivering the large and challenging Callisto project earlier this year, is attributed at least in part to the adoption of Agile practices.
Related news on InfoQ: SirsiDynix Case Study: Jeff Sutherland on Highly Productive Distributed Scrum