Twenty years ago, an agile rebellion started among a small pocket of besieged software developers. Today, the benefits of agile methodologies have improved stock trading, federal bureaucracies, celebrity chef-led humanitarian efforts. Yet Agile has started to lose favor. This has prompted us to get back to basics and start a series focusing on the Principles of Agile.
The eighth Principle of the Agile Manifesto reads:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
When I see this principle, I start to wonder exactly how much of my approach to software development is due to early exposure to the Agile Manifesto. I have thoughts and opinions that I consider my own, but reading back through these principles, I realize so many of my deeply held beliefs are rooted here.
A sustainable pace of work is one of the core tenets of Simple Thread. We don’t want our team working long hours on a regular basis, even if they’re willing to. This is partially pragmatic, because we believe there are rapidly diminishing returns when you try to do intense, creative work for too many hours. You will inevitably hit a limit and start writing more bugs, creating sloppier designs, etc.
However, this is also driven by a simple principle: it’s how my cofounder and I want to work. We want to have a sane work-life balance, and we want that for everyone on our team. We wanted to create a company and a team culture where we’d want to work, not just for a year or two – for the rest of our careers, forever.
Forever requires serious sustainability.
Why is sustainability hard?
I’m going to start this answer waaaay back in the mists of time, when I was a lowly undergrad at UVA. I took a lot of high-level philosophy and religious studies classes, and the small graduate seminars were often graded on a single essay due at the end of the semester.
A single assignment. Due months and months from now. For a college student.
Yeah, I’ll be honest. I often struggled to take a disciplined approach to those assignments, waiting until a few weeks before the end of term to get serious about writing the essay.
Or sometimes I’d try to be responsible and outline along the way, fill in rough chunks of research, etc. But then when I started trying to shape it up into a cohesive first draft, I’d realize I actually wasn’t as far along as I thought. These vague ideas and half-finished thoughts didn’t really work together.
At first, I thought it was just me. I was often younger and less serious about the course than the other students. But I soon realized pretty much all of the students struggled with it, to varying degrees. One of the other students, actually my TA in another course, told me his secret. He’d schedule office hours with the professor to review his essay at certain points during the semester. He knew that would force him to get his thoughts clear and make some progress, at least enough to have a conversation.
Hmm, scheduling check-ins with the professor sounds a lot like scheduling regular demos with a client.
As I left academia and joined the workforce, I came to realize these problems of time management weren’t just an issue for young irresponsible college kids. Everyone struggles with making progress on large projects when there’s no sense of urgency, no deadlines looming. Everyone underestimates the work required to take something from “80% done” to 100% done.
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
Tom Cargill, Bell Labs
Without some structure to help us, we’re going to back ourselves into a corner where we have to work unsustainably. It’s just human nature – not for everyone all of the time but for many of us much of the time.
In the modern world, we all have a never-ending stream of work we could be doing. It takes heroic levels of individual discipline to consistently set aside urgent work and focus on critical work due months later – unless you set up systems to support you in this.
There is also a more sinister side of things where businesses will intentionally prioritize short-term profit over long-term responsibilities, e.g., not caring if they burn out employees in the pursuit of hitting quarterly targets. But for this essay, I’m focused on the problems that arise even when everyone has the best of intentions.
How does Agile help?
Agile helps mitigate these problems in a few ways. First is the simple idea of working in iterations. You break the large project into smaller projects with smaller deadlines. Now you’ve regained some of that sense of urgency – but with less of the anxiety that often comes toward the end of a project. It’s a sustainable sense of urgency.
Another big way Agile helps is its focus on working software. It’s important enough that it’s mentioned in multiple principles. By frequently delivering working software, you are forced to get it much closer to 100% done. You might not do every bit of the polish and all of the documentation, etc., but it should be close. Getting parts of a project done done along the way has so many benefits.
You greatly minimize the problem of the last 10% taking the other 90%, but you’re also getting feedback along the way. This should minimize the volume of surprise rework, which is a surefire way to cause unsustainable scrambling late in a project.
Other principles support sustainability too, e.g., the focus on technical excellence and regular reflection. It almost seems that if you were following all of the other principles, you might not even need this principle to be explicitly stated. I’m glad it’s included though, because it’s a good counterbalance to the principles focused on the client and the output of the team.
It’s a vital framing of how the other principles should feel to the team, not just their behavior and responsibilities.
Sustainability is a virtuous cycle.
Just as the other Agile principles feed into creating a more sustainable pace, having a sustainable pace supports the other principles.
Imagine two teams. Both have been working on this project for the last 6 months. Team A has had 40% turnover. Team B has had 0% turnover.
Which team will have more trust with the business stakeholders and be able to collaborate more effectively? Which will have the depth of understanding to welcome changing requirements and integrate them cleanly into existing architecture? Which will trust each other enough to reflect openly and adjust behavior? And so on. Working at a sustainable pace is not the only driver for turnover, but it’s a big one.
Working sustainably also gives the team mental space to consider how things might be done differently, how things could be better. For example, it’s hard to even contemplate how you might refactor a codebase or pay down technical debt if you’re working long hours in a frenzy of building new features.
What is sustainable development?
You hear a lot these days about sustainable development in the context of climate change, where it’s often defined as “development which meets the needs of the present without compromising the ability of future generations to meet their own needs.”
I think we can adapt that into a definition for us in the software world as well. Sustainable development delivers the current value our stakeholders need without compromising the ability to deliver future value. In an ideal state, this means sustainable development is promoting the wellness of our team members and supporting their growth as well, fostering an environment where every project makes everyone better prepared for the next one.
We certainly strive for that type of sustainability at Simple Thread, and I love seeing it as part of the Agile Manifesto. It’s yet another reminder of how much they got right 20 years ago.
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
