2013-06-26

Illustrated: How Agile Project Management Can Work For You

In 2011, I was writing about agile to convince software developers to adopt it. But as more and more businesses integrate software development into their core competencies, it’s time to re-explain how agile can help all sorts of projects—not just software.



A couple of years ago I wrote about agile web development that works. But to the mainstream business community, agile was still a fairly obscure subject. Now that it’s proven itself, I figured it was time to talk about why agile projects produce better results—and how almost any team in any industry can make use of some part of the process. First, some definitions. Then I’ll show you how agile works with some visual aids.

Agile Web Development:

  • not specific process,
  • not an action, and
  • not a daylong exercise.

Agile is:

  • a mindset,
  • an attitude, and
  • an approach to getting projects done.

Agile Development includes:

  • streamlining the project workflow,
  • eliminating time-sucks, and
  • pausing for frequent sanity checks.

Agile Behavior means:

  • avoiding distraction where there's no benefit for the project,
  • assuring focus for actions that add value and obviously make the website better, and
  • eliminating processes and bottlenecks that cause headaches, frustration, and even anger.

Agile Project Management:

  • facilitates changing requirements and specs,
  • allows development teams to achieve higher-quality results, and
  • helps developers reach their goals and milestones in a fraction of the time.

And I'm now going to show you how it's done!

Typical Development Process, Circa 2000

Before the turn of the millennium, it was up to us web geeks to identify some effective ways to design websites. We started with the tools and processes used in print, video, and radio, which many of us already knew, and modified them for the Internet.

We embraced paper prototypes, wireframes, user personae, and use-case planning, to which we added information architecture, planning with site maps, and navigational flow charts. It was the beginnings of a methodology. Below, a typical web development process circa 2000-2007.

In 2000, Steve Krug published Don't Make Me Think: A Common Sense Approach to Web Usability, and Jesse James Garrett published an influential diagram that inspired his book, The Elements of User Experience: User-Centered Design for the Web, published in 2002. These two managed to articulate the subject in a way that even the most technology-phobic print designer could understand.

This Isn't the Web You Knew in College

A couple of years ago, we got an RFP from a college asking us to plan and design a new site for them. Great school, great project, and we do this sort of thing frequently. We sat down to write the proposal, but felt oddly stuck; we couldn't figure out how to approach it.

Then it hit us—the spec was like something out of a time machine. They were looking for a web developer from 2005! Wireframes, site maps, use-case scenarios, and focus groups—the traditional process we'd said goodbye to about the same time Jesse James Garrett (the same guy) coined the term Ajax and gave birth to Web 2.0.

The web has changed and so have the expectations for what a site should be. At the same time, the pace of development has accelerated so that speed and efficiency have become inherent parts of the process.

The Agile Process, Illustrated In Graphs

In the diagram below, 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. Below, the modern (agile) web development process.


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.

The rapid iterations of Agile projects help to keep the process running smoothly, but the reduction in overhead—time spent scheduling, recapping, finding people to get feedback, dealing with staff reorganizations, accommodating moods, taking time for training—that yields such enormous time-savings.

For instance, your key stakeholders need to attend three hours of meetings over three days, instead of four meetings over four months. Agility requires commitment. At the same time, Agile teams feel empowered to make key changes and ask defining questions, such as:

  • 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?

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.

[Image: Flickr user Daniel Oines]




Article Tags: get agile





Add New Comment

2 Comments

  • PM Hut

    Hi Jason,

    It is yet to be scientifically proven that a project managed the Agile way is faster than that managed using Waterfall - and I'm talking about software/web development projects here.

    I also have to say that the image near the end of the post is completely detached from reality - in a best case scenario this image applies to a very narrow spectrum of software projects.

    Thanks for sharing.

  • Peter

    Thanks for the article! But aren't there factors that determine how a project should be managed? Timeline, budget, complexity, etc...