Follow-up Post of ‘AllSCM.com in Print Media’
Davy Hua on Nov 06 2007 at 10:48 am | Filed under: SCM Basics, Tools and Processes
This is the list I contributed to the articles of “Ch-Ch-Changes” in issue 185 of SD Times. Some were left out, but the few that were used carry tremendous values as well.
SCM Best Practices:
A. Continuous Integration - This build model is a must for any agile SCM team as the benefit of automation will greatly enhance the team’s overall productivity output.
B. Daily Stand Up Meetings - Designed to be short (5-15mins) which explains the stand up part. These meetings are meant resolve obstacles any of the team members may be experiencing at the moment quickly and efficiently. No more phone/Email tagging!
C. Iteration: Maintain an iteration schedule, the shorter the better (about 2 weeks to a month is a good range).
D. Accurate Iteration Planning: Only bite what you can chew. Same holds true for any SCM team — plan only a limited number of projects the team can realistically finish in an iteration.
E. Service Agreement: Whether this is an agreement between the IT group regarding server management of the build farm servers or with the QA group for release management; having such agreements will help to enforce processes and define roles with precision.
SCM Common Pitfalls:
A. Lack of Documentation: The evolution of an agile SCM team is continuous and intense. Without proper and detail documentation, organizations open themselves up for potential problems down the road should the SCM team/person leave the company without giving it enough time to train or hire a replacement.
B. Staffing Resources: SCM activities and services can expand rapidly and if the company lacks proper resources to hire more SCM, the current ones will be inundated and soon the company may find themselves with two-weeks notices. The same can be said for equipment resources as well.
C. Lack of Backup Plans: Backup plans such as the ability to reproduce a specific build for audit or bug fixing purposes are crucial. Companies often overlook the needs for these plans.
This is very good idea! I thought it can enhance the team’s overall productivity output.
You’ve just described (perfectly) the direction the company I work for is moving. I guess it’s pretty common for agile development shops to follow similar practices … but for the love of God, I wish someone would get people to understand that a scrum is supposed to be short! It’s about removing obsticals to progress, not being social…