Making a case for using agile for automotive site development

The Landscape

Back in September 2008 Lehman Brothers collapsed. The resulting shockwave had immediate and damaging consequences across the financial markets and, ultimately, the entire economy. An already struggling automotive industry was pushed to the breaking point.

Why should we start a discussion on agile here? To survive, the decision makers in the automotive industry had to take a hard and honest look at the way they were doing business. They needed to adjust not only to ...

the rapidly changing financial situation but also to the increasing expectations of their customers, who were demanding more and more from their vehicles.

One opportunity that presented itself was to look at better ways to manage the approach to digital marketing, specifically website development. This article looks at one of the Detroit Three automaker’s adoption of an agile approach to website development.

So what challenges did the business have?

This Razorfish automotive client was dealing with the obvious chaos in the marketplace, huge fluctuations in gas prices and the rapidly changing expectations of automotive consumers. The following desires were also identified by the key business stakeholder as key to the company’s success in development of a significant consumer website:

A need to reduce costs across their infrastructure.

A need to find new opportunities to grow.

A need to promote new vehicle features and services within an ever-growing product range that had increasing integration with technology, such as vehicle diagnostics and navigation.

A need to provide ongoing education about those new and ever-more-complicated vehicle features.

A need to retain repeat site visitors.

A need to do it all NOW!

Why Agile?

Based on the macroeconomic environment and the more specific micro-level business desires listed above, our project team and the client quickly determined that a traditional waterfall approach was not going to work.

Traditional waterfall approaches to website design start by defining a large feature set, creating a workplan during the first weeks of an effort and then blindly driving toward that goal over periods lasting nine to 18 months.* Instead, agile aims to tackle work in short sprints, which typically last from one to four weeks, during which the most important work is always delivered upfront and the goals of the project are constantly reassessed throughout the project lifecycle. Realistically, it means that feature updates can be pushed to market within two months adding immediate value to the consumer and the business. More importantly, it means that the business can constantly react to changing environmental and business factors throughout the lifecycle of the project.

So how does it work?

Simply, agile can be defined by the following six steps:

Define → Prioritize → Establish acceptance criteria → Build → Review → Launch

Define: The complexities of the work at hand are broken down into manageable feature sets. Led by the User Experience team, the other disciplines of the project also contribute to this breakdown. In the case of our website, those features aligned with core functions of the site such as Global Navigation, Support Content and Managing Vehicle Service. Each one of those features are further broken down into user stories that provide the design team with flexibility to develop a solution without extremely specific restrictions. Stories conform to a simple structure, as follows: As a <type of user>, I want to <perform a task> so that I might <achieve a result>. Stories at this time are also scoped and sized to determine how much effort is required across the team to deliver the solution.

Prioritize: Once features and user stories have been defined, the business owners can prioritize them based on business needs. The business chooses what is worked on first. This prioritization activity is carefully balanced with determining how much work can be consumed during a sprint. Once a team’s work velocity is calculated, only the top-priority items — which must equal the amount of work that the team can consume within a sprint — is tackled. Ongoing prioritization throughout the sprint for items that are on the backlog is facilitated through a process called backlog grooming. This ensures that any subsequent sprint is always tackling the most urgent set of features.

Establish acceptance criteria: While the notion of defining requirements via open-ended stories may immediately make some leap to the conclusion that the client never gets to fully define what they need, the reality is that each user story being tackled in a sprint also has specific acceptance criteria. Acceptance criteria are defined before the sprint starts during a sprint-planning session, which allows the business to clearly articulate the expectations of how the solution should work without hampering the solution approach.

Build: Once the business chooses which features to work on, prioritizes the work and defines acceptance criteria, the sprint begins and the work really starts. The team members are challenged with performing a full set of activities from user experience development, design development, copy development and front-end code build within the constraints of the four- to six-week period. The sprint approach to tackling work ensures that the team stays focused on the specific defined features rather than focusing on the entire site.

Review: At the end of the sprint the feature set is reviewed with the client. The user stories and acceptance criteria are compared to the solution to determine if the project team members hit their goals. One of the truly great efficiencies of Agile comes to bear here. If the work is green-lighted by the business stakeholder, it can be readied for launch, which results in priority features getting placed in market very quickly. If the work didn’t hit the mark, the client didn’t lose months and months of time — they lost four to six weeks. The unapproved work can be placed on the backlog again and, more interestingly, it can be assessed again against the current business priorities. If the market conditions have changed since the project started, new work can be prioritized.

Launch: From a website-development perspective, once a feature is approved for launch, the launch cycle allows for any necessary last-minute adjustments and finalization of QA and launch sequencing. This is actually where the rubber hits the road and the feature is rolled to the live environment.

Working within the process

Agile and the notion of an Agile team was new to our team. We set up a “scrum” room and set out on an unknown adventure.

What at first felt like organized chaos quickly turned into a rhythm that the team became comfortable with. Unlike the traditional waterfall model, there is no formal Microsoft Project-style plan. Instead the project facilitator, or scrum master, manages the workflow and work tracking with low-tech solutions: Work is tracked on pin boards where tasks, associated owners and estimated times to complete those tasks are transparently shared with the entire team. Progress toward the sprint end is managed via a sprint burndown chart (see example at right). At any given point in the sprint, members of the team can know whether they are on track.

Communication is quick, transparent and efficient. Because everyone is in a single room, people can quickly engage in discussions taking place, should they feel the need to do so. Conference calls are held in the scrum room and everyone gets to listen in. This immediate exposure to information means email and ambiguity is minimized. Every day the team also huddles in a process called the “scrum” where they address three questions: 1) what did you work on yesterday; 2) what will you work on today; and 3) what stands in your way of being successful. The third question is important as inhibitors are owned by the scrum master and it’s his or her job to close them.

The workflow is dynamic. If an approach to reaching a solution is not working, the team can quickly try new methods. They are not constrained by rigid project-management processes or waterfall dependencies.

Drawbacks

OK, so it’s not all good. Managing expectations with the client can be hard as there are fewer progressive steps for approval -– there are no wireframes or copy decks; these deliverables get folded into a working prototype.

Keeping focused on a fixed-price contract and determining when you’ve fulfilled your obligations can be difficult as the priorities keep changing. You need an active and engaged key stakeholder for it to work. The constant pressure to deliver sprint after sprint can be tiring. Unlike a normal waterfall initiative where there are natural peaks and valleys for different teams, agile is all go, all of the time, for all teams.

In Retrospective

Our team is now one year into this journey. We’ve launched a large, complicated site within six months of starting the project and subsequently launched four significant updates. The client has been delighted with the results and the site has received critical acclaim from external industry experts.

Agile was right for our client. They were able to appropriate funding and start a project in the midst of unprecedented turmoil in the financial market. They could do this because they were able to start the project knowing that they had the flexibility to change course at any time. Agile enabled everyone to assess and re-assess the integration strategy throughout the lifecycle of the project, both at a sprint-by-sprint level and at a long-range level. To date we’ve had two significant reviews of our long-range strategy and have been able to make course changes as necessary.

Agile has also enabled us to iterate on features within the site. We launched designs that met client needs early and then enhanced them later. This allowed the business to deliver initial value to the market but still monitor and react to its function in later sprints. A key to success here is ensuring expectations regarding features and feature quality are clearly set with the client.

Agile enables the quicker integration of information onto a baseline site than waterfall. Take the increasing level of electronics on modern vehicles. Unlike more traditional engineering on vehicles, which has a long lead time, electronics has a much shorter lifecycle from conception to development. As such, consumers need education and support content much more rapidly. Agile supports an ability to build and integrate such content into production quickly and efficiently. Consumers get the information they need, when they need it.

Agile has also enabled us to deal with the complexities of separate workstreams outside of the project. This is especially important when the backend infrastructure you rely upon is constantly changing and growing. New features become available and with Agile you can prioritize integration with those features ensuring that the latest feature or service is available to the client and consumer.

In closing, agile has become an incredibly important approach to delivering websites to our automotive client. It enabled them to be nimble in a massively unpredictable market, to get the most important features to market early and to react throughout the lifecycle of the project.

*The Standish Group, a respected digital development analysis firm, found that roughly 65 percent of features designed in traditional waterfall projects never get used.

Related link:

Manifesto for Agile Software Development

Image credits:

From top to bottom: Conference call and presentation in the scrum room, located in Razorfish’s New York office; burndown chart; wireframe pinup session in the scrum room. All three images appear courtesy of the author. The agile development thumbnail image appears courtesy of Software Quality Engineering.

Hide