Video of My Last Iteration Planning Meeting with CodePlex

Right before I left CodePlex, I filmed my last Iteration Planning Meeting with the team to give you a bird’s eye view into the day in the life of an Agile Program Manager. I did this because last year at the MVP 09 Summit, I invited MVPs to sit in on our IPM. They said they greatly enjoyed watching how we did agile, so I’ve always wanted to video on of our IPMs and put it on the web. Fortunately, I was able to film my last IPM. Better late than never!

The IPM is where we review the weekly work with the team and make any necessary adjustments. For this specific IPM, we were starting an I3 week, which means we reviewed the completed feature work of I2 and would only do bug fixes and other tweaks in I3. (See above link for explanation of I2 and I3 weeks).

I separated our IPM into two parts (videos below):

  1. Review of the work for the week – mostly bug fixes
  2. Review of work that was finished in the previous week – demos

This IPM occurred after the Mercurial deployment in preparation for the Sync’ing Source Code tab with Releases Tab deployment.

I had been wanting to do this sync’ing of change sets and releases tabs for literally years, so it was only fitting that i did it as my final deployment on the team. The idea behind this feature is that you will never again see “No Source Code” in the Source Code tab if the project owner checked his/her sources into the Releases tab. Instead, we carry over the source code from the Releases tab into the Source Code tab. (IMO, the Source Code tab should have always been Source Control *or* we force people to upload source code there, but I digress since this is a moot point now).

Part 1 – Review of work for I3 – In the video below, note we’re just doing bug fixes and tweaks. And note that we’re using the CodePlex software internally to keep track of our work items.

Part 2 – Review of completed work in I2 – Below we’re demo’ing to one another all the new work that would go out in this release, including the Sync’ing Release tab and Source Code tab and the new help page.

Enjoy! And Geaux Agile!

How Agile Works – My Program Manager Cheat Sheet

While cleaning out my office in preparation for my big move to California, I ran across my Agile Program Manager “cheat sheet.” I had to laugh because as I reviewed the document, i thought to myself “This makes so much sense. How did i never get this before?”

When I first joined CodePlex, I was going out of my mind insane trying to figure out what my daily PM responsibilities were. So, in typical Sara Ford-like fashion, I told Jim Newkirk we weren’t going to end our 1-1 weekly meeting until he had outlined what was expected of me as a PM each step of the way in an agile development cycle.

3 hours later, I left Jim’s office with this document.

How Agile Works

Release Overview Diagram

Each number represents an iteration, which is a week of work. I1, I2, and I3 are the development iterations. The majority of a Program Manager’s time is spent in the pre-I1 iterations, named –3, –2, and –1.

The Epic Story – This is what goes on a sticky note on the whiteboard. For example, “Ratings and Reviews for Project releases” is an epic story with the following stories associated with it.

  1. Rate Release
  2. Display ratings and reviews on release page
  3. Display ratings and reviews on project homepage
  4. Move release metadata to new location  // also a UX improvement Epic story
  5. Releases sorted by date with release ratings  // also a UX improvement Epic story

Pre-Iteration Planning Meeting (IPM) Planning (about 10 weeks out from deployment date)

These are the series of Program Manager tasks that need to be completed in this order:

  1. Epic + Proposed Stories are written
  2. Wireframes are designed
  3. Review wireframes with team
  4. Rewrite stories based on wireframes
  5. Prioritize what gets done first in terms of dependences
    1. Think about how non-dependencies can be done later or separately
  6. Talk to developers for high-level estimates
    1. These "stories” should be in terms of < 5 days of work
  7. Talk to test team about acceptance tests

Product Backlog

  • Story must be ready at I1 (the first iteration of development work). This must be actionable work, meaning the developer can grab the story (and wireframe if appropriate) and start coding immediately.
  • Story entered as feature in product backlog
  • Have about 9-10 weeks of work in Product Backlog at all times

Iteration Planning Meeting (IPM)

  • Program Manager –> Developer translation occurs with each story
  • Developer breaks story down into their language and into their own tasks. (again, this is where the dev is in charge of the how and the PM is in charge of the what).
  • The team as a collective aims for how much work they can do in that one week. Everything beyond that is put back into the backlog for re-priorization by the Program Manager for the next IPM

My 3 part series on Agile Program Management on Port 25

In a follow up to my original post on how I learned to program manage an agile team, I’ve put together a 3 part series on how to be an Agile Program Manager over on Port 25.


Community Leadership Summit Trip Report

Community Leadership Summit banner

Jono Bacon, the community manager for the global Ubuntu community, organized the first Community Leadership Summit for community managers to come together and share ideas. I loved the fact it was run as an unconference or open space. I get so much more high quality information from open spaces than I do from traditional style conferences. The saying that the room knows more than the speaker is very true. Just attended an unconference for proof.

It’s been a long time since I’ve attended a conference where all we talked about was community. It was a totally re-energizing experience (as if i needed more energy). Pictures at bottom of blog post.

I hope folks from #cls will swing by the Microsoft booth at OSCON on Weds and Thurs to say hi as i wear my CodePlex banner as a cape. I’m jealous of the Brazilian flag guy. (you had to be there for it.)


  • “Understanding community is about understanding the human condition.”
  • "Everybody deserves to have a great community."
  • "Don’t cut people off before they have a chance to grow.” 
  • "It takes a village to build a program."
  • "It’s amazing what people will do to get a badge on a forum site. If it worked in kindergarten, it will work forever."
  • "Marketing should not be allowed to use the word ‘community.’ They should especially be banned from using the phrase ‘join our community."
  • "In today’s online world we speak glob-ish as our default language"
  • "People like people who help them."

Other Takeaways

  • We need to design a reputation system that goes beyond just what the person does online. We need a way to track offline events, like running user groups, public speaking events, etc.
  • Similar to design personas, we need personas for members who participates in our online communities so we know how best to engage and empower them.
  • You have to assign tasks to community members to make them feel inclusive. Otherwise saying "look at the list" will cause them to leave.
  • People don’t want to take surveys when they are upset with your product. It’s like pouting. You got to make the feedback channel personal.
  • Empower people by asking them “what do you like doing? what do you do best?” The example used here was in a user group meeting, an attendee who wasn’t technical turned out to be a professional meeting organizer. They were significantly more productive in that meeting because of her help.



The Microsoft ( “I am the empire” t-shirt and the Free Software Foundation’s GPLv2 t-shirt.

I am the empire t-shirt with the Free Software Foundation GPLv2 t-shirt

Picture of the CodePlex agile talk suggestion


Thanks again Jono and everyone who helped put together this summit. It was awesome!

How I Learned to Program Manage an Agile Team after 6 years of Waterfall

Agile is the single greatest things a team could do to significantly improve the user experience and quality of their site. Now having said that…

If I could go back in time… 3 things I would tell myself about Agile

For a long time, I’ve said that my biggest job on the CodePlex team is to learn agile. Now I find myself saying “if only I could go back in time, here’s what I would tell myself about agile:”

1. Design and plan for the very next step, instead of designing and planning for the very next feature.

2. Break down work into smallest possible sets. Adding work is fun and rewarding; removing work is painful and risky.

3. Design and plan 80% of the way as the very next step. Use feedback to solve the remaining 20% in the very next step after that.

And there’s probably a 4th point that’s only relevant to a Microsoft Program Manager going from multiple 3-year product cycles to 3 week agile releases:

4. Forget everything you’ve been told about what makes a Program Manager successful at Microsoft. Thinking about this will only drive you insane and make you completely miserable on a real agile team.

Agile: A love / hate relationship

Usually at this point, someone asks me, “so how did you convince your team to do agile?” I have to laugh and say, “It’s the other way around.” The team already consisted of agile people. I was the person with zero agile experience entering the team with my traditional Microsoft software development ways.

To illustrate how clueless I was about agile, during my first week on the team, I had asked a specification question, like how many characters do we allow for a password? And Jim says, “we’ll have to look it up in the test cases.” And I said very proudly from my Visual Studio experience, “Gotta love it when the test cases are the specs.” (yes, I said this to Jim Newkirk, my manager.) To which Jim very calmly replied, “That’s the way it is supposed to be.” And I laughed, and then after a pause, I said in slight horror, “you’re serious, aren’t you?” It was like finding out there was no Santa Claus or you really don’t vote for the President of the United States. The mind just simply can’t comprehend.

Needless to say, the CodePlex team had a lot of “untraining” to do. They estimated it would take about 18 months for me to chill out, and it actually took 18 months for me just to see that agile could actually work well. I still have my moments when my “VS-side” (the traditional program management training) takes over l, but this really stems from me not having enough info to replace #4. After 6 years of being told how everyone views your role in the world, it’s impossible to see it in any other way, especially when you still work in the same company.

And just to get this out of the way now so there’s no confusion… if you asked me personally what i thought of agile, I would say that Agile drives me crazy for reason #4. Why? Well, I was hired straight out of college by the Visual Studio team, so traditional waterfall software development is all I’ve known for 6 years. And since there were so many people in the VS org, everything had to be well-defined, from what was expected from us, how we performed our jobs, etc. At any given point in time, I knew what was expected from me, my dev, my PM (since I was mostly a SDET / tester during my VS career) and how they would do it.

Moving to agile, I knew what they wanted me to do (have meaningful work for the devs to do, and make sure they always have the right work to do), but had no clue how they wanted me to do it. I called it “navigating a labyrinth that had invisible walls outlined with electric fences.” I only learned my way around by making one agile mistake after another agile mistake. It wasn’t really until I decided to try for one week, “I don’t care how I’m evaluated. #4 never existed. And I’ll just see if Rome burns down…” that I actually felt true happiness at work. I’m only sharing my personal feelings to prove that I’m not just drinking from the kool-aid (or anti-kool-aid, in the case of Agile at Microsoft). I really think agile is awesome (see next paragraph), even if it comes to me at great personal cost (see reason #4).

But if you ask me as Sara Ford, the Program Manager of CodePlex, and the author of this blog post, I will tell you that agile is the single greatest things a team could do to significantly improve the user experience and quality of their site. I honestly believe this to be true after everything I’ve seen, even if reason #4 drives me crazy and makes me miserable inside. But as I tell myself to get out of the car each morning, “it’s a chance of a lifetime to fight the evil empire from within!” (yes, you can quote me on that.)

How we build the CodePlex software

Before I can explain the above 3 things, it’s important to understand how we build the CodePlex software, especially if there are any other MSFT Agile PMs out there reading this. (We should start a support group, btw.)

We deploy every 3 weeks using 5 week deployment cycles, as shown below. There’s roughly 2 weeks of new feature work, then 1 week of bug fixing. Then we “cut the RC” (Release Candidate) where we fork the code so Test can start the full test pass (regression) on the RC bits, and the devs can start new feature work on the “main” code branch.

5 Week Deployment Cycle overview

Besides having a very good “very next step” plan ready to go, another reason why agile works for us is that we all sit in a team room, as effective communication is key. Got a question? Ask the room. Never be blocked due to communication. Another inside joke here of the “untraining of SaraF” is how long it took the team to break me of the “don’t interrupt the dev,” a strong motto from my Visual Studio days. Somewhere in month #2 or #3 on the team, I asked someone “so, um, how am I supposed to ask a question out loud to the room.” The answer was, “um, just ask the room.” (see #4)

Now, once again, me as Program Manager thinks a team room is excellent, but it took a little (okay, a lot) to get used to working in a single room of so many people, after years of fighting for a window office. The solution we found was to put me facing the corner of the room – out of sight, out of mind, while giving me the sense of “an office”. Significant job satisfaction improvement with that single tweak.

As show below, all the devs sit together at the pairing stations (to the right), and over on the left is where the test team sits. I later moved to the desk in the bottom left FTW!


We use a variation of “Extreme Programming,” but are 90% following XP. Other agile aspects include

  • One week iterations
  • Test driven development
  • Continuous integration
  • Pair programming
  • Shared workspace
  • Collective ownership of codebase among devs

Why those 3 things are so significant

Now back to me. =D

Jim and Jonathan (bless their hearts) tried their best to explain agile to me, while putting up with all my whining. But I didn’t believe them that Rome isn’t burning (and still don’t to some extent, but to lesser degrees now compared to back then). I’m still expecting the world to end (see #4), but just less often, but there are still some special cases out there that just freak my inner waterfall self out “ARGH!!! WHY ARE YOU MAKING THAT CALL AND NOT ME?! Rome is burning! I’m not doing my job righT And!!!  Oh wait, what’s that? I’m on an agile team and this is my VS-side showing? Everything is fine? Oh, okay, um, nevermind. Let’s open the next bug to triage.”

But, it’s like anything else, until you figure it out for yourself (like leading a horse to water…), listening to instructions over and over is just white noise. (no offense Jim or Jonathan). Or better yet, like I say in karate, you really don’t know a technique until you can teach it to someone else.

Let’s take a look at those 3 things again, but this time in detail, so I can prove (or be disproved) that Agile has clicked for me.

1. Design and plan for the very next step, instead of designing and planning for the very next feature.

In traditional product groups, specifications can be as long as 60 pages. Every scenario must be known at design time and figured out, because you only get one shot of getting it right. The analogy here is firing a gun. You could spend a significant amount of time planning, calculating, aiming to achieve the perfect shot. Or using the agile approach, you could aim and fire, recalculate aim and fire, recalculate aim and fire. You could say that traditional product groups do this to some extent, but a few years is a long time to wait for a recalculated shot.

What I didn’t know when I first joined was that it was “okay” (recall #4) to break down the feature work. I honestly though features had to be designed end-to-end and then squeezed into a deployment. Once I had that glorious light bulb moment of “plan the deployment based on the very next step, not the very next feature,” everything else fell into place.

This first light bulb moment occurred when I wanted to do a particular feature, but the way the designs ended up would have taken us a deployment cycle of 6 months. This of course was unacceptable, and I accidentally found myself saying, “if they would have just scoped it to the very next step I could get started with this…” and that was the moment I realized that agile actually had a structure to it.

2. Break down work into smallest possible sets. Adding work is fun and rewarding; removing work is painful and risky.

Maybe it was light bulb moment #1 going off that enabled the “on” switch for light bulb #2.Towards the end of last summer, I was so exhausted from the book, trying to figure out agile, doing major speaking events, and of course not to mention promoting open source within Microsoft, I decided to “give up” for one particular release and just do the minimum amount of work possible to get the deployment out. I was just too exhausted to worry about enduring the potential wraith of my manager (see #4) for deploying such a small amount of work.

And of course, it turned out that was the ideal amount of feature work for the deployment. I discovered this simply based on the number of bugs that had to be fixed in the 3rd week of the cycle, and how there was no feature work that needed to be carried over to the next deployment cycle. In other words, when I finally “failed” in the traditional program management sense, agile clicked for me. And people wonder why I was a nervous wreck all the time (see #4).

And to explain the second half of this light bulb moment: If there were any feature work we couldn’t squeeze in, it had to be carried over, but yet it wasn’t “planned” this way. Then it was a question of do we finish a half-written feature, or do we pull it out, not fully understanding what other aspects of the feature sets it could affect in this state? We would have to make a best guess decision right before deployment.

Another analogy is like Legos. Break all the pieces down into 1×1 blocks. Then it is easy to plan, add, remove. But the larger the pieces, the more connection points, the more cost, the more complexity. I’m sure there’s some analogy to the connection points (the little bumps on the lego square) and writing the code, but I’m not a developer on an agile team, so I’ll leave that open to interpretation.

3. Design and plan 80% of the way as the very next step. Use feedback to solve the remaining 20% in the very next step after that.

Immediately after light bulb moment #2 clicked, I saw the very reason why agile rocks for customer quality. Using agile, you actually can recalibrate, aim, and fire in a time period that is reasonable for customers (compare 3 weeks to 3 years.)  I’m not talking about overall feature set comparison, but a comparison of the quality of the features being released. It was finally at this point in time I could allow myself (see #4) to take advantage of this “aim fire recalibrate repeat” concept by actually planning the recalibration time period. In other words, I could say “okay, we’re going to go with this, and based on feedback, we’ll tweak as needed in the next deployment.”

In Conclusion

Once these three wonderful light bulbs went off, I demanded from Jim a whiteboard. I had this awesome idea that I could use sticky notes to track all of the individual 1×1 (or 2×2) Legos (as shown below). Then someone (I forget who) said, “That’s how agile teams typically track work.” Part of me wanted to rejoice that I had finally graduated to some level of “I’ve figured out agile,” and part of me wanted to scream, “Why didn’t you tell me this before!?” But they probably tried, and had I listened, I would have had just a big sticky note called “Feature”, and we’re back to day 1 all over again.  


Just some final thoughts about #4, since I refer to it so often. I just want to do the best job I can, because I’m here to fight the culture to make Microsoft better for customers. (I know what it is like to use Visual Studio in college (graduated in 2001) and Microsoft asking me for 250 dollars (my month’s rent) to report a bug about the IDE, hence the “evil empire” reference.) But I’ve been so trained by #4 on how software development should work, that it’s been an uphill battle to learn Agile, even if it think the process produces higher quality results at the end. Jim must spend at least 30 minutes on average with me each week trying to get me to accept that I am doing a good job, even though all of my traditional waterfall training says everything to the contrary. (we should do a podcast of my 1-1s.)

I guess #4 is to a Program Manager like trying to convince a developer to write unit tests or to do pair programming. It’s hard cultural change to accept.

So, to all my fellow real agile PMs at Microsoft, I hope this posts helps in some way and I’m serious about the support group. And to the rest of you, I hope this has been an interesting read to say the least of what’s it like to change the culture at Microsoft, especially when you are quite literally the cultural change.

View original comments

I’ve been deep fried on Deep Fried Bytes – Podcast on book and CodePlex Agile development

Wow, was i tired at the beginning or what? I was in the middle of my southern speaking tour, driving all around the south at all hours of the day and night. I called Keith at 3pm telling him my ETA and to get a pot of coffee going. The caffeine kicked in around the 17 minute mark. If i had know this podcast was going to have such a southern accent to it, i would have just let mine go.

Here’s a time breakdown:

  • First 5 minutes – Cheap shot at Jim Holmes
  • First 10 minutes – Talking about book and Visual Studio Tips
  • 13:56 – Mississippi State Cowbells
  • 17:00 – BillG, Visual Studio, and Cowbells
  • 16:35 – CodePlex
  • 21:00 – Working in a room with 17 people
  • 30:00 – How I’m finally figuring out agile

Kick it:

Kinda funny that Keith thinks i’m a nut. If you’ve ever met Keith, you’ll think it’s a southern thing.

You can subscribe to Deep Fried Bytes via iTunes / Zune at

Thanks ya’ll.

CodePlex Feature Requests Collected from CodeMash – Vote for what you want

At CodeMash 2008, I had an incredible opportunity to meet 1-1 with many various users of CodePlex, from those who run projects to those who download them.  Thanks to everyone for their valuable input and making the time to discuss their ideas with me.  I had an awesome time, and will always try to do an open space at every conference I go to from now on.

Instead of just posting the feedback I received, our dev lead Jonathan suggested I enter work items for everyone to vote on.  So…

Without further ado, here’s what I’ve entered based on our conversations at CodeMash for you to vote on.  Of course, please vote on whatever else you find interesting in the feature wish list.

And BTW, CodePlex is hiring developers!

For those who follow my Visual Studio Tip of the Day series, feature prioritization for CodePlex is actually a part of my real day job =)