Posts Tagged ‘Rally’

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!

    Do You have the Proper Agile Tools?

    April 28th, 2010 by clucca

    We recently produced a webinar here at AccuRev, co-sponsored by Rally Software, about the Top 10 Factors for a Successful Agile Implementation.  Number 7 addresses the question of a tools stack. Once Agile coaching and training is complete, now we can think about tools.

    Agile manifest declares:  ”Individuals and interactions over processes and tools.”

    But we believe that this statement doesn’t mean you should forget your tools stack entirely. It’s really about making sure that your toolstack helps facilitate those interactions between individuals.

    So it’s no surprise to us that when we hear about people rolling out Agile, they don’t even consider upgrading any of their tools. Studies have shown that new teams that do not invest in Agile tool sets, automated testing and continuous integration, start to struggle around the 10th iteration (4-5 months). The backlog of bugs and to-dos become so great that teams have to stop what they are doing and do a “maintenance” iteration, where they do massive amounts of QA or stop and do code reviews for an entire iterations. If we think about it, this kind of seems like traditional development model doesn’t it? Are you really Agile if you can’t deliver something which is “done” after every iteration?

    The problem? Your current toolstack was designed by people who had traditional development models in mind.

    Agile tools must help you build a testable, deploy-able app every 2 weeks like clockwork.

    Your tools don’t actually facilitate shorter development cycles, they actually hinder you by getting in your way. Your tool stack shouldn’t be the impediment in your Agile rollout.

    Lets start with an Agile project management tool. This is the obvious tool to replace in your stack. Converting your traditional issue tracking system to an Agile one will give you the speed and visibility to help your teams practice Agile on a day to day basis.

    Traditional source control management systems also hinder the process by following a “waterfall” like model of isolating code changes and leaving them on branches. Most SCM vendors know this is a problem, which is why their solution for an Agile branching methodology is to consolidate branches, or have entire teams work on one branch. This doesn’t make sense. All of your scrum teams should be able to function together and in parallel, while integrating work together on a regular basis.

    Smaller iterations mean a faster paced development cycle. Some of the tasks that you used to do a handful of times over the course of a waterfall will now be done on a weekly, sometimes daily basis. This is where continuous integration and test orchestration come into play.

    While you’re moving through a 2 week iteration, using continuous integration and automated tests suddenly becomes extremely important. Having these processes in place can help you avoid the 10th iteration problem we talked about earlier. You’re not going to have 4 months to regression test the application by hand in Agile.

    The idea here is that your Agile tools must help you build a testable, deploy-able app every 2 weeks like clockwork. You will repeat this process over and over. Isn’t it time your toolstack provided you with clockwork development cycles?

    Agile Requirements Traceability with AccuRev and Rally

    June 11th, 2008 by matthew d. laudato

    Today, AccuRev and Rally announced our technology partnership. You can read the press release here. Since I was part of the engineering team that did the initial proof-of-concept integration between AccuRev and Rally, I thought I’d spend few moments writing about the integration and how it helps customers connect requirements managed in Rally with code changes managed in AccuRev.

    First, for those of you who prefer the movie to the book, you can view a short video demonstration that I recorded here. It highlights the main functionality of the integration.

    Now to the details. Rally provides agile project management, including story and defect tracking, to assist customers in managing the rapidly changing flow of requirements and issues that are common in Agile development processes. AccuRev provides innovative stream-based SCM and integrated issue tracking to enable software process automation within the SCM tool. The integration ties AccuRev and Rally together to tighten the loop between requirements and defects, and the code changes that developers perform in order to satisfy those requirements or fix the defects.

    The integration, written in Ruby and Perl, consists of three parts.

    1. The integration queries AccuWork, the integrated issue tracking system that is available with AccuRev, for all ’New’ defects. It then transfers these defects into Rally, and makes an annotation in a custom Rally field called ‘AccuWork’. This field stores the AccuWork issue ID number.

    2. When developers working in AccuRev make a code change, they will promote that code to an AccuWork issue, and place the ID of the Rally defect (created in the first part of the integration) in the promote comment. The AccuRev server_post_promote trigger (written in Perl) then fires and executes another piece of Ruby code that parses the promote transaction and sends relevant information about the code change to the Rally defect specified in the promote comment. This information is entered into Rally automaticaly and shows up as a ‘Discussion’ entry on the defect. Currently the integration posts the names and version identifiers of the AccuRev files that changed, the user id of the developer who did the change, and the timestamp of the change.

    3. Finally, when a developer or Product Owner using Rally sees the code change, they can set the status of the defect to ‘Fixed’. Ruby code can then be run automatically that looks for all ‘Fixed’ issues in Rally, and changes their status to ‘Fixed’ in AccuWork. It does this by looking for the custom field ‘AccuWork’ created in the first part of the integration, extracting the issue ID number, and formulating an update XML message to AccuWork instructing AccuWork to update the specified issue.

    That’s pretty much it. Working in Ruby and using Rally’s Ruby REST API was very straight-forward, as was working with the AccuRev XML API for querying and updating AccuWork. The end result is an early stage integration that provides basic requirements traceability between issues in AccuWork and Rally, and the coding activities of developers. I hope that if anyone is interested they’ll view the video and let us know what other features they’d like to see, so we can add them to our backlog and to future iterations of this integration in engineering.