April 25, 2006
People I respect and trust say that agile development has crossed the chasm. To expand a bit, that means it's made the necessary leap to become our next mainstream development approach. Perhaps that's why I received this email today from a company that really should have known better:
Data by (vendor)'s SDLC Transformation Group has revealed that output and quality can vary as much as 200% based on the offshore / supplier model selected. Find out how (vendor)'s Agile Offshore approach compares with the typical offshore model deployed by most providers. You don't want to miss this chance to understand how your software development investment can double.
Already Offshoring with other supplier or Offshoring with your own Captive Center?
Learn the secrets behind (vendor)'s Agile Offshore approach and how to implement these techniques with existing suppliers and/or apply these techniques to remote captive development centers.
Not Offshoring or Considering Offshoring?
Discover insights on the emerging Agile Practices and their usefulness to dramatically reducing total cycle time from project inception to delivery (50% cycle time reduction is NOT unusual) Techniques and methods we'll share are actionable to an in-house development group.
Now that agile development has crossed the chasm, we're going to see more and more inflated claims as opportunists jump on the bandwagon. (I know of one, distinctly non-agile, company that's already changed it's name to "Agila-something.") That's going to lead to some natural disenchantment. Ten years from now, I'd hate to hear people say, "Yeah, that agile development thing never really delivered on its 'double productivity' promise." (But... but... what about TDD? Continuous integration? Feedback-based planning? All the great stuff that future-you takes for granted? What are we, chopped liver?)
So, for the record, let me be totally clear: Your mileage will vary. Don't get me wrong--I have lots of experience with agile development and I firmly believe that agile development is a rigorous, disciplined, and low-overhead approach to software development. It results in significant benefits compared to non-rigorous, non-disciplined, or high-overhead approaches. But 50% cycle time reduction? I would never promise that. I don't even know how to measure it. Cycle time versus what? The non-agile project you didn't do because you were doing agile instead?
For the last six years, I've been doing nothing but transition software teams to agile development. Intensive, in-depth, multi-month transitions. (Training and less intensive consulting, too.) I've got the scars to prove it. In the interest of balanced reporting, here are my agile promises:
I promise to discuss your goals with you and help you come up with concrete measures of success that you define. I'll tell you immediately if your goals are too optimistic and I'll help you revise them if they are.
I promise to discuss return on investment based entirely on your expectations and figures. I'll keep an eye out for expectations that are unlikely and I'll even tell you about things that are achievable but risky. We'll focus on realistic, achievable, sustainable value.
I promise to be completely honest with you about what's achievable and what's not. I will be crystal clear about the things that are within my control (the quality of my work) and the things that are not (your team's openness to new ideas).
I'll do all of this before you pay me a dime. I'll risk losing your business rather than committing to something we can't achieve together.
Not quite as exciting as "double your software investment!" Sorry. It's a lot more realistic, though.
Agile development is a great approach to development. It's not a panacea. It won't work miracles. Software development requires professional effort and agile development is no exception. It must be applied thoughtfully, carefully, and with attention to detail and nuance. That's hard. Don't be fooled by the inflated claims of the agile bandwagon that's just topping the horizon.