Port 25: The Open Source Community at Microsoft : Sara Ford

Part 2: Lessons I Learned as a Project Manager Converting to Agile

saraford — Tue, 20 Oct 2009 21:11:00 GMT

In my first post for this series, I stated that "Agile is the single greatest things a team could do to significantly improve the user experience and quality of their website" and "not designing the full 100% is a true blessing in disguise." By putting these two concepts together, you can fully embrace the power that is Agile: Course Correction.

Making Design Changes in Waterfall

In the traditional waterfall, a Program Manager writes a specification, in which all members of the team and the associated business owners review and approve. Then, the development cycle begins to code to the specification word for word. Once code complete, the test team takes over reviewing the code to ensure it matches the specification.

But, what if half way through, someone on the team realizes the specification is wrong? Or more practically, what if the requirements change sometime during development? In my Microsoft experiences, this is called a Design Change Request (or a DCR), and it is extremely costly. New designs need to be made and reincorporated with the rest of the specification. Dev needs to re-code the feature. And the test team has to restart any prior testing, especially for regressions. In other words, DCRs are not good things.

Making Design Changes in Agile

One of the light bulb moments for me on CodePlex.com was accepting the fact that Agile is really just a series of mini waterfalls. Instead of designing a waterfall release cycle that will span the course of several years, you're only designing for a waterfall process of a few weeks. There's a Planning Phase, a Development Phase (which encapsulates the Test Phase, but is beyond the scope of this blog post), and the Deployment Phase. It's waterfall, but waterfall moving at an incredibly fast pace.

Now let's reconsider those Design Change Requests, but on an Agile team. The work is very, very scoped, which implies less ambiguity. (Yes, you could have a perfect specification that isn't ambiguous at all, but if that spec is 60 pages, the risk of human error is higher. Trust me, I've seen this, where I was the human in error.) And, recall that you're only doing 80% of the work. The cost of the design change is already accounted for in the remaining 20% of the development cycle. In other words, it's in the spirit of Agile that you're going to make changes along the way to better the product, or "course correct," as it was initially described to me. In agile, DCRs are good things.

Regardless whether you discover that you need to make a course correction during the Development Phase or the Deployment Phase, it's okay because Agile by its very nature can adapt and respond to these changes quickly.

An Example of Course Correction

Below is a screenshot from the original ratings and reviews designs. Notice how I circled the downloads count.

During implementation, a developer realized that the download count could be confusing. Did it mean total downloads for the entire project, total downloads for the release, or just recent (past 7 days) downloads for the release? We realized that given these designs we couldn't really convey the information we felt necessary to provide the right user experience to our visitors. So, we went back to the design and made a few tweaks. Again, we weren't trying to completely redesign the project directory. Even if we wanted to, there was no time to do anything radical. At the time the developer noticed this issue, we were going to finalize the build for deployment in a little over a week.

What we did instead was "course corrected" by making slight changes to the project metadata on the left-hand side to finish the current feature (or user story, if you're more aware of that terminology). Circled below is the metadata we added. We also added the * next to the number of page views and downloads, where we state at the bottom of the page "in the past 7 days."

Aside: CodePlex shows past 7 days data as a way of reinforcing release early, release often, which we continue today in the project directory. The screenshot below was taken at the time of this writing.

Conclusion of Part 2: Course Correction

This concludes my second post on Program Managing an Agile team.

If you like what you see, let me know! And if you don't like what you see, please don't hesitate to let me know. Seriously, I love discussing my Love / Hate Relationship with Agile development, as depicted on my personal blog.

Up Next: Putting it All Together - How the CodePlex team Builds Software

Part 1: Lessons I Learned as a Project Manager Converting to Agile

saraford — Mon, 19 Oct 2009 19:16:00 GMT

Before I became the Program Manager for CodePlex.com, Microsoft's open source project hosting site, I worked on the Visual Studio team on four different product cycles. Since Visual Studio uses traditional Microsoft product lifecycle releases, I had to learn about Agile development alongside learning about open source development when I joined the CodePlex.com team. Making the switch from releasing every three years to every three weeks didn't happen overnight!

One of the things I discovered is that Agile is used a lot in open source communities. In fact, many of the people who I've worked with personally on learning Agile have strong roots in OSS. Also, the fact that Microsoft is starting to adopt Agile philosophies shows how the company is changing, becoming more transparent, finding more ways to connect with the community, and embracing other schools of thought. And this is why I am here, to be on the inside to push for these cultural changes within Microsoft.

Although Agile is the single greatest thing a team could do to significantly improve the user experience and quality of their website, I believe it can be quite challenging for anyone not in a developer role to get accustomed to. I hope that by sharing my experiences, I can help others in non-developer disciplines on an Agile team.

In this series of blog posts, you'll discover how I learned to program manage an Agile team after six years of waterfall (the traditional method of software development).

Three Major Takeaways

If I could go back in time, here are the three things I would tell myself about Agile.

1. Design and plan for the very next step.

It's not about reaching the moon, but getting out of your front door. Sure, you can design the perfect feature, but if it is going to take you six months to get there, it is useless to an Agile team. It's about designing the journey towards the perfect feature that matters.

2. Break down work into the smallest possible functional sets.

Adding work is fun and rewarding, but removing incomplete work due to a lack of development time is painful and risky. But, you can't deploy a half-written feature either. First, break down the work into the smallest pieces. Then, put together the smallest functional sets that have to be deployed together for the feature to make sense. Your development team will tell you how many sets they can do per release.

3. Design and plan only 80% of the way.

Not designing the full 100% is a true blessing in disguise. Since you have another release right around the corner, you have the time to collect user feedback and incorporate it into the next design. Not only does this solve the remaining 20% (getting you closer to the perfect design with less cost), but also allows your customers to be virtual members of your team.

The Program Manager Release Cycle

To begin, here's an Agile release cycle from the point of view of the Program Manager. For simplicity, this illustration only depicts a single release cycle, without any overlap of previous or future cycles.

Ratings and Reviews: An Example

To further illustrate, consider the ratings and reviews feature on CodePlex.com as an example. Users can rate a release and write a review for projects on CodePlex.

One quick aside about ratings and reviews: CodePlex users rate an individual release instead the entire project. For example, consider Stephen King as an author. What does it mean for me to rate Stephen King 4 out of 5 stars? I find some of his books to be awful, like the Tommyknockers. I want those 7 hours of my life back. 1 out of 5 stars. Yet, for me, some of his other books are incredible, like The Dark Tower. 5 out of 5 stars. Hence, we allow users to rate an individual release to provide more relevant information to potential downloaders of the project.

Let's explore the ratings and reviews feature step-by-step in the Program Manager shoes.

1. Design Phase Part 1: Limit the scope to designing the minimum to make the feature useful and meaningful. For ratings and reviews, the feature must have the following:

a. User can rate a release. User can view the rating.

b. User can write a review. User can read the review.

c. User can sort by highest rated releases in project directory.

2. Design Phase Part 2: Bucket into smallest deployable functional sets. For me, personally, I use sticky notes to illustrate the "must have" pieces for each set.

a. Sticky Note #1: Rate releases / View rating

b. Sticky Note #2: Write a review / read review

c. Sticky Note #2: Sort by highest rated releases

3. Iteration Planning Meeting: To start the development cycle, meet with the development team to discuss costing.

a. In the case of ratings and reviews, my devs said they could do Sticky Notes #1 and #2, but the project directory sorting feature would have to wait for the next release.

4. Dev Cycle: Because the designs are closer to 1-page specifications rather than fully-documented implementations, questions will come up from the dev team. This is where you, the Program Manager, will:

a. Answer any questions about the missing 20% of the specifications / wireframes

b. "Course correct" (more on that later)

c. Add more feature work if time allows

5. Deployment: The release goes live. Now you can collect user feedback and incorporate it into the next development cycle.

a. The very first tweet I saw regarding the ratings and reviews feature was "Sara, is there a way to sort by highest rated?" Here, I was able to ask the user questions about how this feature should work to confirm our designs. Most of the time we don't inform users what's coming up next (we like surprises.) But in this case, it was pretty obvious.

Here's the visual representation of the ratings and reviews feature in the Program Management agile release cycle:

Conclusion of Part 1: The Agile Program Management Cycle

This concludes my first post on Program Managing an Agile team. Since I could go on endlessly writing about topics I'm passionate about (and those who know me will confirm this is not an exaggeration), I'm going to pause here to conclude this initial train of thought.

Up next: The concept of Course Correction.

CodePlex: A Year in Review

Peter Galli — Tue, 27 Jan 2009 00:52:00 GMT

CodePlex, Microsoft's open source project hosting Web site, has grown by leaps and bounds over the past calendar year. Visits to the Website more than doubled to top 19-million in 2008, while new registered users were up more than 70 percent to over 66,000 and the number of new projects more than doubled to 4,542 over the year.

That brings the grand CodePlex total to more than 120,000 registered users and 7,500 projects.

According to a blog by Sara Ford, the Program Manager for CodePlex, there were 12 new releases of the CodePlex software over the year, with new features including Subversion client support; an upgraded UI; Silverlight hosting; an AJAX Source code browser; and Search improvements.

The top five Open Source projects created in 2008, by page view count, were WPF, the main site for updates on the WPF roadmap and the portal for accessing the WPF Toolkit and the WPF Futures releases; the Silverlight Toolkit, a collection of Silverlight controls, components and utilities made available outside the normal Silverlight release cycle; the CompositeWPF, designed to help users more easily build enterprise-level Windows Presentation Foundation and Silverlight client applications; MVCSamples, prototype and sample ASP.NET MVC Sample applications; and the Unity Application Block, a lightweight extensible dependency injection container with support for constructor, property, and method call injection.

Also, earlier this month, DotNetNuke Corporation, the creator of the industry-leading DotNetNuke development framework, decided to leverage the CodePlex infrastructure for its core product distribution. DotNetNuke said it would utilize CodePlex for download infrastructure, bandwidth, and metrics reporting for its core product offerings. Until now, DotNetNuke had been leveraging services from SourceForge.Net.

So, what's next you may ask? Well, Sara and the team are eagerly waiting for your feedback and suggestions.

DotNetNuke Moves to CodePlex

Peter Galli — Wed, 07 Jan 2009 22:31:00 GMT

DotNetNuke Corporation, the creator of the industry-leading DotNetNuke development framework, has decided to leverage the CodePlex infrastructure for its core product distribution.

DotNetNuke will utilize CodePlex for download infrastructure, bandwidth, and metrics reporting for its core product offerings. Until now, DotNetNuke had been leveraging services from SourceForge.Net. DotNetNuke is also currently the second most commonly downloaded project on CodePlex.

Last February, DotNetNuke Corporation announced the availability of the DotNetNuke Forge, the prime destination for open source collaboration on the DotNetNuke platform. The DotNetNuke Forge has grown in breadth and popularity over the past year and now represents a vital part of the DotNetNuke ecosystem.

The DotNetNuke Corporation researched the many open source project hosting services available, and decided that CodePlex provided the "most reliable and dependable infrastructure, cleanest user experience, most advanced project administration tools, and highest commitment to future innovation," said Scott Willhite, its Co-Founder and Community Director.

CodePlex Program Manager Sara Ford says Microsoft is excited about having DotNetNuke join the CodePlex community and, as the leading open source web application framework for ASP.NET, the CodePlex team is looking forward to partnering with them to promote open source development on the Microsoft platform.

The team is also looking forward to hearing the feedback from the DotNetNuke community for improving the open source development experience on CodePlex.

An interview with Codeplex's Sara Ford

Sam Ramji — Thu, 16 Oct 2008 21:20:00 GMT

It has been a month or so since the Codeplex announcement of server support for SVNBridge, which enables TortoiseSVN to talk to Team Foundation Server, and the team is looking for feedback now this has been out for a while. I also recently interviewed Codeplex's Sara Ford on this, and wanted to share her responses with you.

Sam Ramji: So, Sara - this has been a top request for some time. What are the most interesting comments you've received requesting this feature?

Sara Ford: There have been countless requests and comments for this feature, but one of the more memorable ones when we first announced the SVNBridge project last year is "It's so crazy it just might work," was one.

Many of our users view CodePlex, when compared to other open source hosting sites, as Team Foundation Server (TFS) versus Subversion (SVN). Now, our users can use either TFS or SVN clients against any of our projects. It's like soccer fans and American football fans are unexpectedly findings themselves in the same arena, conversing for the first time.

Sam Ramji: What made it hard to deliver this feature?

Sara Ford: When we first started investigating this, we were skeptical that it could be done, since TortoiseSVN and Team Explorer are so different. But once we began comparing the protocols used for Subversion and Team Foundation Server, we were surprised by how much of it could easily be translated. So a lot of things started working quickly, but there were a couple of areas that didn't map directly, and those represented the bulk of the effort to get all the kinks worked out.

Sam Ramji: What can Subversion fans expect next from Codeplex?

Sara Ford: Well, as always, we look at the features users have voted the highest on the CodePlex Issue Tracker. Now that we're closing our number one most requested feature, we're asking our Subversion fans to visit our Issue Tracker and start voting for what they want to see next!

Sam Ramji: It's interesting that now we have Subversion support in Visual Studio through the AnkhSVN project, and SvnBridge support from Codeplex on the server side. You can probably do round trips via SVN from Visual Studio to Codeplex. Interesting? Or just plain strange?

Sara Ford: VisualSVN and AnkhSVN are both popular plug-ins for Visual Studio that provide integrated IDE support for Subversion, and several users have mentioned they've tried them against CodePlex and they work great! We really like the idea of providing the broadest support for different clients and tools, so users can pick the tools they prefer.

Influencing the Microsoft culture one open source presentation at a time

jcannon — Wed, 14 Mar 2007 17:38:00 GMT

Today, a lighter post and link to Sara Ford's blog which talks about her recent presentation to Microsoft employees entitled, "Embracing Open Source on Codeplex." Sara, a developer/evangelist with Microsoft on the Visual Studio Powertoys team, has been a tireless supporter and advocate of change internally on identifying when & where it makes sense to embrace open source collaboration and licensing styles through offerings like Codeplex and Shared Source.

Sara's post (and some great pictures of grassroots marketing here on campus can be found here.

Lessons from OSCON Part 2: Sara Ford interviews James Howison

MichaelF — Tue, 03 Oct 2006 20:42:00 GMT

About a month ago, I did a presentation on What I Learned from OSCON, based primarily on James Howison's talk on OSS Communities. Since James had such great and interesting feedback on my presentation, we decided to do a follow-up podcast. I'm trying to publically capture as much of this journey as possible of a team at Microsoft learning how to go open. Maybe this journey will make for an interesting OSCON '07 talk, I hope. =)

-sara

Introductions:

James Howison is a doctoral student on Kevin Crowston's NSF-funded research team at the Syracuse University Information School and a regular presenter at O’Reilly events. At OSCON '06, James gave a talk on OSS Communities, where Sara Ford took notes until her fingers went numb.

Sara Ford is the Program Manager for the Power Toys for Visual Studio. Her mission is to explore the various ways Microsoft developers can have conversations with the Visual Studio community at the source code level, while providing great after-market solutions to developer pain-points via Shared Source.