I’ve barely blogged at all for the past several months, and the main reason is that my new job has been keeping me busy, and using up my creative energy. But it’s all good – I’m enjoying the challenges. In case you missed my previous tweets about it, I’m now Director of the 14 person web team in U Penn’s School of Medicine Information Services. I’ve been a member of the team for 5 years, so my role is new but much of the territory is familiar.

Our team has created over 80 web-based applications (including our own development framework), and well over 150 static web sites, and we’re adding new applications and sites all the time. It’s amazing work for such a small group. Check out the portfolio of some of our static sites, and here’s an example of one of our applications: the PennMed Clinical Trials search site (most of our application are for internal PennMed use only, so this is one of just a few that are public).

We’ve started two pilot projects with scrum, which is an “agile” methodology (click the link for a basic definition). Currently, we have a workflow that’s evolved over the years, and is scrum-like in some respects: we expect and allow change, we communicate frequently with our clients. But we’ve held on to “waterfall”-like habits, mainly because of how we were educated as programmers: we try to model as much as possible up front, then we build all the tables, then code all the business logic, etc. Because we are caught between these two approaches, we often run into frustrations: we’ve tended to see refactoring as an indication that we did something wrong up front, we’ve never been sure about the right ways to document our work, and we’ve struggled with scheduling and allocating resources.

I gave a presentation to our team last week on why we’re evaluating scrum, and why we’re doing it now. There’s nothing top secret about it, so I’ve uploaded it to SlideShare, and it’s embedded below.

UPDATE 12/3/2010: I’ve revised and replaced the original slideshow: