Hey friends, welcome back! Today we're going to talk about a term that I'm sure you've run across if you've spent any time as a developer in an organization: Agility.

Definition

Agility... seems familiar as a software development term, doesn't it? I'm sure you've heard of Agile project management somewhere along the way... if you haven't, the fact that you're reading this blog means you're likely to encounter it in your professional career, sooner rather than later! But I'm not talking about the adjective 'Agile' today, I specifically picked the noun 'Agility'. More on that later... but for now the definition we're going to use for Agility is "the capability of changing direction quickly".

But I Digress... Agility vs Agile

(If you don't care about such things, feel free to skip to the next header!)

Agile has unfortunately become a label for things... often things that it shouldn't be a label for at all. People tend to use it when they mean "Scrum"... or they put it in SAfE (Scaled Agile for Enterprise)... and in both of these cases, the term has come to be related to a framework whose proponents have come to advocate as THE Way. Somewhat ironically and extremely sadly, we find that Agile is something inflexible and rigid.

I choose to use the noun Agility here to set a distinction - the desire for agility (that is, nimbleness) is where Agile started, but the adjective has lost its way.

Why Agility is important

Maybe you're the "purist" software engineer, who doesn't care what project management does. You're just there to pump out code. "Ben, this stuff doesn't apply to me!" Well... I would disagree heartily.

If you're writing code for pay, it's incumbent upon your code to successfully solve a problem. Otherwise, who's going to pay for it, right? And if they don't buy it, your employer doesn't make money, and you don't get paid.

...so how do we know we're solving the right problem?

Well... we don't. You can read about lots of companies that have pivoted throughout history:

• Nintendo made playing cards.
• Amazon was strictly for selling books.
• Nokia produced pulp and paper.

They thought they had a business plan that made sense. They might have even been successful in that market... but along the way they realized they could... that they should... do something else.

What if their software teams hadn't been empowered to go forward and embrace these pivots?

Businesses succeed and fail based on their ability to adapt. What you think is the best possible move today may be wayyyyy down the list tomorrow, and you're going to need to drop that move and focus on the new direction.

I don't know if you've noticed, but the pace of business has accelerated in the last couple decades, hasn't it? One major example of this was the absolutely break-neck scramble for businesses to adopt remote work policies in early 2020 when COVID hit the news. I watched organizations that said "we will NEVER let people work from home" suddenly be forced to switch to everyone working from home. For some organizations, it was easy to make the change... others kinda struggled though, didn't they?

Agility in Software Delivery

While many of these examples are macro-level talking points, we can watch the need scale right down to the code we write. If we embark on a large major change to our software, and a wild confounding variable collides with us tomorrow, we're either going to have a big change or a missed opportunity. It's in our best interests to work in smaller, "bite-sized" increments... because then if we have to change direction, we don't lose as much work to the "back-burner".

Ok Ben, you convinced me - now how do I work on my agility?

• Budget smaller and shorter. Why do we budget annually? (Because it's the way we've always done it and the folks in accounting said so) Could we budget... quarterly instead? What would change if you focused all your attention on ONLY what's happening in the next 3 months, and then as you approach the end of that 3-month window, you started thinking about what the right next-steps were? You wouldn't have the "security blanket" of having the whole year's budget figured out and allocated, but... you WOULD likely make better decisions because you'd be able to react to things you learned as you go.

• Stop pork-barrel projects. In the past, getting funding for a project was complicated and scary. We responded by trying to request fewer projects, but we'd cram every little idea into it that we could fit. Yes, this will be partially fixed by smaller & shorter budget cycles... but even then we'll have a tendency to want to cram more in. Stop it, and just approach each idea as its own thing. Which leads me to my next tip...

• Frame your roadmap items as "bets". Think of this: every decision you make about your product is an investment of resources (time/money) in producing an outcome... but the outcome isn't certain because that feature might not work the way you want, or your customer sentiment might change. That's... gambling! So as you build your list of to-do items, framing them as specific bets that you're planning to make will help you assess what's most important. Do you need some quick revenue wins? Safer bets might be features with more research into their expected performance. Do you have a little slack and have some additional risk tolerance? Make a riskier bet to see if you can win big. Is the economy a dumpster fire right now? Minimize the betting and focus on efforts that can help you ride out the storm.

• Insist on measured results. If every product decision is leading to an uncertain outcome, you should measure the crap out of it to know exactly what you're getting. That's how you can inform the next item on the priority list!

• Openly share learnings. If you're in an organization, you're likely not the only team doing stuff. Your learnings might be critical for an adjacent team to know about. Make sure that you don't hide your results - I know there could be political reasons to want to, but this is about the greater good!

Wrapping up

Agility isn't something for your PM to go to seminars about, and it doesn't mean holding all your team meetings standing up. It's the way you position your mind to think about work so that you can deliver what's most important as fast as possible.

As a software engineer, you're part of a kind of "elite" group - SWEs are often some of the highest-paid people in a company (aside from Executives). What you do with your time has a HUGE effect on the success of your company; good stewardship is a must!

Tune in next week when we continue the DevOps series, discussing Continuous Integration!