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

CodePlex launches support for TortoiseSVN

jcannon — Tue, 16 Sep 2008 17:24:00 GMT

From our very own Sara Ford, word comes of Codeplex now offering server support for SvnBridge. SvnBridge enables TortoiseSVN to talk to Team Foundation Server. From Sara, "Support for Subversion has been our number one requested feature, and by hosting SvnBridge, our users can now use their favorite Subversion client with any project." Read the full blog here.

A picture says a thousand words:

Featured Project: Family.Show on Codeplex

jcannon — Tue, 27 May 2008 16:09:00 GMT

Over the course of the past year, we've highlighted various community and open source projects on Codeplex. This morning, I wanted to do the same with a very cool open source project that I came across over the weekend called Family.Show. Family.Show is a genealogy project that visualizes family mapping and relationships. The project was released in July 2007 and it's currently at version 2. While the project is backed by Vertigo Software, it is Open Source and licensed under the Microsoft Public License.

Here's a small screen grab from the project home page:

Over the weekend, I used some free time & a family BBQ to start building my own family tree. Frankly, while I'm impressed with the application and it's ease-of-use, I was more amazed at the interest and enjoyment everyone in my family experienced using it. Everybody from my 83 year old grandmother to my 19 year old sister were excited to explore and add to the family tree. It gives new meaning to the collaborative potential of open source :>

See above, the Cannon family tree (yikes) - but infinitely fascinating to self-described family historians. It's worth noting that Family.Show also supports the import/export of GEDCOM standard files, so your work can interchange with other genealogy software packages as well.

I encourage anyone interested to download & tinker with it. Additionally, here are some additional resources:

Visit the Codeplex project home page
Family.Show at MIX07
Watch a Channel9 Video with the core development team

-Jamie

Port 25: The Open Source Community at Microsoft : Codeplex, Dev Center

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

CodePlex launches support for TortoiseSVN

Featured Project: Family.Show on Codeplex