The Library Technology team at Lehigh University has grown steadily over the past decade from only one staff member to six. Before the team was formed, in-house development was limited to scripting and API programming of proprietary applications. But as Digital Library1 projects became a successful platform to promote the Lehigh University Libraries’ Special Collections and faculty research, development emphasis evolved into full life cycle development projects using a mixture of open-source and proprietary solutions. The team now supports nearly twenty library services and applications, a widely-used digital library server that hosts more than ten full-text digital collections, and participates significantly in Lehigh’s founding partnership of the Kuali OLE (Open Library Environment) project.2
The Library Technology team has grown through the support of Bruce Taggart, the Vice Provost of Lehigh’s Library and Technology Services. Through approval of high storage servers, shifting of existing staff’s responsibilities, and allocation of appropriate workspace has enabled the Library Technology team’s successful implementation of projects. But with great success comes great responsibility, along with higher expectations.3
As the Library Technology team moved forward, we recognized that coordination would be key, not only in developing new project, but also continuing our support of existing, and highly used, projects. We also realized that without a full-time programmer, we would risk stretching the time and expertise of individual team members, risking a breakdown of the entire process.
With all this in mind, I began to look at project management methodologies that could assist in new project development. Having done a masters thesis on a topic in capital budgeting, I viewed our situation as an economic problem: a scarcity of resource (staff time) to be invested for the highest return. The constraints to solving this problem included a lack of control over prioritization of projects, an increasingly high demand for staff time on existing and new projects, and a lack of awareness or poor estimation of how long projects or tasks would take to implement. Coinciding with my own research, Vice Provost Taggart returned from the annual Educause conference with an offer of training in Agile/Scrum project management.
During the Agile/Scrum training, I realized this could be the right model for the Library Technology team at Lehigh. What needed to be determined following training were identifying who would play the roles of scrum master and product owner, and how the agile methodology could be expanded to a team that included non-programmers. I also needed a clear, effective method to garner support from stakeholders, who up to this point had expected immediate turnaround on tasks they gave to the team. How would stakeholders respond to their tasks put on the sprint “backlog”, a requirement to complete fuller specification details first and/or create user stories before a development sprint could begin? Clearly, Agile would require not only that the Library Technology team adapt to new work processes, but also the organization at large would need to experience a culture shift in their role in project development.
We immediately started breaking some Agile rules by implementing the sprints for three team members only, and assigning myself both roles of scrum master and product owner. The challenge for the team members during the first few sprints was to gauge their own velocities. How many tasks could team members handle in a three-week sprint? How often did obstacles come up to be cleared? And how much real time do they devote to development beyond supporting existing projects. What is an easy complexity unit to base other tasks against? I conservatively expected a 40% effort of development for the first sprints, and included pre-defined support tasks within the sprint to represent other work that may fill in the other 60%. This allowed for the team to objectively visualize on the sprint board what was accomplished and how much was left to do.
I selected a web-based sprint board so stakeholders would be able to see progress online for their convenience, with the hope they would see the same quick results I expected in this new project management strategy. I also intentionally left out estimating complexity points to stories and tasks, and instead asked team members to evaluate their own division of tasks and complexity estimations over the first few sprints. At the end of each sprint, we, as a team, discussed what was left in the To-Do or In-Progress columns, breaking down whether each sprint included too many tasks or if too many obstacles got in the way. We then decided what should roll into the next sprint, or what should be put on a parking lot in favor of higher priority stories.
After a couple of initial sprints, I added two non-programmer members to the sprint team. This allowed the team to work more cohesively and to gain more experience working in pairs or larger groups. Immediately, the team experienced its first success. Where individuals had previously, and tacitly, estimated and accomplished their own set of tasks, they now had a visual representation of effort, and thus a team-based accountability developed. More importantly, team members could share the burden of certain tasks previously assigned to another by learning new skills or simply working together.
While stakeholders could view the progress sprint to sprint, we were not yet ready to plan for future sprints ahead of time. Therefore some stakeholders questioned the priorities of certain stories over others. For our part, the team could now objectively analyze how much of a backlog had developed in the previous ad hoc process of prioritizing projects and recognized we needed to clear some of the obstacles in the backlog before more adopting the more formal intricacies of agile.
With the addition of a new, full-time programmer, the team finally fit into the ideal Agile team size of seven plus or minus two, regardless of whether or not I assigned myself tasks. More importantly, I discovered that I was better suited for the role of product owner, specifically in the relationship with stakeholders. Our digital library project coordinator had natural scrum master skills, and given her non-technical focused work, she fills the role excellently. With these changing roles, I can effectively deal with the obstacles reported to me, and begin focusing on managing the expectations of the stakeholders.
With the addition of the new programmer and completion of role transitions, the team was able to add complexity estimation into the sprint planning meetings, and I started to measure velocities sprint-by-sprint and member-by-member. Not unexpectedly, the learning curve of complexity estimation was high at first, and there was an initial inequitable distribution of complexity points taken on by individuals on the team. With this measure implemented, however, we have been able to more effectively plan sprints, as well as create a parking lot and backlog for future sprints. Through estimating complexity points, the team realized the importance of breaking down tasks as much as possible to allow for successful for prioritization.
After more than six months of sprints, the overall success of implementing Agile with the Library Technology Team is proven by our more focused, more coordinated effort toward new projects. External to the team, certain stakeholders have noted that team morale towards projects has increased and that results are being delivered more quickly and more often. Despite these successes, the challenge of changing the culture of how projects are accomplished in whole sets rather than piecemeal remains. While not unexpected, I continue to work with stakeholders to help them overcome their hesitation in accepting this methodology. As more stakeholders adapt and embrace the use of Agile, I expect to see a cultural shift within the Library and Technology Services organization for project development and support.
The future success of using Agile at Lehigh is still unknown. Will success be limited to individual teams that adopt Agile? Will team successes be thwarted by a lack of acceptance of Agile philosophy or methods from the larger organization? How long will it take until the Agile implementation can be objectively analyzed as a success or failure? Can the example of the Library Technology team’s use of agile even be applied to other teams in the Library and Technology Services organization? As the Library Technology team continues using Agile, leveraging more detailed project management tools for short- and long-term planning will become more important. Using these more formal products and applications will also require a more formal organizational commitment to Agile. That commitment, and the questions above remain to be answered.
 – Lehigh University Digital Library, http://digital.lib.lehigh.edu
 – Kuali OLE Project, http://www.kuali.org/ole
 – Adapted from a famous superhero lesson, http://www.horsepigcow.com/wp-content/greatpower.jpg (Last Accessed Jan 5, 2011)