The birth of Agile
In February of 2001, seventeen software developers with an interest in lightweight development methods gathered at a resort in the Rocky Mountains in Utah. As they talked, they discovered some recurring themes and ideas, which they eventually immortalized in what they called the “Manifesto for Agile Software Development.”
Text of the “Manifesto for Agile Software Development”
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.
If that all sounds a bit vague, you can think of it as the counterpart to “waterfall” project management, the more traditional approach to large projects, which puts primary focus on specifications and project plans. (It’s called “waterfall” because of the visual image of each project stage falling to the next one, never to return, as opposed to the more iterative or cyclical approach of Agile development).
The general idea behind Agile is that instead of arguing about the wording of a requirements document written three months earlier with little perspective into the current situation, it’s often healthier to acknowledge that the project is going to be flexible and evolving, and put processes in place that allow it to be that way.
Barely over 200 words, that manifesto become the foundation for a movement that has changed the world of software development forever. Endless writing and speaking has explored the various ways the manifesto could be interpreted, and many specific frameworks and methodologies (such as Extreme Programming, Kanban, Lean, and Scrum) have been developed to formalize its principles. A whole “Agile industry” has emerged, with successful companies offering tools, training, consulting, certification, and other products and services. The economic engine behind the Agile movement as a whole is massive.
The struggle to evolve
Over time, word of the reported benefits of the Agile approach leaked into other industries, and companies began adapting it to the peculiarities of their own circumstances.
Agile is definitely not appropriate for all projects or industries. It’s great in situations where there’s some element of novelty (evolving requirements, changing priorities, flexible deliverables, and so on). It’s wildly ineffective for industries like commercial construction, where the requirements are rigid and the final deliverable is made of steel and concrete. However, there are many industries beyond software development (including UX design) where the Agile approach is a very natural fit.
Trying to adapt a philosophy with such deep roots in the software industry to a completely different industry, however, can be a frustrating and discouraging task. Elaborate methodologies built on certain assumptions about its participants can unravel when applied in other industries. (And it can take months or even years to figure out what’s not working, and why.)
In the face of these challenges, it was tempting to say “We tried Agile, and it didn’t work for us…”
Similarly, the many tools available to software development teams to help them implement Agile often make no sense in non-software contexts, leaving those teams to fend for themselves, inventing new project tracking systems with spreadsheets, note cards, post-it notes, or whatever else works. (That kind of forced innovation isn’t necessarily a bad thing, but still, it’d be nice if there were more Agile tools available in non-software contexts.)
On top of that, attempts to adapt or modify Agile practices can sometimes invite criticism from more traditional practitioners, simply because it’s weird and different. While most people in the Agile community were supportive and sympathetic toward our situation, there were some who couldn’t get past the idea that we were simply doing it wrong because we weren’t using by-the-book protocols.
In the face of these challenges, it was tempting to say “We tried Agile, and it didn’t work for us.” For industries like UX design, a waterfall methodology almost always goes wrong, but at least it goes wrong in comfortable and familiar ways.
Adopting agile for design
Our first exposure to Agile software development was around 2006, when we started interacting with a number of software firms who had adopted or were adopting the Agile approach. Shortly afterward, we moved into a shared collaborative workspace where we interacted regularly with Agile software teams, and often worked on projects together with them. In that kind of environment, it was natural to start picking up some of the philosophies and finding ways to implement them into our own project management processes. In early 2009, we officially adopted Agile as our standard project management approach.
Not long afterward, we were hired by a prominent organization in the Scrum community to redesign their customer experience (website, marketing materials, etc.). As you might expect, they wanted us to use Scrum (a specific Agile framework) for that project, and we were totally game for it. We were experimenting with Agile anyway, so why not throw ourselves wholeheartedly into Scrum and see if we could learn something?
And learn we did. There were lots of growing pains as we struggled to figure out how to apply Scrum’s principles to our own culture and practices. We had significant debates about the role of design (which implies planning and intentionality) in a context where everything seemed a little haphazard and constantly changing. Even trying to synchronize our work with the software team building their web application was a challenge, because we were working on different things at the same time.
Ultimately, though, we worked through most of those issues, found our groove, and produced a tremendous amount of really great work for that organization. We were fortunate to have great contacts there, who understood our frustrations and knew when to be flexible. We got the job done, and we were proud of the work we did.
“We had significant debates about the role of design (which implies planning and intentionality) in a context where everything seemed a little haphazard and constantly changing.”
Although we didn’t follow “proper Scrum” after that, we absorbed many of its principles and protocols into our own project management methods. We weren’t following any established framework to the letter, but we really did believe in the core principles of Agile, and we saw ourselves as an Agile design firm.
The uneasy relationships between design and agile
On the surface, it seems like design and Agile should magically work together, but there are some underlying philosophical issues you have to wrestle with before figuring it out.
Design is all about big-picture thinking: planning, strategy, working out all the details, thinking everything through, making it perfect, etc. (Eric Karjaluoto called it the “masterpiece mentality.”)
Agile, on the other hand, is more often about doing the basics and saving details for later: iteration, minimum viable products, “perfect is the enemy of done,” etc.
Those two worlds don’t blend smoothly together, at least at first. Agile developers can get frustrated with designers for over-thinking things (“Why can’t they just let it go? We can get to that later.”), while the designers get discouraged by the perceived low standards of Agile developers (“Don’t you want it to be good? Don’t you want the user to be happy?”).
In both cases, though, the problem comes from a misunderstanding of each other’s perspectives (as problems often do). The designer isn’t being obsessive, they’re just trying to do right by the user. And the developer isn’t being lazy, they’re just following a process that actually gets things done with minimal navel-gazing. Both sides could learn some important lessons from each other.
To adopt an Agile approach in the world of design, you actually do have to sacrifice at least some of the grand-scheming and obsessiveness that designers are prone to, and replacing it with some acceptance of real-world business scenarios, which often aren’t ideal.
“The designer isn’t being obsessive, they’re just trying to do right by the user. And the developer isn’t being lazy, they’re just following a process that actually gets things done with minimal navel-gazing. Both sides could learn some important lessons from each other.”
Designers always want to believe there’s an archetypal “right” answer, and they’ll struggle with clients for time and budget and direction to get at that right answer. They forget that the right answer is the one that works for the client’s actual situation. (If you only have a $20k budget, then a $40k website isn’t the right answer, no matter how many awards it would win.)
So once you struggle through the tension between the two world views, you can actually reach a very healthy middle ground that gives you distinct advantages and flexibility. An Agile approach to design actually works beautifully, once you understand it and give it some room to breathe.
It’s easy to suck at Agile
The Agile approach is difficult. Like any great philosophy, it gets messed up in the execution by the imperfect humans actually trying to implement it.
A controversial 2012 report from Voke dished out some harsh criticism of the Agile approach, including comments like these:
“Be aware that the Agile movement might very well just be either a developer rebellion against unwanted tasks and schedules or just an opportunity to sell Agile services including certification and training.”
“Survey participants report that developers use the guise of Agile to avoid planning and to avoid creating documentation required for future maintenance.”
“We received some unprecedented scathing and shocking comments about the level of competence, professionalism, and attitudes of some members of the Agile movement.”
“Sixty-four percent (64%) of survey participants found the transition to Agile confusing, hard, or slow. Twenty-eight percent (28%) report success with Agile.”
“Overwhelmingly, 40% of participants that use Agile did not identify a benefit.”
Although Voke was excessively hyperbolic in this particular report (it sells more that way), I’m not surprised to hear results or conclusions like that one. Honestly, I’d expect results like that for pretty much any methodology, even the good ones. (I’d bet that 64% of anybody finds the transition to anything confusing, hard, or slow. We humans aren’t great at transitions.)
You can think of Agile as a belief system, like a religion, philosophy, or political party. In most belief systems, the core principles are actually really great. Even when different belief systems disagree, you could probably follow one or the other and still be in pretty good shape.
The problem comes when large groups of people start rallying under those banners, with little depth to their understanding of what they just signed up for. The unfortunate truth, regardless of the belief system in question, is that most participants will probably understand it poorly, and therefore execute it poorly.
If your team’s lazy, Agile won’t make them productive. If your team’s sloppy and haphazard, Agile won’t make them organized. If your team keeps screwing things up, Agile’s not going to make it all suddenly work right.
However, if you have good people in place and you’re working on the kinds of projects where Agile is appropriate (not building a skyscraper, for example), they’ll probably do better with Agile than without it.
Don’t let that last Voke report scare you too much, though. Generally speaking, Agile does seem to work quite well. A 2011 study by the Standish Group, for example, found that projects were three times as likely to be successful as those following traditional waterfall project management techniques.
Getting to the heart of agile
As our project management methods evolved over the years, we started to find ourselves experiencing “Agile guilt,” because we weren’t doing daily standup meetings, or because we occasionally put together a Gantt chart for a client to explain a rough project workflow, or because we didn’t have an appointed scrummaster.
Not long ago, I thought we’d actually given up on Agile. Our project management approach has evolved in a way that’s tremendously efficient and effective, but may not look like orthodox Agile to the casual observer anymore.
However, I eventually took some time to read the Agile Manifesto again (as well as the associated 12 principles), and was surprised to find that not only did we still believe and practice those core elements, we were actually really good at them.
We were rocking Agile and didn’t realize it because we’d mistakenly bought into the notion that Agile is defined by the rituals and rules that have evolved around it. It’s not. Agile is actually really simple.
For me, the Agile approach is really about acknowledging that disturbing truth that every project manager knows, but has trouble admitting. The truth that the project plan is wrong. Scope creep. Change orders. Shifting priorities. New directions. We act shocked and appalled when those things happen during our carefully-planned project, even though they happen on every project ever. We go back and point to lines of text buried in documents, written months earlier and read by nobody, to explain why we shouldn’t have to do something that the client now believes is important. Is there any other industry where something happens 100% of the time, but we still pretend every time that it’s not going to? It’s madness.
The Agile approach, at its very core, is about acknowledging that things evolve in the real world, and that we might as well embrace that fact and figure out how to do it efficiently, instead of treating it like a terrible thing that never should have happened.
I’m proud to say that we actually do that really well. We don’t lament scope changes the way most design firms do. We don’t whisper nasty things about our clients when deadlines shift and priorities change. We understand those things happen. We embrace it. We’re okay with it. And our processes effectively allow those things to happen, because we knew they would from the beginning.
Still agile at Forty
The way we work here at Forty doesn’t really fit any of the formal Agile methodologies, and we’re okay with that. Here are some examples of what Agile looks like for us on a day-to-day basis:
Agile principle: “Individuals and interactions over processes and tools”
Our philosophy is that each project should work well for each client, so we might for example use Google Hangouts for one client, and then Skype for the very next meeting, because that’s what those clients are comfortable with. Or we might have a standard workflow that we use on most projects, but on a particular project we’ll swap it out for something else that’s a better fit for that context. We’re not rigid in the way we do things; we bend and flex to fit the situation.
Agile principle: “Working software over comprehensive documentation”
We’re not delivering software in the same way that an Agile development team would, but we still focus should be creating things that actually work for our customers, rather than getting bogged down in theory and showmanship. We have a certain amount of documentation that helps explain what we’re doing, but we try to keep it as lean and minimal as possible, cut out the dog & pony show, and focus instead on giving our clients clear and relevant solutions that solve their actual business needs.
Agile principle: “Customer collaboration over contract negotiation”
Years ago, we used to have to pull out our contracts and point to certain statements and saying “You promised this” and “We never said we’d do that.” Not anymore. We eventually realized that as soon as you have to pull out your contract to “prove” something to a client, you’ve already lost them. Now, instead of relying on detailed scope definitions to keep our projects in line, we focus on clear communication and expectation-setting. When everyone involved understands what’s happening, and why it’s happening, and what’s going to happen next, there’s very little reason to argue about it. We trust each other, and we work together to do great things instead of nitpicking each other about minor details.
Agile principle: “Responding to change over following a plan”
This is a big one for us. We’ve come to see scope change as a natural (and healthy) part of the process, and we plan and price our projects accordingly. With many of our clients, we actually have a simple monthly retainer that enables us to make as-needed course corrections without stopping the project, renegotiating, re-estimating, etc. Even our more structured projects have a living project plan that evolves over time to account for changing priorities, contexts, etc. We still do a lot of planning, but we don’t fight the change when it inevitably comes.
Agile is hard, but it does work
It was actually a surprise to me when I read through the Agile manifesto and the Twelve Principles and realized we were actually diligently following them all of them, almost by accident. I thought we’d given up on Agile until I realized we’d actually been doing it all along. We’d cut through all the rules and protocols and gotten to the heart of Agile. Everything else flowed naturally from there.
Agile really does work. We get more done, we have stronger relationships with our clients, and we’re creating higher-quality work because we follow those core principles. We didn’t concern ourselves with following one methodology or another; we figured out what Agile meant to us, and then we did it.
And despite the fact that the Agile methodology is oriented heavily toward software development, its core principles really do apply to almost any project where things are changing and evolving. In the world of design, change is an everyday reality, so Agile is a very natural fit, once you figure out how to make it work for you. We’re years into it now, and seeing only great results.
