How We Work
Kevin Smith
VP of Engineering
I’m often asked if we’re “Agile” at AxisCare. Yes, but probably not how they mean.
When most people say Agile these days, they mean Scrum. It’s by far the dominant Agile methodology, but I’ve found it often devolves into mindless ceremonies, two-week death marches, and ticking boxes instead of building innovative products. Success is rarely defined before work begins, and engineering rigor is barely a consideration. Why so much of the software development world has accepted this as the norm is beyond me, but thankfully it’s not the only way to be “Agile”.
Tradeoffs, Not a Rigid Process
Give the Agile Manifesto a fresh look if you haven’t read through it in a while. It may surprise you. It’s not a defined process. It’s just a set of tradeoffs—a worldview declaring some ways of developing software more worthwhile than others. The underlying principles make it clear that the heart of Agile is fast feedback at all stages of software development, and I think the authors are right on the money. Ironically, Scrum tends to fall flat because teams are often incentivized to prize the very things the Agile Manifesto de-emphasizes.
Every engineering team should find what works best for them, not become mindless drones to a prescribed process. Whatever our specific practices at any given time, we’re always aiming for…
- Business and technical minds who work hand in hand
- Autonomous teams who regularly ship features that help our customers make major progress in their business
- A codebase that is easy to change
- Team members to feel challenged, celebrate accomplishments frequently, and grow together in technical excellence
- A sustainable pace so we all want to stick around
Here’s what that looks like for us right now.
Feature Work
When it comes to building features, we’ve taken the basic truths and many of the practices of Basecamp’s Shape Up and tailored them to fit our team for the kind of work we do. If you’re unfamiliar with Shape Up, check out this great video overview on the basics from author Ryan Singer.
Innovative products are the result of outside-in thinking and deep integration across product, engineering, and design. Our own product development starts with an investigation into the everyday struggles our customers face. Once we understand a problem we think we could solve, we’ll workshop potential solutions with people from both the business and technical sides. Just rough ideas, nothing concrete.
We start with a time budget and work out a solution from there. What’s our appetite for a solution here? How much time are we willing to invest? A few days? A few months? What does a three-week solution to this problem look like?
We don’t design a complete project in our heads and then ask “How long will this take?” Who could know!? When a project scope is fixed, it’ll take as long as it takes. That’s why we start from the other end. Singer refers to this as “fixed time, variable scope”.
Shaping
We’ll then shape the project during highly collaborative sessions involving product leaders, designers, engineering leaders, and our experts from QA. A nicely shaped project is rough, solved, and bounded. There’s no prescription for how to build it—we trust the expertise of our engineers for implementation—but the main elements are included, success is clearly defined, and potential time bombs have been dealt with. And most importantly, it’s clear which rabbit holes to avoid and how much time to spend on the project.
We have not built the project on paper. We haven’t done all the work upfront. We’ve just given it enough definition to be confident that we’re ready to move into the building phase. It’s still a bet, but we have every reason to believe it’ll succeed.
When it comes to project assignments for the teams, there’s a lot of back and forth between product and engineering leaders to figure out what makes sense. Every cycle is unique. A team may have a lot of people out on PTO, we may have a new hire coming on board, or the cycle might fall over the holidays. The projects themselves affect each other. Is it one big project for the team or several they’ll need to juggle? Are they all in one area of the codebase? Is the team entirely unfamiliar with the part of the business this one affects? Is there new tech involved? Are there unknowns around a third-party integration?
At the end of the day, here’s the bet that we’re making: we’re willing to spend this cycle for this team to accomplish these projects, and we think it’s reasonable to ship them by the end of the cycle. It’s about as granular as that bet can get. No sense in pretending capacity planning can be automated or get any finer-grained. These are tough tradeoffs that simply require the judgment of product and engineering experts who are intimately familiar with their teams’ capabilities.
Building
Our engineering teams build these projects in four-week cycles. At the start of each cycle, we’ll assign projects to each team. They’re responsible for shipping complete projects by the end of the cycle, so handing over the full assignment at the start allows the teams to forecast and adjust as they go.
One of the reasons I love working in a fixed time, variable scope environment is that you know from the beginning how much time you have. That lets you keep quality high, proceed like a professional, and cut scope where necessary to ship on time. High-performing teams need that autonomy, and constantly intervening with changing expectations would destroy the team’s ability to manage their own time. It’s critically important to protect the teams from outside demands during the cycle. (More on how we do that later.)
That’s a sea change from the typical workflow among software companies: build exactly this spec, as fast as possible, and cut quality to “save” time.
The teams take on ownership at this point, and since their managers were an integral part of the shaping process, there’s strong continuity in project knowledge as we move into the build cycle. The teams build proofs-of-concept, iterate quickly, get internal feedback from customer-facing teams, ship in small slices, and wrap it up by the end of the cycle. They’re highly collaborative, and they’re getting frequent insight from each other through architectural discussions, pair programming, code review, and QA all along the way.
We’re looking to get internal, external, and systems feedback early and often so that course corrections are small and a normal part of the flow, not something major that thrashes the team at the end. The plan we started with isn’t holy writ, but it would’ve been foolish to start without one. As Eisenhower famously said, “Plans are worthless, but planning is everything.”
Finish Well and Reset
Between cycles, we have a cool-down week. That gives us time to respond to any emerging concerns from a recent release, make performance improvements, prep for the upcoming cycle, knock out some small tasks and bugs, etc. It’s also a great time for an engineer to make improvements to something in the codebase that’s been bothering them. (I recommend engineers keep a wish list of problems and dev quality of life improvements that they want to address when they have the time.)
Any number of things might come up during a cycle that could wait a few weeks, so we’ll save those for cool-down. This is one small way we protect the teams’ build cycles. And it’s a nice change of pace before we start up another one.
Reactive Work and Other Things
What about everything else? The many things that are too small, too urgent, or too reactive to schedule as a cycle project. Or helping teammates outside Engineering. Or just dealing with the unexpected in general. How do we handle that?
During each build cycle, one engineer from each team steps away from feature work and into a rotating role that we call the Free Agent. They’re responsible for tackling exactly the sort of work described above. They work off a kanban board and stay light on their feet by limiting the number of things they have in flight at any given time.
The Free Agent role protects our engineering teams from distraction during the build cycle and gives us a way to lend a hand when someone outside Engineering needs our help. Unexpected things are always going to come up, and if we didn’t have some spare capacity we’d have to yank our teams off cycle projects to deal with it. The Free Agent gives us the confidence to assign cycle projects and say, “This is all you’ll have for the next four weeks. Have at it!”
In It for the Long Haul
You’ve no doubt read stories of how this or that tech company operates and thought Wow, they cracked it, we should be doing that! only to find out the company was publishing… shall we say an “aspirational” account of their inner workings. (Looking right atcha, Spotify.)
Here’s the thing: this is actually how we work. It’s the result of many iterations and collaboration across the whole team to find better ways of working, and it’s an ongoing project.
Now that’s not to say this is The One True Way that every team should adopt. This works for us because this works with the team we have now, in the business context we’re in now, with the tech stack we have now, etc. We’re always learning, always doing bigger things, and always on the lookout for ways to make this an even better place to work.
We’re blessed to work on a product that helps real people in the real world. Our work helps seniors age with dignity in their own homes, and everyone involved is better off—from the agencies, to the caregivers, to their clients.
On the inside, we foster this high-performing engineering team by hiring the right people, giving them the autonomy they need to do great things, and coaching them toward mastery. We prize technical excellence, and we’re deeply invested in growing junior and mid-level engineers into seniors and seniors into staff engineers or managers and beyond. If our people stick around for the long haul because this is the best place they’ve ever worked and they’re deeply satisfied with their accomplishments, I’ll count that a major success.
We are uncovering better ways of developing software by doing it and helping others do it.
Hear, hear!