Building the car while driving it: Using Agile methodologies for changing project scopes

Sarah Wambold, Metropolitan Museum of Art, USA, Marty Spellerberg, Spellerberg Associates, USA

Abstract

Keywords: agile, cms, project management, redesign, development, digital strategy

1. The problem

A familiar story: A digital project looms. The project team is assembled. Ideas are recruited, fostering inclusivity and garnering investment. Stakeholders express opinions on which features, problems, and solutions are most important to address. A kickoff meeting attempts to capture project scope. The team begins to work. And then… priorities shift, features creep, budgets disappear, staff changes, different problems are identified; and as the original project becomes unrecognizable, a new, shinier project comes into focus. Deadlines slip, and the longer the project takes, the once-bedrock requirements, deadlines, and priorities become shifting sands.

Through a series of projects—and “aha moments”—spread across years and institutions, we developed a new approach to this familiar problem. By “building the car while driving it,” we discovered that reframing these conditions as opportunities improved not only the way we work but also our relationships and the projects we produce.

2. A revelatory project

It’s 2008, and the Art Gallery of Ontario is preparing to reopen with a hugely expanded collection, a new building by Gehry Partners, and a new visual identity by Bruce Mau Design. The Gallery’s website will also relaunch, and the project team has spent the past year doing research and discovery for a comprehensive redesign project. Incorporating a new visual design, a reconsidered information architecture, a new content management system (CMS), and fresh content, the launch of the new website will be timed to coincide with the brand re-launch. In other words, many major project timelines are converging on a single, very important date. But as this date approaches, we realize something terrible—the new site’s CMS development and content migration is far behind schedule. The new site is simply not going to be ready in time for the big day!

We conclude that we don’t actually need to launch the whole of the “new site.” Instead, we just need to launch the public-facing elements—the new logo, look, and navigation—the elements that tie directly to the identity launch. The back-end work, while essential to the site’s long-term management and growth, is free to be rolled out on its own timeline.

In short order, we apply the new look and navigation to the “old site” and launch the changes in time for the reopening. Later, once all the testing is done and without any pressure, we quietly substitute in the CMS. About six months later, we “redesign” again, based on more research, and about nine months after that we launch more features, building on what came before. The process was revelatory.

The “traditional” way of building websites is incredibly, unacceptably risky. By managing project aspects independently—as we did at the Gallery—we can minimize our exposure so that if something goes awry with one aspect, it doesn’t affect others. This, and other tools of the Agile approach, give us the resources we need to mitigate risk.

3. Inherent risks of digital projects

The threats to a successful, seamless, on-time, and on-budget launch are many. In Extreme Programming Explained, Kent Beck (2000, 3) articulates that:

• Schedules slip: The day for delivery comes, and you have to tell stakeholders that the project won’t be ready for another six months.
• Projects get canceled: After numerous slips, the project is canceled.
• System goes sour: The project is successfully launched, but after a couple of months or years the cost and/or labor of making changes, or the defect rate rises so much that the system must be replaced.
• Priorities misunderstood: The project launches, but it doesn’t solve the problem or address the priorities that were originally posed.
• Priorities change: The project launches, but the priorities it was designed to address were replaced six months ago by other, more pressing priorities.
• False feature rich: The project has a host of potentially interesting features, all of which were fun to develop, but none of which meets the users’ needs.
• Staff turnover: People leave and take with them a wealth of project intelligence and institutional knowledge.

For the museum sector, Seb Chan and Jane Finnis cite:

1. The project wasn’t right for the organization (or the organization wasn’t right for the project)
2. Tech in search of a problem
3. Must-be-invented-here syndrome
4. Know thy end-users
5. Trying to please donors rather than beneficiaries (and chasing small pots of money)
6. Forgetting people
7. Feature creep
8. Lack of a backup plan
9. Not connecting with local needs
10. Not knowing when to say goodbye (Chan, 2012)

If we accept project risk as the central problem to be solved, we need a framework that addresses these risks.

4. Mitigating risk using Agile methodologies

“Agile development is a conceptual framework that promotes adaptive planning, incremental development, iterative software releases, and rapid responses to change.” (Mitroff Silvers & Hendee, 2012, 55–64) The tenets of the methodology are to deliver software early, keep solutions simple, test continuously, and adapt quickly. It suggests that we can control four variables—time, cost, quality, and scope—and that scope is the variable that provides us with the most valuable form of control. If we manage scope, we can manage costs, quality, and time as well.

According to Beck, the absolute truth of software development is that “the requirements are never clear at first. Customers can never tell you exactly what they want.” (Beck, 2000, 18) Furthermore, the development of a project changes its own requirements. As soon as stakeholders see the first release, they learn what they want in the second (or what they truly wanted to begin with).

In our own sector, Cooper Hewitt’s recent experience switching from Drupal to WordPress (Walter, 2014) highlights how institutional priorities reveal themselves over time. As the organization’s needs for a CMS evolved, they learned what they needed for the project as they were doing it. The flexibility to revisit decisions made early in a project leads to happier stakeholders and, ultimately, a better website.

How do we control the soft, malleable nature of scope? Agile suggests we fix the date, quality, and cost and let the scope be implied by these other variables. As we progress with the project, we keep date, quality, and cost fixed, always adjusting the scope to address new priorities as we encounter them. This style of development requires that we address the most important organizational objectives early, so that as priorities shift and we adjust our scope, all subsequent development is discretionary.

This conceptual framework is a scaleable solution for projects with varying sizes and institutional importance, ranging from comprehensive website redesigns to the development of new, program-specific publications.

5. Agile development of a museum microsite

It’s 2013, and the Museum of Contemporary Art Chicago is working with artist Goshka Macuga on a year-long residency project. The institution’s expectation is that this residency will engage museum visitors with the artist’s process throughout its duration. The project team is charged with bridging the gap between artist and audience.

Macuga is off site for most of the residency, visiting Chicago only at predetermined intervals. With no artist on site and, in the early phases, no objects being produced, the museum needs a physical manifestation or marker to let visitors know what’s happening. With its ability to present a depth of information in a physically economical and engaging way, digital media emerges as the best candidate. The museum and the artist agree to a title-wall installation that includes iPads, but what goes on the iPads remains to be determined. With no clear direction, no project scope, and no content, the development process needs to accommodate the utmost flexibility.

In her first visit to Chicago, Macuga and then-MCA curator Dieter Roelstraete meet for a research exploration of the city’s “lesser-known histories, forgotten folktales, and best-kept secrets.” (http://www2.mcachicago.org/macugamap/) The material they generate becomes the basis for our presentation. Our first iteration is a blog, with posts written by the artist and curator arranged in reverse chronological order. This design pattern has the advantage of being simple and quick to launch. But after the first release, we realize that users find the content unapproachable on the installation’s iPads. They don’t know where to jump in, and when they do, they don’t have the context they need to understand what they are reading, how it relates to them and to the museum, or what it’s all leading up to.

For our second iteration, we reorganize the content into an interactive map interface, since the artist’s notes are organized around places she visited in the city. This provides an instantly relevant format for on-site visitors: whether residents of Chicago or visitors to Chicago, all are likely able to relate to a map of the city. This also serves to emphasize the project’s connection and relevance to the local community, a goal of the museum’s residency program generally.

As the residency continues, we come to understand that Macuga’s work will find its form in phases: lateral research of canvassing Chicago; deep, vertical research at the Warburg Institute in London; production, likely to happen abroad; and a yet to-be-determined final presentation. With this new information, we again adjust our digital strategy, and we focus every new release to respond to the project’s most salient priorities.

The project’s core creative concept comes into view as the artist’s process reveals the characteristics of the work she’s creating. By adopting an Agile methodology, our team is able to respond to changing needs through the course of the project. The result is a compelling, revealing, and engaging presentation for museum visitors on site and online.

6. “Extreme” principles and “Agile” values

The fundamental principles of Beck’s “Extreme Programming” technique are rapid feedback, simplicity, incremental change, embracing change, and quality work. While some of the practices of XP are specially designed for application development or, like pair programming (a practice where two developers collaborate on code), are occasionally impractical for very small teams, the intentions and techniques can be easily adapted to an Agile methodology specific to museums:

• The planning game: Quickly determine the scope of the next release by combining project priorities and technical estimates. As reality overtakes the plan, update the plan.
• Small releases: Put a simple system into production quickly, then release new versions on a very short cycle.
• Simple design: The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered.
• Refactoring: Developers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility.
• Continuous integration: Integrate and build the system many times a day, every time a task is completed.
• On-site customer: Include a real, live user on the team, available full-time to answer questions.

These principles were further refined by a gathering of developers and codified in a document published as The Agile Manifesto. It articulates a set of values:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The postscript adds that “while there is value in the items on the right, we value the items on the left more.” (Beck et al., 2001)

7. Agile redesign of a museum website

It’s 2014, and the Clyfford Still Museum is coming up on its third birthday. The Museum has outgrown the website it has had since before the building went up, and the project team is planning a redesign. The requirements are understood as a new, more flexible CMS; a reconsidered and streamlined information architecture; and a new visual design, which will be mobile responsive.

We begin by replicating the site’s existing templates in a bespoke WordPress theme and migrating the existing content and information architecture. At the five-week mark, we switch over and begin running the “old site” on the new platform. With the new CMS in place, all the work to come will build upon this substantial and early achievement; the Museum will never have less than a new CMS, no matter what the future holds. We then begin work on the “new site.”

Echoing the experience at the Art Gallery of Ontario, implementing the new CMS and migrating the site content first is revelatory. We are always working with real, live content, enabling the content strategists and Web editors to test assumptions and make improvements along the way. The designers, too, are able to design for real content, as opposed to an idealized version. The developers, with the foundational back-end out of the way, focus on rapid prototyping of front-end ideas, enabling prompt feedback from the team.

Early plans are to ship incremental updates, iteratively evolving the “old site” to the new design. However, we quickly recognize that the gulf between the old design and the new will be too wide, and that updating the live site in such incremental way will be unacceptably disruptive to users’ experience. For the remainder of the project’s 16 weeks, we maintain content in two sites: a “production” site with the old design, and a “development” site with the new. The ability to make a decision of this scale mid-project is a feature of the Agile approach.

We perform user testing and make adjustments as we go, constantly returning to the Museum’s priorities and, at every phase, questioning whether we’re delivering on them. When we come down to that final push, we articulate our status in terms of the project’s fluid scope. This empowers stakeholders to weigh in on which of the remaining design concepts will contribute most to the successful launch.

8. Phase-based project scoping: A hybrid approach

In a “traditional” approach, the digital team works somewhat independently of other Museum stakeholders, on a system delivered by a final flip of a switch. Along the way are opportunities for feedback, testing, and review by the stakeholders, but everything is accumulated for this one all-important launch date. At the other end of the spectrum is the fully Agile methodology where iterations are short, consisting of single use-cases. For each cycle, the development team informally meets with on-site stakeholders to quickly draw up a back-of-a-napkin sketch. The functionality is coded, tested, and potentially deployed, and the cycle is repeated. (Ruby et al., 2010, 74–79)

Our experience has been that while the “traditional” approach positions stakeholders at too far a remove, the fully Agile approach isn’t always possible in a museum setting. We’ve developed a hybrid approach to website design and development that builds on the strengths of each. Characterized by a series of milestones, this approach favors flexibility and client feedback. Its phases are premised on a “journey” metaphor:

1. Where do we want to go?

This phase will emphasize research and discovery, while establishing the project’s bedrock foundation. The key activities are to create a sitemap, perform design research and hold the project kickoff meeting. Where applicable, this may also include deploying the target CMS and migrating any existing content into the system. In this case, staff CMS training and the production of any user manuals will also begin.

2. How do we want to get there?

This phase will emphasize exploration, while addressing architecture/navigation considerations and developing the project’s visual language. Key activities are design presentations and experimentation around core functionality and aspects of the user interface, culminating in a defined project scope and design direction.

3. Course corrections

This phase will emphasize testing and iteration, while ensuring the organization’s top needs have been addressed in a way that will be well received by the site’s visitors. This can include usability testing and a “beta” launch, followed by additional design iterations and code adjustments. It culminates in an executable plan for the final phase of the project.

4. The home stretch

In this phase, loose ends are tied up while performing final fit and finish. Key activities are to make final design/development adjustments and complete any documentation and staff training. The result is a smooth launch and a project shift to ongoing maintenance.

9. Organizational fit for Agile teams

Agile methodology may not be an appropriate fit for all scenarios. According to Philippe Kruchten, Agile is best of for non-safety-critical projects that have a defined, stable system architecture and are not subject to strict governance. It may be an uncomfortable fit for systems with a low rate of change or that involve multiple points of integration with legacy systems. Additionally, core Agile processes may run aground if there are few release opportunities or no stakeholders to interact with. (Kruchten, 2010)

Cennydd Bowles, writing at A List Apart (2008), says the approach works best when “designers, project managers, developers and business owners all have a good understanding of each others’ disciplines.” On the Clyfford Still Museum redesign, we found our team divided naturally into tasks based on our roles: Sarah, the content strategist, took on the information architecture; Martin, the developer, took on the migration and CMS configuration; and Scott Reinhard, the designer, focused on the visual and conceptual research and developing the new look and feel. But we had considerable skills overlap, which Bowles refers to as “literacy.”

For an Agile methodology to be effective, the team “must let go of perfection to produce rapid, iterative work: “90 percent right” solutions are par for the course for Agile. This can be counterintuitive, but for better or worse, Agile prioritizes the timeline over virtuosity.” (Bowles, 2008)

10. Build the car while driving it

The botched launch of Healthcare.gov in 2013 illustrated the worst-case scenario of a Web project failing to deliver on time. It brought software development methodologies into mainstream conversation, with a New York Times op-ed piece recommending the adoption of “modern, incremental software development practices, like a popular one called Agile.” (Johnson & Reed, 2013)

With their many stakeholders, diverse audiences, and limited resources, museums need a development methodology tailored specifically to their needs. Tackling the problem head-on at the Art Gallery of Ontario revealed that the inherent risks of digital projects can be mitigated using an Agile approach. Applying these principles and values to the development of a microsite for the MCA Chicago, we were able to address evolving requirements, respond to stakeholders’ priorities, and test our assumptions as the project developed. The redesign of the Clyfford Still Museum website revealed a “hybrid” approach of phase-based project scoping, which ensured organizational fit.

Through these projects, we learned to develop deliverables on multiple parallel tracks. We learned to be unafraid to revisit decisions made early in the process. We learned to keep our solutions simple, adaptable, and flexible. We learned to deliver on high-priority items as early as possible, and to continually readjust our scope. We learned that we must expect to adapt to conditions as we find them. Most important, we learned how to plan to be flexible.

References

Beck, Kent. (2000). Extreme Programming Explained: Embrace Change. Addison-Wesley Professional.

Beck, Kent, et al. (2001). “Manifesto for Agile Software Development.” Manifesto for Agile Software Development. Consulted January 31, 2015. Available http://agilemanifesto.org/

Bowles, Cennydd. (2008). “Getting Real About Agile Design.” A List Apart, December 2. Consulted January 31, 2015. Available http://alistapart.com/article/gettingrealaboutagiledesign

Chan, Seb. (2012). “Call for Submissions: Epic Fail at Museums & the Web 2012, San Diego.” Fresh & New(er), January 25. Consulted January 31, 2015. Available http://www.freshandnew.org/2012/01/call-submissions-epic-fail-museums-web-2012-san-diego/

Johnson, Clay, & Harper Reed. (2013). “Why the Government Never Gets Tech Right: Getting to the Bottom of HealthCare.gov’s Flop.” New York Times, October 24. Consulted January 31, 2015. Available http://www.nytimes.com/2013/10/25/opinion/getting-to-the-bottom-of-healthcaregovs-flop.html

Kruchten, Philippe. (2010). “Contextualizing Agile Software Development.” EuroSPI 2010: Proceedings. Grenoble, France, September 1–3, 2010. Consulted January 31, 2015. Available https://pkruchten.files.wordpress.com/2012/07/kruchten-2010-contextualizingagilityfinal.pdf

Mitroff Silvers, Dana, & David Hendee. (2012). “Agile Games for Productive Teams.” In N. Proctor and R. Cherry (eds.). Museums and the Web 2012: Selected Papers from an International Conference. Available http://www.museumsandtheweb.com/mw2012/papers/agile_games_for_productive_teams_0.html

Ruby, Sam, et al. (2010). “The Depot Application.” In S. Davidson Pfalzer (ed.). Agile Web Development with Rails 4. Texas/North Carolina: The Pragmatic Bookshelf.

Walter, Micah. (2014). “Downgrading your website (or why we are moving to WordPress).” Cooper Hewitt Labs, April 6. Consulted January 31, 2015. Available http://labs.cooperhewitt.org/2014/downgrading-your-website-or-why-we-are-moving-to-wordpress/