Posts Tagged ‘agile methodology’

AccuRev’s Agile Methodology Workshop

July 20th, 2010 by Bob DeMaria

AccuRev hosts educational Agile methodology seminars called “Agile Comes to You,” which reach audiences nationwide and focus on teaching best practices of Agile software development.  The seminars have been quite successful, and regardless of their organization’s level of Agile adoption, I know attendees have learned some great information from these sessions.

AccuRev doesn’t host the Agile methodology seminars alone, and generally presents in conjunction with partners Rally Software, Urbancode (the makers of AnthillPro), and Coverity. The seminars consist of a keynote with extensive Agile experience, educational presentations, and a short tools demonstration. The format has been so successful that we have used it for over a year, and you might even notice similarly-formatted seminars from other organizations as well. (Imitation is the most sincere form of flattery, right?)

The Agile Methodology Workshop

We try to focus on making our seminars as educational and relevant as possible by giving attendees access to the real life Agile experiences that presenters bring to the table.  So in addition to presentations focused on benefits of the Agile methodology and best practices, we came up with the concept of an “Agile Workshop.”

The Agile Workshop  allows each attendee to discuss their most difficult challenge in transitioning to Agile with other attendees in small groups, as well as with our Agile experts.  We do this for two reasons:

1) It gives the attendees a chance to exchange thoughts and solutions regarding their Agile migration.

2) It allows the attendees to interact with the panel of experts on how to solve these difficult challenges.untitled AccuRevs Agile Methodology Workshop

Once the group has discussed the challenges each individual faced during a transition to Agile, they then agree upon a top challenge that they ask the panel of Agile experts to comment on and offer advice.

For example, at a recent seminar in Toronto, this was the attendees list of top challenges:

  • Culture Change / Rest of the Organization not Agile
  • Support Agile and Traditional projects in parallel (Hybrid Process)
  • Massive/Distributed applications implementing Agile
  • Propagating user stories across multiple release lines
  • Agile with Distributed Teams
  • Agile with Outsourcing
  • We have been seeing this same pattern across most of our seminars, and I believe it gives us good insight into the state of Agile adoption.  It is amazing to see that even across very different organizations, the challenges that arise with Agile adoption are remarkably consistent from seminar to seminar.  It seems that no matter who you are, or what stage of Agile adoption you are in, many are facing the same challenges when moving towards Agile development. There is some comfort in numbers, knowing that you are not alone in facing hurdles.

    While I won’t take the time to answer every one of these challenges here today, I plan on commenting on each one of these issues in the coming months, in hopes that sharing my experiences and alternatives help you in solving these difficult problems.  I would also like to invite some of our Agile experts, as well as our attendees, that are internal to AccuRev or our partners to comment or blog on some of these topics to share some of their experiences.

    While the “Agile Comes to You” tour is taking a short break for the summer months, be sure to look for us in your city this September or stop by and visit us at Agile 2010 Conference in Orlando.  Have a great summer!

    Blending Agile Practices Into Your Traditional Development Process

    June 16th, 2010 by damonpoole

    When talking about Agile development, people often ask me, “but why would I want to change to a new methodology when traditional development has made so much money and created so much value for so many people for such a long time? Why mess with success?” That’s a great question!

    After hearing that question for the umpteenth time I finally realized something.  It isn’t traditional software development that has provided so much value! It is the software itself. Imagine calling a travel service prior to the advent of software. You call them up and say “I’d like 100 or so options for travelling from Boston to San Jose. I’ll also need a bunch of 3 or 4 star hotels in San Jose and mid-sized rental cars to choose from.  Could I get that in 5 seconds please?”

    In today’s world, of course you just go to a site like Orbitz.  It isn’t traditional software that provides that value, it is the software itself.  It almost doesn’t matter what process you use to produce that software, the value is so high. When you are only competing against somebody that doesn’t have software, that’s one thing. When you are competing against other organizations that are also using software, then the exact process you use can make a big difference from a competitive standpoint.

    It isn’t traditional software development that has provided so much value it is the software itself.

    What do we mean by “traditional development?” After having been involved in the process of literally thousands of software development organizations, I can safely say that there isn’t really any such thing as “traditional development” or even “waterfall.”  That is, if you look at any two organizations developing software, there is no standard for what comprises traditional development.

    In the end, organizations adopt individual practices that make sense for their circumstances. This same approach can be used when adopting “Agile.” There really isn’t any such thing as “Agile.” It is a combination of values and practices which can be adopted by any organization and does not require wholesale adoption in order to provide value. Yes, there are packaged solutions out there such as Scrum, XP, Kanban and others, and they do provide value.  But so do the individual practices.  So, instead of thinking about “how do I switch to this new thing,” consider Agile as a new set of tools that you can add to your existing process on a case by case basis. Worry about “being Agile” after you’ve gotten some experience under your belt with some of the practices.