Agility and Agile—capital “A” Agile, Agile as a proper noun—are in a little bit of trouble. A 2017 survey of 300 CIOs reported that over half of them regard Agile development as “discredited.” Three-quarters of CIOs are no longer prepared to defend it, and half of them say they now think of Agile as an “IT fad” (source).
This problem is ultimately the result of Agile being sold as snake oil, the solution that will fix all the issues within any given organization. Then, when things don’t get fixed, it’s Agile’s fault. “It’s just a fad, it’s discredited.” But capital-A Agile is very easy to get wrong. It’s easy to dive right into using some Agile method, an “Agile tool,” without really understanding it.
So, what is Agile, and what does it mean to have agility? It can be a little tricky to understand. If you think back to playing video games, you have a character you’re playing with that has certain stats—usually things like speed, strength… and agility. Strength makes perfect sense; a character with greater strength would probably win an arm wrestling match against a weaker one. Speed seems obvious as well—the faster character would win a race. So what about agility?
Agility starts with awareness. Imagine a video game character or comic book superhero that has agility in the middle of a battle against an opponent, and a second opponent emerges to attack out of nowhere, but our agile hero has the awareness to duck the punch. They’re adapting to that changed situation quickly, and saving the day.
Awareness enables that agility; agility is adapting to change based on an awareness of a changed reality. This is not just something that exists for video game characters and superheroes—humans can be agile, too. Anyone who’s had to change their plans for some reason has experienced some form of agility, even though it may not feel like the most extraordinary thing in the world to change your dentist appointment because something came up. Flexibility on everyone’s part in that changed reality, and that adjustment to taking on the right thing to do next, is on the scale of agility.
But we’re capable of more than just adapting to change, and agility is about more than that. If we compared deliberation and hair-trigger reaction, which one would be considered more agile? Agility is more than mindless triggered reaction, but neither one of these concepts on their own are entirely agile. If you are too focused on deliberation, you might find the awareness can be crippling for you. There’s too many things to think about and consider, and you may spend so much time thinking that you become stuck—but behaving like a loose cannon, relying only on knee-jerk reactions, can actually be far worse.
Your agility is measured by the effectiveness of your response to any given situation. The faster you can deliberate and come up with an effective action, the more agile you are. Doing something with agility balances your awareness of the situation and your deliberation of options with your speed of response. However, this is a little different from a thing or an activity being agile, like design or development.
For something to be agile, it needs to bring awareness to itself and allow room for adaptation. How can something be agile? We can first look at Scrum; it has ceremonies, it has values, and it has iterations. The ceremonies include a daily standup meeting, where everyone on your team can share what they’ve been working on, what they’re going to be working on, and where they’re stuck, and that’s bringing in a daily awareness. Whatever that is will support us in deciding the right thing to do that day, to continue guiding the team towards accomplishing the sprint goal. The daily standup is where you purposely pause to gain awareness, get a sense of what reality is, and adapt to that changed reality.
The dilemma here between agility, Scrum, and design, lies in the quote, “You never get a second chance to make a first impression.” Designers understand a statement like this instinctively, because they have a lot of pressure on them to create with purpose, deliberately, and with intention. The parts of design that will be hard to change later get the most attention. If we consider an iteration shipped in a state which a designer or design team would consider a less than desirable state, there’s a risk that this work will not have the intended impact on the viewer, and that could change absolutely everything. When presented with a goal from a client, like “We want to increase our online enrollment by 50%,” there is a lot of pressure and stress around getting it right the first time.
Planning reduces stress, so there’s a tendency and a desire to plan a lot, to engage in a very big discovery or planning phase, and try to get it all lined up just right from the beginning. We think about the big, grand, perfect, end result, and we think we need to spec that all at the beginning. It’s natural for us to think that way, and you can even see this happening when people try to switch to working with Agile, and they end up with concepts like Sprint Zero; they want to be iterative, have a shippable increment at the end of all their sprints, but first—the Big Huge Planning Sprint. It’s hard for us to escape.
You can plan for months and still end up going in the wrong direction. Masterpiece mentality ensures perfect as the enemy of good—you can launch something a little less than perfect, or never launch something at all. Agile, when sold as snake oil, often results in management thinking they’ve escaped the responsibility of deliberation, but agility actually means we do just enough good thinking to be able to get started, and we don’t get bogged down in overthinking. After you get started, you keep yourself on the right track with feedback, getting it early, and getting it often. Once you know what the reality of a situation actually is, if you need to, why wouldn’t you immediately change course and do the right thing? When it comes to designing with agility, it’s about looking for that feedback, it’s being open to change, and it’s about changing quickly. But what about our design process and our methodologies? How do we get it right when we’re faced with something that’s bigger than what just one of us can do? How much do we plan?
Design creates something—it is deliberate and intentional, it’s not haphazard and reactionary. You could argue that design without deliberate intention is not design. It’s worth considering where creativity fits into our agility. If doing something with agility balances the deliberation of options with the speed of response, then it is creativity that generates those options when we are designing something new. This is why Design is such a challenging fit with a desire for a speedy response. The best options may not yet have emerged, they need to be discovered, and this takes time. To make this agile, what we really need are adaptive iterations that bring awareness to our work for a maximally effective experience.
As an example, we can cite LCM’s work with NTEN on their Nonprofit Technology Conference. We did a very limited discovery with them, just to learn more about their organization, the conferences they had in the past, and to generate some ideas from all sides. One of the decisions that we made in terms of design was to start with small, high-fidelity pieces, like logos; the high fidelity aspect, I would consider a way to optimize for awareness. If you do a lot of low-fidelity, “back of the envelope” sketches they won’t have the same feeling or elicit the same emotion from your viewer, and the person who needs to make a decision won’t be able to make as informed a decision as they would be able to if they were presented with a more polished piece. Since the idea is to not spend too much time on any one direction at this point, logos are a great way to get a conversation going and help you get on the right track. This approach helped get us to an agreed-upon theme for the conference brand in one meeting with the client.
From this place of alignment, it’s much easier to extend this idea out to other deliverables, and it’s a lot easier to get acceptance on something that is consistent with the thing that came before it. You can even evolve this further, as we did with NTEN, by having the marketing and site content be consistent with the look and feel of the designs.
What about design sprints? LCM worked on a seven-day design sprint with a client at Johns Hopkins. Again, we planned just enough to get started, to quickly get something reviewable in front of the clients so that you can stay on the correct course. Collaboration with the customer is of paramount importance, and in this instance, we kicked the project off with an on-site visit to the client’s lab. They had extremely colorful art depicting their work in computational cardiology all over their walls, and we allowed that to influence us and carried a similar idea forward in our work. We first created vibrant hand-drawn illustrations over the course of two days, and then simultaneously moved into creating logo options while fleshing out the overall design of the website. All of our assets were handed off to their development team on day seven, and the pace of this project was made possible by the agile way we worked—doing a little of something, getting feedback on it, going back and doing some more that takes the feedback into account, then getting more feedback, over and over until everything was in a good place.
One of the big tricks to the success of this approach is that you need your client’s trust, and their respect. If you don’t have that, you can end up in a process where you are expected to promise perfection on a specific timeline. You need to be treated as if you’re doing the best that you can.
In the Johns Hopkins project, we didn’t start with a logo, and actually, including a logo in our work wasn’t planned. So agile, right? There’s a misconception that agility means you go in without a plan, but the reality of agility is actually that you should always be planning. Not planning has consequences, and creates a lot of waste. In this example, we did so well and worked so efficiently that we were able to add logo work to the sprint—if we had stuck to the “plan,” we may have left that client feeling like we didn’t really utilize the time they paid for in the best way. We may have allowed ourselves too much time to second-guess our approach, and ended up diverging down a different path that wouldn’t have been as successful. We have to sense and respond, inspect and adapt, to remove the waste of going in the wrong direction, which is one of the core ideas of an agile methodology. Even if your direction ends up being in direct opposition to the way that you thought you were going to go in the outset, it doesn’t matter, if it’s ultimately the right direction.
When it comes to design, if we can make something easier to change later, we can get started sooner, and be more Agile. This is really where pattern-library thinking comes in, because working in patterns that are applied broadly across a site makes it especially easy to change something at a later date, so we don’t need to plan as much to get started. Having your entire team waiting while a few people plan and design everything out is pretty wasteful, but it can be very challenging to break people out of the mindset of needing to have everything done in order; the designs are done, now they’re passed to development, development knows exactly what the thing they’re making is supposed to look like. If something goes wrong, it’s not really on them, because they just built what they were told to build. It’s very comfortable, and it’s the way many people are accustomed to working. In order to shift to a more agile method of working, it’s important to first have conversations with your team and ensure that they understand that it’s expected, and okay, to have to figure things out as we go. That’s just reality—you can’t figure everything out ahead of time: you will learn more later. Even if you think you’ve figured everything out, you’ll inevitably find out at some point that you didn’t. What happens then?
The reality is, it would be a really boring project if you actually figured everything out at the beginning, and that’s simply not the nature of the work that we do. With Agile, we can do that figuring out together—guessing right or making mistakes, listening and correcting our course. It’s in how we work that lets us do more together, and be better and faster at it. Designing with agility is designing the bare minimum you need to get to the making, and then designing more. It is emergent, and intentional. It hypothesizes, experiments, senses, speculates, adapts and responds in an evolving relationship with those affected by the design. We don’t always have the answers given to us at the start, and that’s okay.
See the original 2017 Design4Drupal Keynote presentation here.
