Monday, October 04, 2010

The Go.OSU URL Shortening Service: Agile Development in Practice

About a year ago, I wrote about the idea of a creating a University-branded URL shortening service. Late last month, a small team that I collaborated with at Ohio State launched such a service, called Go.OSU.

Right after I wrote my post last year, I created a short project description and shopped the idea around to potential partners. My primary selling point was that the service would leverage the authority of the OSU brand to the shortened URLs that are included in social media, publications, etc. Although I received a lot of positive feedback about the idea, many potential partners were caught up with other projects.

Since there was so much positive feedback on the idea, this Spring I shopped the idea to the Office of the CIO. While receptive, the OCIO suggested that I build a business case document for them to consider. The idea would be vetted through their review process and, if it past that first level of review, the idea would be placed on a list along with other projects seeking funding. The project would move ahead into development if it received funding, or if other support was identified.

Although I appreciate the reality that projects at that level of an organization need to fit into processes and workflow, my gut said that this review process could take at least a year. It wasn't a very agile approach for a such a lightweight project.

Later in the Spring, I was walking through a hallway at a conference on campus when I heard my name mentioned. It was Beth Black, a University Libraries colleague, and Ted Hattemer, from University Marketing Communications, talking about the idea. I jumped into the conversation. In literally 10 minutes, a decision was made that the project would be developed jointly by UL and UMC and that Ted was on board as our (very supportive) sponsor.

No committee consensus.
No formal meeting.
No user survey / needs analysis.

A few weeks later Jim Muir, a developer on Beth's team, demoed for the project team a working prototype. A few weeks! How agile is that?

We pounded on it for a couple weeks and sent Jim all our feedback so he could make changes. Ted brought in one of his designers, Jim Burgoon, to assist the other Jim with the interface design. The project didn't move ahead too quickly over that next couple months due to competing priorities. The project regained momentum in the early summer and was finally launched after we addressed security and legal issues.

Libraries are always talking about the need to be innovative and to take advantage of emerging technologies. Yet, they slow it all down by forcing ideas and fledgling projects to go through formalized systems. As this project shows, innovation is not born in committee and through process. It is born from half-baked ideas and serendipitous meetings and grows by NOT adhering to formal processes or traditional methodologies.
Sphere: Related Content

No comments: