Are we agile?
Samuel Roeca, Head of Engineering
Published January 15, 2023
I'm standing in a circle of new acquaintances at a wedding, making conversation with a finely-suited friend of someone's uncle. The conversation inevitably trends toward "what we do", and he learns that I'm involved with Software Engineering. Smiling knowingly, he asks a familiar question: "Are you guys agile? Kanban, Scrum, you know? My niece works in tech and was telling me about sprints, you should meet her!" Since this question contains as much narrative as it does inquiry, I give my typical response: "Absolutely, we always develop with change in mind! Anyway, please tell me more about your niece?" This response references agile while iterating the conversation away from technical details. Others in the circle relax as the conversation course-corrects, but I become distracted by how difficult that question was to answer. I believe that the engineering team at Kepler is agile, but how do I even begin explaining what I mean by that? And that's when I realized... this is a great topic for blog post!
We are agile
On its surface, "Are you agile" is an easy question to answer. Interpreted simply, it asks whether we operate according to the agile project management philosophy. Its main text is so short, I'll include it here in full:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Individuals and interactions
In the main, our features and products are designed by small, self-regulating teams consisting of one Product Manager, a primary developer, and a code / architecture reviewer. These numbers may vary based on size and complexity of the project. We leave decisions about how these teams operate up to the teams themselves.
We only develop formal processes and tooling after experience shows that we are hurt by their absence. For example, we now have a formal project categorization process because we repeatedly had mismatched expectations between relevant parties about how much effort a particular task might take. Now, we have unified expectations through our formal designation of a piece of work as a Proof of Concept, a Prototype, a Pilot, or Production.
Similarly, a long time ago, tracking our work resulted in lots of clutter and mismatched expectations. We solved this for ourselves by managing our work in Shortcut and organizing weekly backlog meetings where we can visualize all our work. This particular way of managing work is called Kanban, but we don't strictly adhere to any/all of its tenets. We just use the parts of the Kanban process that help us focus on Individuals and interactions.
Working software
Our continuous delivery setup means that individual new features can be developed locally, automatically tested on testing server, deployed to staging for final approval, then delivered to users. Most software that we write is deployed shortly after writing, testing, and QA.
Custom collaboration
We rarely develop new user-facing software without frequent interactions with our end users. We're lucky because on end users almost all work at Kepler, which makes them a captive audience, but agile doesn't always need to be difficult!
Responding to change
New developers at Kepler must learn to quickly touch type. We require this, in part, because we use terminal-driven tooling that requires heavy use of the keyboard. The larger reason for all of this is to make everyone on the team as resilient to change as possible. As authors of software, our ability to type quickly (combined with code navigation tooling, like the Language Server Protocol) literally makes it easier for us to respond to change. We respond to this change by refactoring our production code based on what is learned with end users and by testing out entirely new proof-of-concept products on the side.
We are not our methodologies
Scrum, Kanban, and other process du jour methodologies are just that: methodologies. We are not our methodologies. We are Kepler Engineering: an agile team that philosophically strives toward practical, playful productivity. After thinking all this through, my original answer wasn't so bad. The next time I'm asked any form of the question "is your team agile?", I'll simply respond "Yep, we're some agile cats".
