Many of today’s agile software suites have the ability to integrate with various source (revision) control systems. In theory, this allows the agile team visibility into code updates through their check-ins, but most importantly it matches each check-in to the applicable user story, iteration story or task. In practicality however, there are some ground work items which must be in-place to benefit from this functionality. Just like CRM or ITSM software implementations, a process must be in place before the software will show true return-on-investment (ROI) and long term user adoption.
The following process items are important if you want to use your source/version control system to enhance the visibility into your agile development:
1.Each team member must have their own source control login
Although it may go without saying, each team member must have their own login to the source (revision) control system. Without this, there is not traceability to which user contributed to the user story, iteration story or task.
2.Comments, Notes, Messages on each Check-in
A long standing practice in programming is that code should be commented to enhance readability and therefore maintainability. Why should a check-in to source control be any different? The comments on each check-in should be detailed enough to indicate a summary of the changes for what is being checked in but not too detailed that it takes more than a minute or two to write.
3.Story or Task Reference Number
Along the same lines as point #2, each check-in should link to the unique reference number for the applicable user story, iteration story or task. Every source control software system & agile software suite seems to handle this differently with some systems reading the card # or story # directly from the comments box and some having a specific field to capture this data.
If your agile software suite supports an integration to your source control system than you can monitor check-ins directly from within. If however you are limited to what your source control provides, so try to find a view that provide a running list of checkins or use a tool like SVN-Monitor (which I highly reccomend).
Start looking for the following things and soon you will see the power of this new data feed. Just a few of which are:
1) Compare Standup Meetings to Checkins
Compare what is said at your daily standup meetings to what is being checked-in. This is not a matter of not trusting your team, but simply providing more granularity to standup updates. Is there a team member who’s standup’s seem week, but checkins prove otherwise? Perhaps you’ve noticed a developer that recently checked in a large item but forgot to mention the change during the standup? Use this insight to mentor your team members of the importance of standup meetings, and improve you Agile adoption.
2) Maintain Visbility During Busy Periods
During busy periods or very quick iterations (less than 1 week), the team may find tracking development tasks in the agile tool too tedious. You know their doing work, and by monitoring source control you will get a good sense of the progress on user & interation stories even if they aren’t tracking it in the agile tool. Do not let the team slip on tracking progress on user & iteration stories however!
3) Metrics on Developers/User Story, Check-ins/User Story
As they say you can have “Too many cooks in the kitchen.” Any experienced developer or team lead has been part of this a time or two. If too many developers are working on one piece of code, sometimes they can interfere with each others development. The ultimate result is code which is complex to read and more prone to defects.
Now to take this back to Agile… Ever wonder how many developers should contribute to a single user story? Too few and you create silos of knowledge, too many and you may find challenges maintaining the code implemented in the user story in the future. In my experience, I try to stick to no more than 3-4 developers per a 3 week user story. Monitor your metric and find the balance that works best in your unique environment. Remember no size fits all.
You can monitor a simular metric of # of check-ins per user story. Mainly with this one metric you will want to watch for trends between user stories and you will likely find more complex user stories have more checkins. You may therefore want to keep a watchfull eye on the release of these user stories.
I hope you find some concepts that you can leverage in your environment. Until next time….