When the Business Demands Change: The Agile Method vs Agility

Are you a mega-planner? I am.

When I was 10 years old on vacation in the Badlands with my mom and brother, I demanded ‘The Daily Plan’ from my mom every day. I was compelled to run through the general events of the day, how long it would take to get there, how long we’d be there, trying to include all the highlights we (I) wanted to hit. I’d spend hours looking at maps and planning. My mom jokes about it now, but I know it drove her nuts when she just wanted to explore.

Not much has changed. I’m a big planner still and have a compulsion to always be on time. In business or at work, this can be an asset or a curse, depending on the day. Especially in our business of web development, design, and technology: things can change in a matter of minutes. During a new product launch, fighting a particularly pesky bug, or countering any number of crises, there is always the potential for bubbles to burst when you’re building something really complicated.

We can’t always plan specifically for these, but we can make a general plan for how we deal with them. Recently, two big hiccups happened — one internal and one external. Here’s how we coped.

External: When the most agile approach is waterfall

Background: We are working on a website build right now that’s going to launch in the next month or so. We have a specific budget and timeline, as usual, and we plan on a certain number of working hours per sprint. We’re speeding toward the end of this project, thinking all along that we have plenty of time to wrap the remaining bits up and launch on-budget.

Then a few things happened adding time bloat to the project, including: unanticipated time outside of the sprints spent on stylistic and content concerns, additional complexity within pages we had previously outlined, and the discovery of entirely unimagined technical constructs which needed to be built before other pieces could be integrated.

Our Agile process was rolling...team sprint planning, voting on complexity, keeping clients completely informed. All of that was adding to the time overage too, since Agile is so inclusive and requires a whole team sprint planning once every two weeks. A six-person meeting for two hours can eat time fast, though it saves you from a lot of communication issues later.

We couldn’t use up any more time for anything other than building. And we still have to launch the site, which is another chunk of time.

We figured: We know the site, our client is awesome, so let’s scrap the Agile Method and make decisions to get this thing done. The most agile approach to solving this problem was to simply build the rest of the site with the leanest team, fewest meetings possible, and limited feedback. We had to make the best decisions in the interest of time and budget. We were at a point with the the build where we couldn’t noodle every detail as a whole team and we had to trust the team to make decisions and simple execute to get the thing done. The most important thing we learned is that with every project, you need to assess, respond to the environment, adjust, and then execute. The agile process gave us this flexibility from the start, something that a waterfall approach might not have given us if we started there.

We’re launching soon, stay tuned.

Internal: When the competition beats you to launch

Because we don’t have enough going on, we’ve been steadily working on our own website relaunch. This has been ongoing for the good part of a year and seems to be at the very bottom of our priority list even though it’s one of the most important pieces of our marketing mix. Sounds familiar, right?

We made some serious progress last month in the design and user experience. And then we checked a competitor's recently redesigned site…and…it looked almost exactly like what we were building.

So we took a deep breath, had a beer or two for lunch, and got to thinking. Yes, we needed to start over, but why waste time figuring everything out again only to have that happen again?

We scrapped the site and focused on only the bits that made a real difference with the audience we are trying to reach. We trimmed everything else out of the scope of what we are trying to launch with. Here’s our revised priority list:

1. Nail down our brand and mission, get internal buy-in (more on this soon in our next L.A.B. post)
2. Focus on ONE piece of the site as a whole team and delegate
3. Forget about the competition
4. Launch the new site with the one essential bit, and add to it in order of priority

This is a truly agile approach, which I advocate for when you’re thinking about building something really complicated for a few reasons:

It’s a great marketing opportunity to write about what you are doing and why.

-and-

You won’t commit to more than you can realistically get done.

Utopia! Stay tuned for our new (extremely minimal) site soon.

hugs,

Emily