by saraford on January 20, 2010 01:29pm
In my previous post, I discussed how "not designing the full 100 percent is a true blessing in disguise" that enables Course Correction in an Agile team. In this post, you'll learn how the CodePlex team puts Agile to work in developing the CodePlex software.
Putting It All Together: How We Build the CodePlex Software
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.
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.
While, for our internal processes, we're using a variation of Extreme Programming (XP), we are following the XP process about 90 percent of the way. Other agile aspects include:
If I could go back in time, this post on my personal blog is what I wished I could have told myself about Agile development on my first day on the CodePlex team. Of course, I realize that every Agile team is different, and the concept of Agile itself has its own challenges, just like any other software engineering methodology.
It is my hope that if you are on an Agile team outside of the development role, these series of blog posts has helped you in some way. I hope that, at least, you've learned that you are not alone in figuring out what agile means to the non-developer disciplines.