Problems and Pitfalls of Museum Project Management
Effective project management is crucial to the success of almost any project. This management can be difficult when faced with an ambitious project on a tight schedule where project partners are scattered across many miles. Museums face these challenges every day as they coordinate and plan new exhibitions, Web site content and educational programming. Managing the unknowns of projects and budgets is a reality for most museum professionals, but delivering results that are on time and meet expectations is often a difficult task.
Like other staff in the museum, museum technology teams commonly work within the confines of their own departments. Consequently when approached with the challenge of working collaboratively on the authoring of software projects, these teams need to find new ways to work together efficiently.
Our Specific Case: Challenges of steve.museum
The steve.museum project is focused on doing research related to the use of social tagging by museums and developing software that museums can use to make social tagging a reality for their institutions. From its early days, the project has had the additional goal of proving that distributed and diverse teams of museum professionals can work together on projects for the mutual benefit of their institutions and the broader community. The project is composed of team members from over a dozen different institutions, as well as other partners. The team is distributed geographically across the United States and collaborates with several international partners. Project members come from a diverse background of expertise and knowledge and include museum educators, administrators, research professionals, information specialists and software developers. Faced with an ambitious project, with tight schedules and budgets, and with the added requirement of enabling broad participation; the software development team of the steve project embarked on building a suite of tools to research the usefulness of social tagging for on-line museum collections.
The steve.museum project is certainly not the first to attempt such broad collaboration. Other communities have shared our difficulties with project management as well. In seeking to mitigate these difficulties, the software development community has worked to create project management methods that attempt to quantify the risks and scheduling difficulties inherent in any project. Over many years and projects, this community has tried and failed numerous different systems for managing complex projects. They have also learned many lessons that can be helpful to the museum community in planning our own projects.
After early missteps, the steve development team decided to adopt many of the practices of agile software development, a strategy for managing software projects. In the remainder of this paper, we will describe how the team started with little or no formal method and through necessity began shaping a working method into a prescriptive and repeatable process. We will go on to describe the features and benefits of agile project management and explain why they might be useful for a broad range of collaborative projects conducted by the museum community.
An Agile Overview
As mentioned above, Agile Project Management is a technique currently used in the software development community to address many pitfalls of project management. In contrast to other project management techniques, agile methods directly address the roles of the customer in the planning and development process, as well as the probability of changes in assumptions and requirements that will undoubtedly occur in most projects.
In 2001, leaders of various camps of the software industry met and created the Agile Manifesto which declared:
Individuals and
interactions over processes and tools;
Working software over comprehensive documentation;
Customer collaboration over contract negotiation;
Responding to change over following a plan. (Manifesto for Agile Software Development – http://www.agilemanifesto.org)
Out of these principles came working methods that sought to mitigate many of the obstacles of project management: difficulty estimating cost, risk, and schedule; adapting to shifting requirements; prioritization of critical path tasks; and dealing with the many different types of personalities involved in a project.
This paper is not intended as an overview of the various flavors of agile methods; interested readers might consult Cohn (2005), Beck (2004), or Schwarber (2004) for more specific descriptions on the use of these methods in the software development community.
A Speedy Overview of Steve's Agile Methods
The project begins like any other project. Brainstorming is accomplished; ideas fight against other ideas, nice people compromise. For the steve.museum project, the collaborative process inherent in agile development has become crucial and provides perhaps the best way for partners with experience in many different areas to actually have a voice in how the software gets developed. In our working methodology these discussions and brainstorming sessions are the beginning of the process of Specification.
Creating software specification and requirements documents is historically a difficult and contentious process of rigidly locking in the work that is to be accomplished in the entire duration of a project. Typically, software developers and customers have a hard time understanding each other and communicating clearly about what specifically needs to be accomplished for the project to succeed. The steve team chose to break the specification process down into smaller pieces consisting of Milestones, Epics and Stories.
Milestones
Due to their basis in real world activity, milestones are the easiest unit of project management for a large team to focus on. They can be described in common language, and the thinking about how they are constructed does not require any specific knowledge of software design or development. An example of a milestone in the development of the steve tagger was the “Look Closer” milestone. This represented the need for users to be able to see details of an image by displaying a higher resolution image through enlargement or zoom. Each milestone represents one concrete set of outcomes that can stand alone as its own piece of software.
Epics
Once the milestones of the project begin to solidify, the team can move from defining high-level features to articulating the logical progression of the use of the software through the creation of epics. At this stage of the process, epics are not yet technical, but merely more specific about how each of the milestones can be accomplished. An example of an epic from the steve project is, “A user should be able to add, edit, and delete tags related to an image on the screen.” Epics are useful in walking the team through the things that occur when a user follows the steps required to make something happen in the software. While useful for the entire team to better understand a logical flow of execution, epics are not yet at the level from which developers can proceed with programming tasks.
Stories
After the epics are finalized, they can be broken down into smaller tasks called stories. Stories are small discrete tasks described in common language, but of sufficient detail to enable developers to begin the software development process. If needed, developers can break stories down into tasks, technically detailed pieces of work needed to meet the requirements of stories. Tasks at this level only need to be understood by the technical project team and are for their own benefit in meeting the objectives of the project. Once the team has finished the creation of milestones, epics and stories, the specification phase of the project is complete.
An Educated Guess…
One of the most difficult parts of successfully managing complex projects involves the estimation of how long any particular set of work will take. Agile project methods address this difficulty by working in short development cycles that result in usable software at each iteration of the cycle. The software development team makes use of the milestones, epics and stories created in the specification phase to choose work for each member of the team to accomplish within any particular phase of development. Stories are assigned points by team members based on the estimated amount of effort needed to complete the story. It should be noted that this is not specifically a time estimate, but a relative guess at how hard any story is, compared to other stories. In points budgeting sessions, all members of the team, regardless of their background, indicate the number of points they feel is appropriate for a given task. Early on in the steve development, these estimates varied widely, with one developer assigning five points to a task and a non-developer assigning two points. These situations gave the team a chance to think systematically about the implications of desired software functionality and design and to clarify issues that might have led to disagreement later on in the process.
During each phase, developers select stories to complete during that time period. At the end of the period, developers calculate how many story points they were able to complete during that period. As cycles continue and estimation is refined further, developers are able to better estimate how many points are reasonable to complete in a fixed time frame. This is known as a developer’s velocity. Knowing the different velocities of team members enables the team to estimate more accurately the time needed to complete a project.
Big Things are Made from Small Things
A key tenet of agile software development is that each development cycle includes the testing of stories completed in that cycle. The commitment of the team is to produce working software at each phase, thereby moving the project forward in baby steps each time a cycle is completed. There are several different benefits to this commitment. First, at the end of a development cycle, the software has to work, with no errors, even though the incremental changes in features may be modest. This results in much higher software quality for the overall project since testing is not left to the end of the project. It is much easier to diagnose and fully test small pieces of code on a continual basis as opposed to the testing of an entire system after all the work has been completed.
Unit Testing, User Acceptance Testing, and Why Evaluation Isn't a Party at the End
The agile methods used by the steve team rely on two different types of
testing. The first type is called Unit Testing. Unit Testing involves writing
small bits of software which assert that the results of each story match the
expected results. Unit Tests are preserved across development cycles. This
enables the checking of legacy software to ensure that the newest changes in
the code does not break features that worked in the previous development
cycles.
Another important piece of testing is called User Acceptance Testing or UAT.
User Acceptance Testing provides a mechanism to ensure that actual users agree
with the project’s developers that the software works according to the
specifications. As the software
nears completion, the team drafts a script of what tasks the software should
perform and what the expected outcomes of each step are. For example, a UAT
script for a Web site with accounts and logins might be, "The user
attempts to log in with the wrong password." The expected result for that
test would be, "The user is returned to the log-in page with an error
informing them that the user name or password is incorrect."
Ideas Occur, Plans Change, and Life Goes On
The team’s commitment to software quality has another far more important benefit. By creating usable software at each step, we create places for sanity checking to occur. Team members from the larger project are able to check on the software progress and ensure that it really meets their needs, rather than simply following the specifications to the letter. This process allows non-technical members of the project to stay involved with the software development during each cycle. As the software continues to mature, these sanity checks also allow the team to decide that it would be better to go in a different direction, allowing the team to be more ‘agile’ in addressing new challenges that were not envisioned during the specification process. Sometimes external forces cause changes to the original plan. Other times, new solutions become clearer as the team continues to work through the details. Since the agile methods haven't wedded us to an enormous plan, we have greater ability to change the direction of the software as it is being built.
Taking Time to Reflect
Agile working methods often include retrospective meetings at the end of each development cycle. The steve team held software retrospectives at our semi-annual meetings which served as both the conclusion of the previous development cycle and the beginning of the next cycle. We borrowed heavily from the format of agile retrospectives described by Derby et al. in Agile Retrospectives: Making Good Teams Great (2006).
Prior to the retrospective meeting, each member of the team was tasked with helping enumerate the timeline of events in the previous development cycle. At the beginning of each retrospective meeting, each team member “checks in” by sharing with the group a simple statement about what he or she wants to achieve through the process. These comments often tend to describe team members wanting to work out kinks in the development process in order to deliver better or faster results.
Following the check-in, the group proceeds with an analysis of team members’ emotional state at each point in the timeline. Examples of team members’ comments on emotional state are comments such as, “On the initial call determining the scope of this development cycle, I was excited about the tools we were planning to use to compile the code,” or “during the delay in our delivery of a working test application in late November, I felt confused because I didn’t know what was expected of me as a member of the team.” Team members may also indicate their emotional states by indicating satisfaction with the process on a scale of 0 to 5, 0 being “very upset” and 5 being “couldn’t be happier.”
The next activity in the retrospective is called the “Fishbone.” This exercise is designed to explore the problems that are identified in the emotional state analysis. In the fishbone, the group tries to identify root causes of dissatisfaction with the process by investigating the questions of who, when, and where. We split the “bones” of the fish into the following categories: Methods; Machines; Materials; Staffing; Place; Procedure; People; Policies; Surroundings; Suppliers; Systems and Skills.
After fleshing out the questions around the difficulties encountered in the development cycle, the group moves on to creating an action plan for improving the process in future cycles. Examples of action items from steve retrospectives include modifying the tools that we used for communication, being conscious of the need to notify others when tasks were completed, and having clearer guidelines for the use of development resources.
By allowing the team to regularly check the temperature of the project, agile retrospectives made the steve development team more comfortable with one another, established clear lines of communication in a non-hierarchical project team, and increased productivity.
Some Final Thoughts
As described in this paper, the steve development team employed several different agile project management methods in order to overcome several challenges facing the team of international collaborators. By involving both technical and non-technical team members in the development process, all team members had a greater investment in the success of the project. Technical staff became more sensitive to the real-world effects of architectural or design issues, while non-technical program staff gained a better understanding of the resource requirements and long-term implications of the many decisions that are taken in developing software. The team was able to bridge the gap of understanding that often exists between technical and non-technical team members and to avoid the consequences that often follow these common misunderstandings.
The modular “working software” approach of agile development allows members of the larger steve team who are not directly involved in software development to check in on the project at regular intervals. It also allows staff beyond the development team the opportunity to be involved in testing throughout the process. In this way the software delivered at the end of each cycle is better suited to the needs of the client and better tested than software that has not been seen by actual users.
The short intervals of the agile development cycles allowed the steve team to adapt quickly to changing requirements while delivering software on-time and on-budget. Weekly calls of the development team kept the team informed about the process and limited the slow-down of the process if a team member was unavailable for a week or two. The communication involved in using agile methods ensured that the goals, problems, and plans of the project were understood by all team members, and this led to better results.
The use of these methods is not a panacea. A solid commitment to the repeated use of these methods is critical. Initially, the perceived addition of the burden of these methods seemed overwhelming. Indeed, adhering to such a structured method of working together requires discipline and persistence from the team. It was only after following these methods for some period of time that the benefits of the model became apparent. Admittedly, this requires some bit of faith on the part of a new convert to using agile methods. Perspective project managers should forewarn their team that the process will be difficult and will require self-discipline in the initial stages. Suggesting a trial period of a certain number of development cycles will allow the team to agree to a limited test period, followed by a retrospective in which a more permanent adoption of these methods can be discussed.
References
Beck, K & C. Andres, (2004). Extreme Programming Explained: Embrace Change (2nd Edition). Addison-Wesley Professional.
Cohn, M. (2005). Agile Estimating and Planning. Prentice Hall PTR.
Derby, E., D. Larsen & K. Schwaber (2006). Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf.
Schwaber, K.(2004). Agile Project Management with Scrum. Microsoft Press.
