You Can’t “Cherry Pick” Agile Projects

BLG02x - edited feature imageWhen you are first adopting agile techniques in your organization a common strategy is to run one or more pilot projects.  When organizing these projects you typically do as much as you can to make them successful, such as finding:

— Projects where the stakeholders are willing to actively work with you.

— IT people who are flexible, willing to try new things, and willing to collaborate with one another.

  1. — IT people who are generalizing specialists, or at least willing to become so.

— Finding a project which is of medium complexity (therefore it’s “real” in the sense that it’s significant to your organization) but not one where it can make or break your organization (therefore it’s safe to experiment with).

In North America we refer to this as “cherry picking” because you’re picking the cherry/best situation that you can find.

Some thoughts:

  1. Being agile may not have been the primary determinant of success.  You set up an environment where you have a good relationship with your stakeholders, where you have good people who want to work together, and the project is challenging but not impossible.  Oh, and by the way you adopted a few agile techniques as well.  Sounds to me that situation you could have adopted a few not-so-agile techniques instead and still succeed.  Although my various project success surveys, see my IT surveys page for details, have shown time and again that agile project teams are more successful than traditional project teams I haven’t been able to tease out (yet) whether this success is attributable to agile or just attributable to improved project initiation efforts.
  2. When adopting agile/lean widely across your organization, you can’t cherry pick any more.  For the past few years I’ve been working with IT organizations that are in the process of adopting agile/lean strategies across their entire organization, not just across a few pilot projects.  What these organizations are finding is that they need to find ways to adopt agile where the business isn’t as willing to work with IT, where some of the people aren’t so flexible or collaborative, where some of the people are narrowly specialized and not as willing to expand their skills, or where the project exhibits scaling factors which motivates you to tailor your agile approach.  It’s harder to succeed with agile in these situations because they’re not as “cherry” as what you’ve experienced previously.  Luckily, if you’ve been successful previously then you now have some agile experienced people, you have successes to reference, and you’ve likely overcome some problems even in the cherry situations which you have learned from.  So, your cherry successes will hopefully improve your ability to succeed even in “non cherry” situations.
  3. You need to work smarter, not harder. If the source of your success was actually from improved project initiation practices and not from agile, then recognize that and act accordingly.  Realistically part of your success was from that and part was from agile, and the organizations that adopt a measured improvement approach potentially have the data to determine which practices lead to success and which didn’t.  Without the metrics you’re effectively flying blind when it comes to deciding how to improve.  There is clearly a mandate for smarter work practices within IT, within your organization as a whole for that matter.

Share this post

Scott Ambler

Scott Ambler

Scott W. Ambler is the Senior Consulting Partner of Scott Ambler + Associates, working with organizations around the world to help them improve their software processes. He provides training, coaching, and mentoring in disciplined agile and lean strategies at both the project and organization level. Scott is the founder of the Agile Modeling (AM), Agile Data (AD), Disciplined Agile Delivery (DAD), and Enterprise Unified Process (EUP) methodologies. He is the (co-)author of several books, including The Executive Guide to Disciplined Agile, Disciplined Agile Delivery, Refactoring Databases, Agile Modeling, Agile Database Techniques, The Object Primer 3rd Edition, and The Enterprise Unified Process. Scott blogs about Disciplined Agile at DisciplinedAgileDelivery.com. Scott is also a Founding Member of the Disciplined Agile Consortium (DAC), the certification body for disciplined agile.

scroll to top
We use technologies such as cookies to understand how you use our site and to provide a better user experience. This includes personalizing content, using analytics and improving site operations. We may share your information about your use of our site with third parties in accordance with our Privacy Policy. You can change your cookie settings as described here at any time, but parts of our site may not function correctly without them. By continuing to use our site, you agree that we can save cookies on your device, unless you have disabled cookies.
I Accept