Agile Web Development That Works

Jun 23 2011 by Jason Mark | 51 Comments

Agile web development is not a specific process, action, or a daylong exercise. Agile is a mindset, an attitude with which a project is undertaken.

It means streamlining the project, taking away time-sucks, performing frequent sanity checks, and making sure that you’re not spending excessive time on things that don’t add value to the project.

It’s about spending quality time on actions that add value to the website and make it better, and taking away time and energy from parts of the process that cause headaches.

Your team will reach the same goals and milestones, but in half the time or less.

In this article, I’ll show you how the agile project management method can be applied to developing websites.

Traditional Web Development Process

Typical web development process circa 2000-2007.

Around the turn of the century, a bunch of us web geeks were working hard on figuring out how to design websites effectively. We started with the tools and processes used in print, video and radio, and modified them for the internet.

We embraced paper prototypes, wireframes, user personas and use-case planning, as well as information architecture planning with site maps and flow charts.

When Jesse James Garrett and Steve Krug came out with their usability/user-centered-design books, we heaved a sigh of relief, not because what they were saying was new, but because they articulated the subject in a way that even the most technology-phobic print designer could understand.

The Turning Point

We got an RFP recently from a college that is redesigning their website and wanted to hire us for design and planning. It’s a great school and it sounded like a great project, the likes of which we’ve done dozens of times before.

But when we sat down to write the proposal, we found ourselves scratching our heads about how to approach it.

After a while, we realized why. The RFP was looking for a web developer from 2005.

Wireframes, site maps, use-case scenarios and focus groups — the traditional web development process — have served us well for almost 10 years, and we developed effective websites using them, but in a high-paced industry like ours, speed and efficiency are very important.

Now we see that they were tools of the Wild West. They still have their places in the new world, but they’ve been reduced to a niche player, and are only used on the trickiest of web projects.

What’s Changed?

There have been three major changes in the past 5 years that have fundamentally altered how we design websites.

First, everyone uses the Internet. I mean everyone. Ten years when we met with marketing directors or CEOs, most of them had secretaries who printed out their email to be replied to. Now, every CEO has a Blackberry or iPhone.

Secondly, we have gained a better understanding of how people use sites. Five years ago, we had best guesses to start from, now we have best practices. For example, every user who goes to a college website knows to look for the link that says "Admissions", and likewise every college knows to have a link called "Admissions". It’s hard to imagine, but these were big questions 10 years ago that merited days of discussion and testing.

Third, and possibly most importantly, are the vast strides in content management systems (CMS) technologies over the past 5 years. Any reasonably talented usability consultant (a profession that also didn’t exist 10 years ago) can work with a developer to customize any number of inexpensive or freely available, open-sourced CMSs, so that even my grandparents can edit a website.

Now we’re at a point where the work that used to take up 80% of a web development project is unnecessary.

It’s time to put aside the processes that supported that work, and graduate to the next level.

Agile Web Development Process

Modern (agile) web development process.

In the process shown above, editors are interacting with content and navigation on day one. Navigation is fluid, and we’re getting in front of users faster and making 100 minor corrections to our course, instead of waiting a few weeks and making major adjustments.

Flexible Processes for a Flexible Web

Get your team off of email and hold the phone. Stop the endless back-and-forth, internal meetings, and rehashing of the same issues each week.

Get everyone in the office and lock them in (figuratively). Bring the decision makers, the content entry folks, and your IT specialists, and you have a recipe for success.

While every part of an agile web development process runs more smoothly with rapid iterations, it’s the reduction of time spent on overhead — scheduling, recapping, hunting someone down for feedback, mood swings, staff reorganizations, training, etc. — that really gives you your biggest time-savings. Instead of your key stakeholders having to attend 4 meetings over 5 months, they need to attend 3 hours of meetings over 3 days.

With agile development, your team will be immersed in building the website within a couple of weeks of starting the project, and you’ll be getting real-time feedback from real website users within a month.

Your internal team will be empowered to make these changes and will be trained in asking the key questions, which are:

  • Does this change help us reach our goals?
  • Do these images and words support our brand?
  • Is this solution better than what’s there now?
  • What’s the worst that could happen if we tried this for a week?
  • Once the week is done, how should we decide if we leave it or change it back?

Now is a very exciting time for technology, and this new method of web development is a tool that gets right to the heart of the matter, and avoids wasting time on the noise and minutia that slows us down.

A Case Study of Agile Web Development

We worked with Technical Career Institutes in Manhattan to re-launch their 100-page college website in 1 month.

They wanted a slick, modern, engaging design to reflect their brand. They want it to be easy to edit, and easy for them to maintain.

Within 2.5 months of signing a contract with us, their inquiries had increased by 100% — a wonderful outcome of the re-design. (We’re continuing to work with them to understand where they lose people in the application process, and will continue to improve these numbers.)

In three days, despite not having a clear brand statement, we took all the photos, designed the new website look, got sign-off (and excitement) from over a dozen key stakeholders, programmed the themes and tested them on all priority browsers, finalized navigation and created about half the pages on the website.

What follows is a breakdown of our 1-month timeline.

Week 1: Setup

Initial server setup by our team. We chose Drupal because it’s powerful and can be configured and customized to be very easy for end-users to use. Using the Acquia Drupal install, security updates become easy. (We have a standard module list that, if you ask about in the comments, I’ll discuss in another article.)

Week 2: Onsite Training

Over the course of this week, we worked with TCI to understand their brand, create the visual design of the website, take hundreds of photos, define the navigation, and train 15 TCI staff members on content management. This allowed them to completely rewrite 15 pages and migrate 25 more from the old site to the new site, set up multiple web forms and calendar integration, and connect all the hooks to their existing admissions systems.

Weeks 3-4: Cleanup and Go Live

We spent the last two weeks tidying up and preparing to go into production. TCI continued to add and tweak content while we refined the design and the code, cropped pictures for them, and helped them with navigation problems. We made the site more search-engine-friendly and generally kept things moving forward to deployment.

Post-Launch

Both our team and their team have made dozens of tweaks to the website after the site was launched. We continue to monitor website traffic to optimize the website for search engine traffic.

Conclusion

Using agile project management reduces traditional website development processes significantly. What could have taken 4-8 months under a traditional process, we reduced to 1 month. Cutting down the build process to its bare essentials reduces bottlenecks and project overhead, making it as efficient and results-driven as possible.

Related Content

About the Author

Jason Mark is an educator, business owner, and author. His Massachusetts-based firm, Gravity Switch, continues to be the leader in web, iPhone and iPad development in New England, and Jason keeps their carbon footprint down by bicycling to work year round. Follow him on Twitter @jasonnmark.

51 Comments

Scott Block

June 23rd, 2011

I’m definitely interested in hearing about the Drupal modules you use!

Dave Sabol

June 23rd, 2011

Jason,

I applaud the effort and the results, but what you describe here doesn’t really jive with what I have learned and practice with Agile Project Management (we use Scrum), I see know mention to the product backlog, nor to the daily scrum or sprints. Granted Agile is pretty flexible so you could be using a version of XP, Lean, DSDM, or FDD that I’m a little less familiar with, but regardless what I’m not seeing are the hallmarks of agility – iterations, focus on increased communication, motivated people, etc.

I’m really glad the process worked for you and even happier that you took the time to write about it, however, I think you’re title is a bit misleading and does the practice or true agile project management a bit of a disservice, and could set others up for confusion and/or failure.

Jason Gross

June 23rd, 2011

Great article Jason.

It’s not a mind blowing venture to suggest that our projects should be executed in a more efficient manner now than they were 5 or even 2 years ago. However, the value in this article is the transparency in how you have changed your process and a real world example of how it worked for you.

I am sure some designers have not yet had the opportunity to work with large scale, content rich projects so I think it is worth pointing out that the idea of getting a college website from approval to launch in about a month is a significant accomplishment. Too many of us have had the great opportunity to learn this the hard way with clients who fear a go live date and constantly push deadlines back because they have this idea that everything must be perfect and after site launch their content is set in stone.

This article provides a great insight into managing projects in a way that better reflects the agile nature of the web.

Ryan

June 23rd, 2011

Module list would be interesting. Comparing notes and whatnot :)

jason mark

June 23rd, 2011

Dave,

Thanks for bringing up this point, and I think you’ve touched on one of the key points I hoped to convey to people, which is that “Agile” is MORE than just Scrum (which people love or hate). The Manifesto for Agile Software Development says:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

and it has 12 underlying principles:
1) Customer satisfaction by rapid delivery of useful software
2) Welcome changing requirements, even late in development
3) Working software is delivered frequently (weeks rather than months)
4) Working software is the principal measure of progress
5) Sustainable development, able to maintain a constant pace
6) Close, daily co-operation between business people and developers
7) Face-to-face conversation is the best form of communication (co-location)
8) Projects are built around motivated individuals, who should be trusted
9) Continuous attention to technical excellence and good design
10) Simplicity
11) Self-organizing teams
12) Regular adaptation to changing circumstances

In this context the tools you describe (scrum, etc.) are very useful, but are just tools that must always be evolving and changing, and will at some point be replaced but it’s own process.

One'

June 23rd, 2011

This post it’s about “development” or just using a software? I have a feeling that the old approach of developing something was replaced with just using & configuring + design an original theme. Of course times were reduced by using Drupal with some modules, but what about using agile to custom develop something original? Apples and oranges…

Micah

June 23rd, 2011

Thanks for the article.

I’d love to hear your standard module list.

Jason Hanley

June 23rd, 2011

Agile is definitely the way to go, but a lot of people have trouble understanding what it really means.

I’d be interested to know what type of communication and project management software/tools you use to track client features, changes, etc.

Young

June 23rd, 2011

This was a very interesting article. Being a part of a pretty small team, I think most of the time we still approach in the traditional mindset when developing new – especially small – sites. I would like to hear more about exactly how the diagram above applies, things like how you can tackle all those overlapping tasks at the same time and how big a team would need to be to execute it properly. Perhaps a compare/contrast of the same project, assuming it was engaged in the two approaches, would help me grasp it better. Either way, thanks for the insight.

Charlie

June 23rd, 2011

Yeah, modules list would be cool.

Wonder what your agreement is with the college as far as post-launch. How long will you be tidying things up and doing SEO for? I guess these are the things that Drupal isn’t well equipped for yet? Or is there a gap in skills of the client for these things? Just curious.

Pretty impressive on what was accomplished in just the first 3 days.

Art Williams

June 23rd, 2011

Awesome article! I’m going to pass this one around the office here. I’d also be interested in your list of modules.

Thanks,
Art

Tony

June 23rd, 2011

Granted you did it in a month and great, what about the user experience though? How do you know what your building is really going to work? You can put lipstick on a pig… More and more companies, government agencies, start-ups, VC’s and others are seeing the value in really discovering who their users are nd what they really need. Then building the UX around that. Unless I missed it I didn’t see where you did that? How could you have done all of that in a month? I’m not trying to bash, just understand how you could say to your client that the new site is better, more usable etc. Then just re-skinning it?

S. Sahrp

June 23rd, 2011

“In three days, despite not having a clear brand statement, we took all the photos, designed the new website look, got sign-off (and excitement) from over a dozen key stakeholders, programmed the themes ”

- WOW – impressive (honestly)- how big is your team? Just curious – I don’t think we will ever be able to accomplish that, agile or not ;(

I agree with Young’s suggestion above, maybe if you could compare the old/new approach on the same project…

Great article!

Jake

June 23rd, 2011

I have to agree with Dave’s comment. Although what you describe in your follow up comment is Agile, there is nothing in the post that actually talks about how you used an Agile process – regardless of the flavor of Agile – to help with the development of the website.

In fact, reading through your description of the project, it sounds like all you did was install a stock Drupal installation, and shift the content across Drupal. If you could tell us more about your development process, it would be a lot more useful.

Sorry for the negative comment, I was just hoping for more about Agile.

Pascal Larocque

June 23rd, 2011

I’ve been looking for a concrete example of applying Agile in an Agency setting and this articles gives some very interesting insight into the development.

We are currently trying to switch to agile in our agency but we keep running into issues when it come to RFP and contract negotiation. Seems that before we can change our mindset we must first change our clients mindset.

I’m wondering how did you convince your client to try an agile approach instead of the usual waterfall process.

Macel Legaspi

June 23rd, 2011

We’re big fans of agile too and have worked on several sites applying agile best practices. I also dig Drupal, which is I’d say becoming a lot more powerful these days, thanks to the community that supports it.

Glad to see success stories such as yours!

Dave Sabol

June 23rd, 2011

Jason,

Your points are well taken and I have to agree with you 100%! However, what you present in your post and your comments and reality seem to differ a bit! You eschew documentation in your post, but in your comment and in the Manifesto, documentation is key. In the same vein, the Manifesto clearly states that Agile does not skip over key areas (for web I’d say it is UX design – e.g. IA, Frames, and UxD) and your post suggests that they aren’t important (e.g. your suggestion of Mr. Krug). I’m pretty familiar with Drupal and Acquia and I can’t imagine launching a fully featured Drupal site – especially in the referenced use-case – without a lot of additional user feedback and a ton more planning, coding and configuration! Regardless, I applaud your effort, and I guess we’ll have to agree to disagree about the proper implementation of agile – at least per your post – because too many of the key artifacts are missing. Agile is a great approach to managing projects, but it’s definitely not the WIld-West. There are still constraints, best-practices, and limitations regardless of the flavor you use.

Again, my thanks for the post and best of success with your next initiatives!

ricelin(undirect)

June 24th, 2011

So thanks for such sharing!cool!

Jan

June 24th, 2011

Thanks for the article. But I think I don’t get the point. So you designed the new website with all pages *and* got the approval in one week? The client approval and amendments of the design alone takes several weeks in most of our projects …?!
And another week to program the complete individualized CMS fields, templates, JavaScript, and so on? How many developers did you have working simultaneous on this, if I may ask?

Avangelist

June 24th, 2011

Very insightful read particularly to how your time boxes work.

For me, I believe that incorporating agile systems into projects where there is a site of this type, what I would call a marketing site is very simple. It is built around content and possible just a few goals –

* Allow prospective students find information on courses
* Convert that interest into a new student enrolment

Just as an example.

But for those of us who build applications based in a web browser it seems the agile concept doesn’t work as well and I don’t know why.

It would be really interesting to see follow ups on this article in the future covering specific areas such as how to break up tasks for development in week 2-4 following your example.

In SCRUM you’re supposed to take a user story such as “I would like to add a new product to my online shop” and break it into tasks.

Where I have found things go wrong is that this user story is so wide that all the tasks required to do it mean that there is excessive planning, mockups and func/tech specs getting written in week 1 and suddenly you’re using an XP method but in a short timescale.

philipcaplan

June 24th, 2011

Jason. What I worry about is the “Elephant In The Room” of Versioning.

By this I mean, the users and owners of a system such as the one you describe think it’s wonderful, and by using it come to love it!

Then for perfectly good reasons, some changes are made and some of those users find it breaks the system for their usage! Yesterday they relied on the system, today what they used to do is no longer possible, or gives results that are no longer what they need!

Not all the users, or the outcry could make the “owners” roll back to a previous version to fix the “bug” or unhappiness. But what if some users **love** the update, and others find themselves **locked out** by it?

So, in 2011, the “Team” (Programmers/Designers/Owners) successfully create a Platform on which the Content is created and gradually shaped by the Owners.

But how, in 2012 will we allow the site/platform to evolve in Function and Usability to keep up with its Success? Does every End-user have to get every change on the same day? What about testing?

To me, this is the next Stumbling Block on the road to replacing PC-based systems (which relied on training before they could be used) with “Don’t Make Me Think!” usability where no training is the preferred mode.

BTW I’m not a coder or designer, but a “customer” of both hoping to get created a system which encourages worldwide end-users to achieve things that weren’t possible 2, 5 or 10 years ago.

So I’m very concerned with “how do keep improving/extending the system without breaking it” when experience tells me that Customers have a wonderful way of using systems for purposes the creators never thought of!

Pushpinder Bagga

June 24th, 2011

Could you please tell more about Acquia Drupal and how you think its implementation helps in real world scenarios?

Benjamin T. Watson

June 24th, 2011

Lets be real, Agile is a developers excuse for making things up as they go. Add design or testing in the mix to that and you have a project team that gets frustrated, stressed and really has no over all direction to head toward.

I have been on several “Agile” projects and the method has never been successful once. Every time people have reverted back to a waterfall method halfway through the project. Some may say well you were doing it wrong then… I give you this illustration then, How effective is it when the horse, cart and driver are all going down the street side by side. That is a clear illustration of what Agile is.

Mark Simchock

June 24th, 2011

Thanks Jason. Good stuff.

Actually, I think agile is a process, and an endless and micro-iterative one at that. I enjoyed your article but if I had one wish I would wish that you explored in more depth how the end tools (i.e., CSS, CMS, Analytics, etc.) have enabled – if not necessitated – a more agile approach. For me the key is to grasp 80% of the biz needs and going forward vision. The remaining 20% are forever part of what should be the ongoing evolution of an internet based property. And of course there’s also the issue of the market forever morphing.

The other key for me is first starting with The Why. Once The Why is understood (at an 80% or more level of confidence) then move on to The What. It seems that many of the pre-agile tools was overly focused on The What, and too often that was too debatable (i.e., stakeholders, meeting, time suck, etc.). Shifting the emphasis to The Why not only leads to swifter agreement but then there is also proper context for The What.

The unfortunate part of asking why is that you are greeted with an above average number of glossy-eyed stares. When “I want the site to…” is met with “Why?” wants are finally replaced with needs. That’s a critical and major difference. There a plenty of sites where the wants were met and the business needs missed.

SMH

June 24th, 2011

I like it. But I assume this works for large budget projects and all design And programming is completed in house. Makes sense for universoty projects or magazine projects. Also, can you work on multiple projects at once with agile?

I can’t see myself implementing agile for a $5k project. Also, how many clients want to be involved in a Daily process?

jason mark

June 24th, 2011

Thanks for all the feedback about standard Drupal Modules, I’ll be sure to make a post about that in the next couple of months, and I’ll see if I can slip something in there about the advantages we see in using Acquia Drupal…

jason mark

June 24th, 2011

Benjamin, I think you’ve hit the nail on the head with the fact that most people perceive agile as an excuse for making things up as they go. In reality Agile REQUIRES considerably more project management and planning than traditional projects, it’s just put in different places. Take the example of Habitat for Humanity who built 1,000 houses in a week: http://www.habitat.org/newsroom/2006archive/06_05_2006_HBB_National_Rls.aspx

If you ask most builders to try to build a house in a week, they’re going to come up with a mess, but if you approach it right it’s not only possible, but can be VERY VERY effective.

jason mark

June 24th, 2011

One’ –

You said:

Of course times were reduced by using Drupal with some modules, but what about using agile to custom develop something original? Apples and oranges…

We just did our first blitz-build with a client where we were building some pretty nifty functionality. In the past we’ve ONLY done agile web development when the features of a site are 99% “out of the box” with a standard CMS.

We were pretty impressed with the fact that we were able to prototyp, test, and refine 2 *fairly* tricky types of functionality for a client in just 2 days as part of a larger blitz-build.

We also have used this method internally for some pretty cool cutting edge technology we’ve had.

In those cases there is always “cleanup” time afterwards (usually about 20-30% of the total budget) to deal with things like IE6, or fringe use cases or data import, or whatever.

jason mark

June 24th, 2011

Jason H, Young, Charlie, S. Sahrp, Pascal, Jan,

We’re a 10-12 person shop (some part timers in there). TCI had about 6 people on it for 3 days, plus a freelance photographer we love and then probably about 15 hours of time that other people “Chipped in”

We have in proprietary Issue Tracking system we’ve developed and everyone on the team is well trained in creating tickets (numbered steps, clear expect, etc.). We also assign someone to scrub the bugs/issues every hour or two and make sure the right tasks are assigned to the right people, and nothing is languishing. We also run through the list with the client once a day or so and make sure they agree with our priorities.

One great thing is because these projects are based on TIME “feature changes” become less confrontational and less labor intensive. Instead of asking a client for a scope change, we record it, spend an hour on it, and then check in with the client to make sure they agree it’s a priority based on a quick back-of envelope calculation. The client sees that some things take longer than expected, and some take less, but THEY’RE in control of what gets done each day.

We’ve used this same process with smaller sites and smaller teams. Here’s an example of a 2-day Blitz Build. We had a Project Manager/Designer there for a day and a half, and a Programmer who started half-way through the first day and went to the end of the second day. We also had a QA person (tester) spend a couple of hours. The client came to us with photos, and in 2 days we designed the site, built the site, trained the client on the CMS, processed images for them and helped them build about half the site:
http://www.maninmazeworks.com/

It was hard work, and we had experienced people on it, but team size wasn’t an issue. We had some Internet Explorer cleanup to do afterwards, and had to help him with some lingering images, but it worked great…

In terms of changing our clients mindset to agile what we’ve found is it’s a lot of work to force water uphill. We still do traditional projects, but when we first meet with a client we ask them which approach is more exciting to them. They self-identify. I’d say 80% of the people we suggest agile to LOVE the idea.

Jan, design, approval, Navigation sign-off, CMS field, Templates, Javascript, ALL in 1 week (mostly in 3 days actually). After that it was 90% content, and some Internet Explorer cleanup.

jason mark

June 24th, 2011

Tony and Dave,

Thanks for bringing up the usability side of things. First off I want to say the proof is in the pudding. It’s 2 months since the redesign and they’re getting double the number of applicants that they were getting before the redesign.

We did also review their analytics before the blitz to make sure we weren’t doing anything stupid.

My metric for going live is when the minute we *think* the site is better than the old site… then we measure, measure, measure. We monitor it quite a bit the first few weeks, then shift to more of a monthly measuring, and constantly improve it.

We would be silly to think that we could make a site that’s as good as it can be in a month, but if we can build a site that’s BETTER than the old site in a month, monitor it and improve it every month after that, we’ll have a MUCH MUCH better time tested website in 6 months than if we spent 4 months planning…

jason mark

June 24th, 2011

Avangelist,

Good thoughts. I’ll think on this some and see what I can come up with.

I’ll be honest here, I’ve not had great luck with SCRUM. I find it overbuilt and underbuilt at the same time. I know the guys over at http://Atalasoft.com use it with GREAT results, but they make a very different product than us. We’ve also had much poorer results doing agile development in Expression Engine. The more custom code you need, the less agile you *can* be, and the more testing you have to have around it.

Also, as I’m reading your comment (and other people’s) I’m seeing people saying “great concept, thanks for the case study but how could *I* do this”. I’m actually teaching a class in VT this summer and I’m contemplating bringing an ACTUAL client into the room and redesigning and building their website in 4 hours and allowing the students to watch. I might fall on my face, but I’m sort of excited about the idea…

jason mark

June 24th, 2011

PS: I’m trying to answer everyone’s questions here, but if I miss any pls ping me on twitter @jasonNMark and I’ll follow up…

1001webs

June 24th, 2011

Very intrigued about that standard Drupal module list that,

Thanks in advance

Dave Sabol

June 24th, 2011

@Jake thanks for the kind words.

@Benjamin, I think what you are describing is more a failure of execution than failure of methodology. I’ve led and seen Agile projects that have gone flawlessly – for the record I’ve seen waterfall work well too – but all too often the methodology is held to blame when in fact it’s due to poor management of the process. I think what you described is the driver being asleep at the wheel…plus with pure agile you get an engaged team who all “own” their work packages/deliverables so even if the cart and horse were side-by-side, someone would own it.

That being said, your example is weak, and clinging to a preference rather than an exemplar, at best!

Sam Barnes

June 26th, 2011

Jason, despite not agreeing with the pragmatic side of your post, I think this is one of the best ones I’ve read that at least tries to give the version of “Agile” you talk about some weight by describing a real-world scenario.

But I’m honestly quite stunned at the process and timeline you describe and do wonder how many projects like this you have conducted with such speed and results, and like everyone else, how big your team is?

While I’ve no doubts this project went well for you using the approach described, I cannot think back to a single client or project where this would have worked for me or any company I worked at.

As other commenters have stated, this would require a change to almost all client mindsets and organisational structures, a team where all members were top notch and had schedules cleared to work on one project only – just not realistic I’m afraid.

I can’t help feeling that this project was an edge case where everything just went fantastically well and it was as much to do with a competent client, great relationships and urgency as it was your “Agile” approach.

That brings me onto the use of the word Agile… now I’m not going to get all semantic with you about what Agile is and isn’t, but what your post does do is highlight an issue and attitude that causes issues for many agency management teams out there…

…and that’s that after reading a post like this, some will understand, whereas other more naive people will believe this is how all projects should, and can be, run – they’ll then start believing their current agency methods are inefficient and filled with unnecessary “overhead” as you call it – and then they do it, they utter the words “we should go Agile”

Unfortunately what they mean is “I’ve read how Agile means less talking, less planning, more getting on with the fun stuff, more chance to experiment and I know some cool companies like 37signals are using it so we should.”

Very few actually understand the bigger picture of why projects are run the way they are, nor that very few are run as Waterfall… having worked at a few agencies and worked with many others, the most common fit seems to be a mixture of Waterfall and “Agile” – some kind of hybrid that seems to fit both client and agency.

Of course this isn’t to say Agile, or even your version don’t have its place – nor am I saying that there are some kind of clients that will respond to this approach and be complimentary and competent enough to make it a success – your project proves there are – but what I’m saying is that this is VERY rare indeed!! VERY rare!!

In my experience the approach you describe works well when you’re constantly developing one platform / tool / product, but when it’s a kind of a one-off website or even web app with a typical client / supplier relationship – for so many reasons your approach falls down immediately.

But I’m genuinely fascinated… and contrary to popular belief, open-minded.

So some initial questions…

1) Is this how you run all of your projects?
2) How many in your team?
3) During this project were the team on this one project alone?

Lyndon Williams

June 26th, 2011

Excellent article imho. Thank you very much.

@mightiermouse

Avangelist

June 27th, 2011

@Jason

The idea of having a client in your lesson is really interesting. I was trying to not make my question directed but you saw through my guise :-)

Yes I think that there are 2 things that always go wrong with agile methods.

1 – The app is in existence and you’re building new features, you’re on sprint 500001 instead of resetting the sprint blocks for each new task.
2 – because you’re building features the objective is to always move onto the next one and so you lose the iterative asset to agile.

It’s been real interesting to see the responses on here I would say that there is a HUGE elephant in the room.

Agile has to be company wide not just the development team. It needs be encompass everything that is going on starting with the project manager and client liason through the development teams and to the marketing / sales teams.

If it is only applied for a single department it falls over because you have a team that are churning out work like a sewer overflow and suddenly they hit tiny pipes at either end.

jason mark

June 27th, 2011

@Avangelist – My hope in writing this article is to start to get the rest of the team onboard (not just the 3 geeks who want to “go Agile”). If marketing isn’t onboard Agile WILL FAIL.

jason mark

June 27th, 2011

@Sam Barnes

RE: Client mentality. I would NEVER force Agile on a client. We outline both methods and ask them to self identify. We also used the same approach internally. When we started about half our team (esp. the designers) were VERY Resistant, so we started with a low profile project with a team who was the most intrigued about it. Then we brought people in. One of my most talented designers (someone who’s won some VERY competitive national design awards) resisted it very strongly, so we brought her in as the “backup” designer for TCI, and the client LOVED her work and went with it, great ego booster, and a great way to help her understand it.

RE: “less planning”
I usually tell people that Agile Development tends to have the same amount of planning and design, the big difference is we have less “abstract” planning and design and more “hands on” planning and design. We also have more interaction between clients, users and designers earlier in the process so that we end up spending our time in a more focused way and focus more on the tricky things. Where a traditional process we might spend 80% of our planning time on the easy things and making sure that the “web experts” and “marketing team” and “IT team” are all talking about the same things. In agile that becomes 10% of the time because we end up working on real world processes. I’m also careful to tell people that you should never implement agile to save money. While in some cases you can save money because you’re cutting out waste, the real win is how much more engaged and how much deeper you can dig in 6 months this way.

RE: Semantics
For a while we called it “lean” internally, based on Kaizen and lean manufacturing. We started by looking at our processes and figuring out where we waste time. We found a lot of areas where we had long discussions with clients about things that just don’t seem like issues to us (navigation nuances, etc). These are important things, but they’re also easily tested, and we found the same topics keep coming back to us, and we tried doing a “Blitz Build” as we call it as a way to get rid of waste.

> 1) Is this how you run all of your projects?
I wish. It’s about 50/50 right now. But I can tell you the projects that get delayed for months, and we have to spend the most PM time watching scope and such are the non-blitz projects. Also, Blitz really isn’t right for everyone.

> 2) How many in your team?
10 ppl, plus some subs as-needed.

> 3) During this project were the team on this one project alone?
For the 3 days of the blitz we had 6 people (plus a freelance photographer) on this project. 3 were onsite with the client in NYC, and 3 were back at our office. We also had 2 extra designer for half a day, and a “project wrangler” back the office who had the power to adjust resources if anything went wrong and we needed to throw more manpower at this (we didn’t, but we had backup in place). The wrangler back at the office also made sure the people onsite were fed and watered and got what they needed. This left us 3 people in the office to work on other projects and handle the day-to-day and to brainstorm tricky problems (there was one where Chrome was choking on the WYSIWYG we were using (CKEditor I think), and it was causing some issues.

matthijs

June 28th, 2011

Just a small note. I see ‘Content Creation’ late in your schemes. However, if you do not have/create/design your content at the beginning of a project, you can design and build all you want but it’ll be a bit of a long shot regarding the wishes of the audience and you’ll find yourself ‘shaping’ (usually cramming) content in some fancy developed website. First think of WHAT the visitor really likes to see/hear/read/learn/do, then think of HOW you will present what the visitor is coming for.

jason mark

June 28th, 2011

@matthijs – Opps.. the content creation label is supposed to be with the light orange bubble that starts on day 1 with a blitz build, not on the dark orange of maintenance. :)

I’ll see about getting a replacement graphic to Jacob tomorrow before I split for the 4th.

Ian Loew, Lform

June 30th, 2011

These steps seem quite simple to employ for larger web firms but what about agencies that have 10 employees or less?

Ian Loew, Lform

June 30th, 2011

Let me revise that last comment…. These steps seem quite simple to employ for larger web firms but what about agencies that have 5 employees or less?

Mike Hoefer

July 5th, 2011

Love this
“My metric for going live is when the minute we *think* the site is better than the old site… ”
It seems much of the time on a web project is spent waiting for someone else to do something. Your get everybody in the room and get it done approach is a good one.

Danielle Goldaper

July 6th, 2011

Jason,
I can’t agree more with the agility that the blitz build offers and with the empowerment that an entire organization must feel after completing this process.

The “buy in” of a few key decision makers to attempt this process, stands to promote such outragious benefits inside the organizations. Think about the pride that is claimed by the number of people who learn to do somethat that seemed mysterious only days before the approach goes into play. Think about the long term benefit of that pride of the “new contributors”.

This method promotes an ownership and an excitement that is key to maintaining the fluid nature of web content management. It gets me excited to think of the immediate impact and longstnading value that this process could bring to an organization of any size.

Very Impressive!

Stephen James

July 14th, 2011

Most of our project deadlines are set by the client based on an event. They need A,B and C by this date. Something like “We need this website completed by our board meeting in 2 months” is often heard, therefore iterative creation isn’t much of an option.

Mark Madison

July 27th, 2011

Jason,

You’re always the teacher and thanks for a great post. I work on smaller scale projects but I think the principles you describe here are relevant to my work in many ways. Also enjoyed the conversations that followed. It was fun to have an insight into how a a modern day web design company works.

jason mark

August 3rd, 2011

Ian, sorry about the late response. RE: a firm with 5 people or less… Keep in mind we’re a 10 person shop! I think my question for you is “do you have all the pieces you need to deliver a successful web project”. If so all you have to do is get them all in a room together.

Let me also mention that Gravity Switch is all about process and process improvement. 10 years ago we applied for an award that recognizes well thought out, followed and documented processes. With only 20 hours of work we applied and won the award, and we were competing against much larger companies who had spent a year working on this award.

All of these processes have served us well in a blitz build. We plan things VERY carefully. We have our our install of Drupal and WordPress with standard modules/plug-ins that make it easier for our clients out of the gate. We hack our own modules when needed.

Here’s how we started. I had a room full of programmers who didn’t think it was possible, but who each had 10+ years of web experience. So I found a client and gave them an AWESOME rate. Very cheep. I told them that we’re doing something experimental, and what we need from them is to be 100% committed to sit around any answer any questions we have.

At the end of 2 days one of 3 things would happen:
1) They’d have a site and could go live.
2) They’d have a great start of a site, and they could pay us more to make any changes they want.
3) We’d refund their money and thank them for their time and they could forget this ever happened.

Despite I had only two people on the project (one a designer/HTML person, and the other a PHP person) we were able to get up their site with some advanced functionality we’ve never done in Drupal before in the couple of days.

They happily paid us and went live with the site.

It was a friend of mine, so it was very “safe” if it didn’t work out, and the worst I would have lost is 2 days of time. I purposely stayed out of it because I *knew* that my team could do it without me. I set them the goals and they did it.

Remember also the people I put on this were skeptical that they could do it…

Tina DuBosque

September 30th, 2011

Jason, we have been using modified (by me) Goto procedures to get web work done for our clients. Saw that you are presenting at NEAUG next month and clicked through to read your agile development piece. Once again, you have expanded my mindset and provided new tools to get stuff done faster with no loss of quality or temper! Thanks to you!

Richard

October 7th, 2011

Well written article that I enjoyed thoroughly. Thanks for sharing :)

Martin

June 22nd, 2013

‘…every college knows to have a link called “Admissions”‘

This paragraph discredited the whole article for me, I’m afarid. I worked for a very old college that gets thousands of tourists a year who just want to see the building. When we did card sorting we found that most people outside the college thought ‘Admissions’ meant opening times and how to get in to see the old buildings. I hadn’t seen that coming at all! We had to change the labels to ‘Study at [college name]‘ for academic admissions information and ‘Visit [college name]‘ for tourist admissions. This got good feedback from both prospective students and tourists and was more dynamic (contained verbs/calls to actions).

There’s some truth to the old management cliche ‘Never assume, always ascertain.’

Leave a Comment

Subscribe to the comments on this article.