Top 10 Website Features #6: Building Your Agile Website

by Mark S. Burgess, Page Mountain LLC

When was the last time you went into your kitchen for a drink of water and the water glass went from empty to full instantaneously? Have you ever had a vegetable garden as depicted on the 60’s cartoon The Jetsons where you threw a seed into a pot and a second later ripe tomatoes appeared?

More importantly: are you holding off on publishing your website until all of the features you envisioned are functioning?

The series so far:

1. Backup at the same frequency as changes
2. Finding the Contact Us Button
3. A responsive “mobile” design
4. Website Logistics
5. A Clean Well Lighted Home Page
6. Building Your Agile Website

The natural world does very little instantaneously. Trees don’t go instantly from seeds to the “the spreading chestnut tree” of the Village Blacksmith poem (note even the attributive verb “spreading” imparts a change of state.) You don’t learn anything, become overweight, get dressed or dine all at once.

So why are you trying to publish your company website that way?

One of many phenomena grown with the Internet’s impact on business is that of managers finding themselves wedged into a software application development and publisher role. While some have practice as publishers with a history of organizing and printing marketing brochures, annual reports and training manuals, few have any training in software development and user interface design.

In one sense, that’s good: at least they haven’t developed the bad habit of writing a lengthy specification of what the brochure or report should look like before handing it off to the graphic artists, copywriters and printers to build. That was the old model for software development. I worked with one company – a market leader in their industry – who had, before engaging me, spent $750,000 and two years developing a specification resulting in a product their customers hated (and so didn’t use.)

I read two books in the early 90’s that changed my thinking on how to develop software: “Structured Rapid Prototyping” (1989) by John L. Connell and Linda Shafer and “Rapid Evolutionary Development”(1991) by Lowell Jay Arthur.

The idea itself germinated and grew into what is today called the “Agile Method” as put forth formally in The Agile Manifesto (2001) the first tenet of which is:

Our highest priority is to satisfy the customercthrough early and continuous delivery of valuable software.

That might sound like an odd orientation for programmers, but it should also turn a light on in your marketing brain that maybe how you publish and manage your website needs to change. After all, your site is a convergence of publishing and software. It is an software application in the sense that you are predicting how your customers will want or need to use it before they actually do. So, the less time you spend building before you get real world feedback, the better.

Here’s a dangerously abbreviated distillation of the Agile method for building your company website:

Step One: Read the previous 5 editions of this series (links above) to prepare for the discussion with your team members. Read up on Agile but don’t take too long the first time through, plan on repeating this step.

• Learn the steps
• How Teams Work
• Avoid Mistakes

Step Two: Collect your team. And I don’t mean identify just a website builder, graphic artists and copywriters inside or outside your company but all of the people who will be impacted by the site including, if possible, some customers. It’s handy to use the same principles salespeople do for Strategic Selling to identify key members:

Financial buyer – someone from the executive team that funds the project

Technical buyer – the regulatory faction of the company: accounting, quality control; purchasing

User buyer – customers, technical support, people tasked with updating the site; the PR and marketing people (who as brand managers might also be techncial buyers)

Coach – someone who can help identify the people in the company (and outside of it like critical vendors who might supply content)

Step Three: In a conversation – over email, in a conference room – preferably in person – talk with the team about what everyone thinks the site should do. Choose a few easy to execute and critical functions for the web site.

Step Four: Create those elements chosen in Step Three, build and publish them.

Step Five: Replay from Step Three …forever. As they say about good writers: they never finish a piece of writing, they just stop editing it.

The key concept is to grow your website organically.

Even if your customers expect that you will eventually have a complex shopping experience, start with something simple they want and make it easy to get at.

Even if you have a ton of relevant material and big ambitions for your site, start small with pieces that work…then add. To do that, you’ll need to use a web site architecture that remains flexible. For instance, hand coding HTML, CSS and Javascript to make things look exactly as you wish means changes will be much tougher to make. Choose an architecture that will evolve with the changing standards on the Internet and what should be a steadily evolving function list for the site.

For the the company I mentioned earlier that had spent so much time defining what they were going to build and then tried to deliver a final solution in its first release, we walked through my version of Agile development (though it wasn’t yet called that) and delivered a finished product that customers loved and paid for itself in its first year. I asked the developers in the room to start building something after our second meeting with The Team.

As with any method, critics grow over time. One such fellow is Andy Hunt who wrote The Failure of Agile and is actually one of the Founders of the Agile Manifesto. Here’s his closing point:

whatever we attempt here has to work for the whole system, not just the developers, not just the managers, not just the testers, not just the users, not just the sponsors. There is no ”us” versus ”them.” There is only us.

Recently, a product I used – to remain nameless – changed their system to remove my control of the timing of events it processed. Their solution caused backups to run during peak user hours. Instead of solving the problems they had with load on their end, they simply moved the load from their system out to their customers. Their “team” had left out a crucial element of an Agile system.

Agility is a critical feature of your website, the logistics you use to support it and the function it performs. You don’t need to bring your team of customer representatives from the retail store, the purchasing department liaison, the website engineers and the accounting staff on your team into the conference room and announce your new title is Scrum Master and that you’re all going to start playing planning poker in a sprint.

As Mr. Hunt explains in his blog post above, you also don’t want to shake everyone up with a hodgepodge of Agile methods and leave out the difficult ones. The good news is that you’re not the first person to implement these methods. The net is full of good articles and case studies for how to go about becoming agile. Once you adopt this frame of mind in how you approach creating your site, you can avail yourself of those resources to help you tune the process to your company.

The key: deliver your website quickly and often.