Lessons learned on an Agile Microsoft Project

Sara Ford writes about the lessons she learned while managing the CodePlex.com project for Microsoft.

Post 1: http://port25.technet.com/archive/2009/10/19/lessons-i-learned-as-a-project-manager-converting-to-agile.aspx

Post 2: http://port25.technet.com/archive/2009/10/20/part-2-lessons-i-learned-as-a-project-manager-converting-to-agile.aspx

Post 3: http://port25.technet.com/archive/2010/01/20/part-3-lessons-i-learned-as-a-project-manager-converting-to-agile.aspx

From post 3:

On how releases are scheduled/managed:

On CodePlex.com, we deploy every three weeks using five week deployment cycles, as shown below. We spend approximately two weeks of new feature work, with one week of bug fixing/ course correction/ adding more work. Next, we cut the Release Candidate (RC), where we fork the code, so the test team can start the full test pass (regression testing) on the RC bits, and the devs can start new feature work on the "Main" code branch. If we find bugs in the RC, we fix both the RC branch and the Main branch.

Team organization

Besides our three week deployments, the biggest advantage of Agile to me, as the Program Manager, is that we all sit in one team room, with the idea being that the most effective means of communication is key. Got a question? Ask the room. Never be blocked due to communication.

As shown below, all the devs sit together at the pairing stations (to the right), and over on the left is where the test team sits. A few months after taking this photo, I changed seats with the development lead so that I could face the corner. I'm a very visual person, so sitting in the corner is less distracting for me. Just like our feature designs, we even apply the "course correction" concept to our own internal processes, like making this desk change tweak.