Project management: Agile methods

I've heard arguments against Agile methods. Some people dismiss it and call it “Fragile.” Others aren't comfortable with the self-organization and lack of hierarchy. I've also heard Agile described as “just another word for not getting anything done.”

So I get it. It’s not for every company, nor is it for every project. If your team is asked to deliver a 20-page website in 12 weeks and it’s the sort of thing you’ve done several times before, using a waterfall method is a predictive way to plan predictable work.

However, Agile methods aren't for stable environments. A company using Agile instead of conventional project management understands that their business environment is unpredictable, and they intend to ship products and services while managing continuously emerging requirements.

Here’s a graphic that I love. It’s called the Spectrum of Process Complexity. I didn’t come up with it (you can Google several versions), but I will take the credit/blame for this version:

The Spectrum of Process Complexity asks two basic questions:

1. Do you know what you will do today? If your day-to-day tasks don’t change that much, your requirements are predictable.
2. Do you know what tools you will use, and what solutions you will employ, to do your job today? Again, if you use the same things every day to complete the same tasks, your process is predictable.

Have you figured out who you are yet? Your job — or what your team does — falls into one of three areas:

• Predictable: Manufacturing and service jobs can be found here, and workers in this area are often assigned repetitive tasks. Some of these jobs have a low barrier to entry, such as fast food service, requiring only minimal training. However, others in this area have specialized training, such as machinists and airline pilots. What matters is that the work expected is predictable, the outcomes conform to pre-defined criteria, and rapidly emerging requirements are rare to non-existent.
• Innovative: Work in this zone typically is done by people with professional credentials — but again, that’s not what defines it. If you’re somewhere in here, you and your team spend a lot of time coming up with novel solutions to emerging problems. UX and software design definitely fit in here, particularly when new products are expected to anticipate market trends, and thus must continuously adapt to emerging requirements. However, a lot of retail customer service is in this zone as well. In fact, Nordstrom essentially re-defined customer experience by empowering their sales associates to exceed customer expectations instead of following a prescriptive set of rules.
• Chaotic: You probably don’t work in this zone, and odds are you don’t want to. If you’re here, you have no idea what will happen at work today, and you have no idea what solutions you will use to do work you know will happen but cannot predict. First responders work here, which is why the fire department goes everywhere in a big red rolling hardware store. Seal Team Six works here as well, and MacGyver, and the cast of every disaster movie ever made.

Hopefully, your workplace doesn’t look like the the second hour of Armageddon by lunch. However, if you get the feeling that the team is always “playing catch-up” to the work, or “putting out fires,” or any other tell-tale clichés, you might want to ask if you are using the right approach to the work — which is to say, the right project methodology.

Why Agile?

“Agile” was not created in a laboratory, or a think-tank, or by a some company with an idea that would sell if only it could find a market. Agile consists of nothing more than a simple manifesto crafted by a group of software professionals during a weekend retreat in 2001:

Why did they all decide to hang out at a ski lodge for a weekend? Because the waterfall project methods they had been using at their software companies were not working — products were defective, late to market, or not getting shipped at all. Talented employees were increasingly demoralized by “make-work” documentation and unrealistic planning estimates. Waterfall was the wrong approach to the turbulent world of technology and software design.

Independent of each other, the first Agile software professionals (in some cases, business competitors) had come up with new project methodologies to correct course. There were various methods — among them Extreme Programming, Adaptive Software Development, Pragmatic Programming, Crystal, and Scrum — but the group saw the common underlying values.

Agile puts collaborators and customers at the center of the process. It intentionally deprecates both hierarchy and personality-oriented work environments. And it emphasizes incremental development of continuously evolving products, with the expectation that each product release will be functional and useful. It’s a set of project frameworks for people who are expected to innovate, rather than be constrained by predictive methods.

Agile is not right for every organization, job, or task. However, when it is the right fit, it becomes a substantial competitive advantage — especially for companies who intend to get their products to market first, and they expect them to exceed their customer’s expectations with rapid, continuous iteration.

> Next: An Agile workshop