The Role of Speed & Grace in Being Agile

Real agility helps us achieve important outcomes faster. Speed (or quickness, if you prefer) and grace are part of the definition of agile: marked by ready ability to move with quick, easy grace. So what is the role of speed and grace in being agile?

Let's begin by exploring what a few people have said about speed and agile.

In response to my article, I'd Like You to Know the Definition of Agile..., my friend Michael Bolton, said, "I’d like to offer one nuance: the quickness to which I believe agile refers is not necessarily forward motion, but the ability to turn quickly, and to recover your balance quickly when something comes along to knock you off it. I think of the kind of quickness associated with an acrobat or, as you suggest, a dancer, and not so much with a sprinter. (Otherwise, I believe, we’d just say “fast” or “speedy” or “swift”.) The kind of speed allows agile teams to make quick and graceful course corrections, rather than running frantically in one directly. Frantic plus agile equals fragile."

Michael is pointing out that speed alone isn't the point of begin agile, because speed alone may yield poor results. Real agility requires moving with speed and grace, quickly adapting to changing conditions and achieving quality outcomes faster.

Tim Ottinger, a veteran agile coach, instructor, developer and colleague at Industrial Logic, wrote a great piece called Sooner, Not Faster. He writes, "If you are going faster than you are able to manage, then what you are doing is not agile, it's just hurried. Your managers and customers want code sooner, but do they really want hurried code from an exhausted, out-of-control team? I can't tell you how often in my early career I've been on teams pushed to go faster and faster, only to be blasted by the same managers for being out of control. They didn't really want faster. They wanted sooner."

Like Michael Bolton, Tim Ottinger is decrying the push to simply go faster, at the expense of quality, sustainability and good outcomes. Sooner, is his word for the combination of speed and grace.

Finally, Alan Cooper (@MrAlanCooper on Twitter), recently wrote a tweet storm about agile's association with faster. Here are a few choice selections from his tweets:

"The main reason why agile methods are popular is because managers think it means doing things faster. Classic, industrial-age management likes things to go faster because that means things cost less. Agile, of course, has nothing to do with going faster. It’s reason for existence is to do things better. Doing things better is hard. How do you know you’re better? You have to know what your goal is to know that, and that’s hard. It’s just damn easy to say I shaved a month off of the schedule, but damn hard to say I made the product better."

Alan goes on to say, "Now, I’ll be the first to agree that going as fast as possible is a very good thing, and that going slower than necessary is bad." The trouble comes, he says, when we go fast to hit a deadline and let quality suffer. He stresses the need for quality over deadlines: "The only way to make better quality digital products in a corporate environment is to establish quality goals. Qualitylines."

Alan acknowledges that "going fast as possible is a good thing" provided we can do so with quality. Without quality, we lack grace. Real agility is hard because it requires moving with both speed and grace.

So what are ways in which speed and grace play a role in genuine agile software development? Here are a few:

• Market validation: A few bright entrepreneurs had the idea to help auto mechanics by producing modern software solutions for them. But before building the software, or raising money to do so, they visited several auto mechanics to interview them. It turned out that none of these auto mechanics had much pain associated with their existing software, even though it was decades ago. Quickly learning that the auto mechanic shops had no interest in spending money to upgrade their software, the entrepreneurs quickly shelved their idea and gracefully pivoted to discover a market that actually needed and would pay for a better software solution. Quickly validating or invaliding a market need for a product or service is essential to being agile.
• Prototyping: To avoid wasting time producing a solution that doesn't match our needs, it helps to rapidly prototype alternative solutions. When I work with an illustrator on a new image, I ask them to quickly sketch several alternatives so I can decide which one captures the idea I'd like to convey. Once I've selected a sketch, the illustrator can craft and refine a solution (see my article, Sufficient Design in Sketch, Craft, Refine Cycle). We use a similar process in software development, preferring tools that allow us to rapidly and gracefully prototype or simulate a solution before investing heavily in crafting and refining a solution.
• Solution Identification: When writing software, you have many ways to solve a problem. How can you work quickly and gracefully to achieve an excellent outcome? Which solution will be sufficient for customer needs and which will be overkill or unnecessary? What will be affordable to develop and what will be too expensive? How can we quickly obtain high value at low cost? It helps to consider options. I call this process bargain hunting, a way to save time and money by considering several ways to solve a problem and identify what could be a suitable solution. Bargain hunting is not an excuse to cobble together inexpensive solutions into a bad design. It's a way to explore and discuss alternatives in order to find a suitable solution. You can often produce a solution with higher speed and grace by initially deferring the "bells and whistles" of the feature for another time. Sometimes you discover that users don't even want the bells and whistles.
• Experimentation: When we don't know what to do, we need to run an experiment. To learn rapidly, we want to experiment as quickly as possible. Do users want some new feature we just dreamed up? We don't know, so we'd better experiment to find out. To do that, we have a variety of high speed tools or approaches, from paper prototypes to customer interviews to lean UX (user experience) techniques like a feature fake (see my article, Fast Frugal Learning with a Feature Fake). If you can quickly identify features you don't need to produce, you'll save lots of time and money. This is called maximizing the amount of work not done, which is all about speed and grace.
• Analysis: A product manager in a bank was asked to increase the number of people using the bank's website. The data showed that many accounts were completely dormant and the bank wanted these dormant accounts to become active. She began analyzing the account data. Soon she realized that many of the dormant accounts were from households where the partners each had their own account, but only one of them actually used their account to manage the couple's finances. It was unlikely that the other account would ever become active again. Through her analysis, this product manager quickly discovered that the goal to re-engage dormant accounts in the case of a couple was not worth pursuing. Good analysis helped her move with quick, easy grace.
• Decisions: When questions arise during software development, you want answers as quickly as possible in order to gracefully produce a solution. A colleague and I once started work on a new feature, only to discover that it was going to take far more time to develop than initially estimated. Since the people who requested this feature sat in the same room as us (called the on-site customer, in Extreme Programming), we immediately discussed with them what to do. Together we decided to change the design of the feature in such a way that it would deliver the same functionality with a simpler and faster-to-implement design. From our discovery of the problem to a satisfying resolution took minutes because decision makers were quickly accessible.
• Workstation Setup: From the moment a new developer joins a team, you want them to be productive as quickly as possible. Everything about this process ought to be fast, from ordering the new machine to setting it up for development. Smart teams quickly setup new workstations or development environments by means of reliable, automated scripts, virtual machines or cloud-based solutions. A new developer ought to be able have a functioning software development environment as quickly as possible.
• Knowledge Transfer: Given a new team member, the faster they understand the code and tools used by the team, the sooner they'll be productive. We perform knowledge transfer as quickly as possible by pairing and/or mobbing with teammates. We take time to answer their questions so they can rapidly learn, rather than letting them slowly figure things out on their own.
• Automated Tests: programmers want their automated tests to run extreme quickly in order to know if a new change broke any existing logic. Slow automated tests slow down development and lead some programmers to avoid running them. I've learned over the years to make sure that the bulk of our automated test run as quickly as possible. We design each unit test (at Industrial Logic, we call them microtests) to run in microseconds. We also make sure our acceptance tests run as quickly as possible, sometimes setting up these tests to run in multiple threads in parallel to save time. We don't allow for fragile tests. If a test is fragile, we fix it so that it is reliable and can run correctly over and over again. You won't develop with quick easy grace if you can't trust your automated test failures to be actual failures rather than false negatives.
• Programming: Complex code is slow and hard to modify. To enable high speed development, we make our code easy to understand and modify. We refactor code to make it intention-revealing: the names and design of the code easily communicate our intention, so a developer can quickly grasp what the code does. We remove code that is no longer being used. We produce well-written, automated tests that function both as as safety net (catching our errors before they go to production) and executable documentation, helping developers quickly grasp how code works in order to let them modify or extend the behavior of that code. Good programming practices help us move with speed and grace even as the code ages.
• Builds: A slow build process, be it manual or automated, delays feedback to developers, which wastes time and may even allow defects to creep in. We work hard to make sure our builds run gracefully and quickly. We do that by automating builds and optimizing them to run as fast as possible.
• Integration: Merging software changes with code that other developers are also changing can be slow and painful. The longer you wait to do it, the harder it gets. We practice continuous integration to move with quick easy grace. As soon as we've produced working software. we quickly integrate it into the master source code repository. The smartest teams use trunk-based development and integrate many times per day. If the build breaks as a result of the change, we get the feedback instantly and can quickly fix the problem. The team endeavors to always have a working build, so that new changes may be integrated safely.
• Deployment: Whether we're fixing a defect, putting a new experiment into production to gather data, evolving a new feature or enhancing an existing one, we want to release new code gracefully and at high speed. A reliable, continuous deployment pipeline helps us do that. We want this pipeline to deliver our work to production safely and quickly. We want our pipeline to fail fast and alert us quickly when there's a problem. If there's a problem in production, we want our pipeline to enable us to roll back or roll forward changes quickly and gracefully. At Industrial Logic, we made it easy for even non-technical people to safely roll back a bad release. At AirBnB, new developers release safely to production within the first two days of their employment.

The above is a sampling of ways in which speed and grace play a role in helping us be agile in software development. The list could go on and on. Similar lists could be created for other human endeavors, not related to software development. Whatever your field is, as you work on being more and more agile, consider how speed and grace influence your decisions and actions. While it isn't easy to move with quick easy grace, learning to do so could help you achieve awesome outcomes.