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