Agile is often a catch-all term that almost all companies use these days to describe their development practices, so it should be no surprise that here at Cherre we also call ourselves agile. As an agile coach, it’s important that I clarify what that actually means for Cherre and how we work.

Sure, you’ll hear the standard agile words here: standups, sprints, and retrospectives, for example. But what do they mean? How does that manifest in our day-to-day routine?

Let’s start with our team structures and how we’ve continued to iterate on our approach. As Cherre has grown from a handful of engineers to 25+ and growing, we’ve had to regularly evaluate the way we organize our teams and our work. Currently, we’re structured as five cross-functional teams, each with its own set of quarterly objectives and roadmap. 

Now cross-functional doesn’t mean that every team includes every discipline; instead, we’ve looked at our product and business objectives and shaped teams around those goals. Our front-end heavy products tend to have a few more front-end engineers, our data pipeline products tend to have a few more data engineers, etc. Essentially we want to equip each team with the skills necessary so that they may be autonomous, independent, and capable of delivering against their business goals. By empowering the teams in this way we can hold them accountable — not for delivering some output of features, but more so for helping achieve particular desirable outcomes. 

All of our teams are also empowered to determine what’s going to work best for them. We start with the principles of the Agile Manifesto for Software Development and, more often than not, use Scrum as a starting point for figuring out how to put those principles into practice. 

The teams figure out what sprint cadence works best for them; most of our teams have settled on two-week sprints for now. They own their sprint schedules and create working agreements within the team. And finally, we trust the teams to name themselves. 

During our sprint retrospectives and through frank and honest communication, we tweak our processes and practices over time. The way one team does their daily standup doesn’t need to match the way another team does theirs. Each team is a group of individuals facing unique problems and situations around their own products, and they need the flexibility and the power to change the way they work to maximize their abilities. 

This also means that teams can, and will, experiment with other things depending on the nature of their products and objectives — perhaps Kanban, or Scrumban, or some other alternative will best serve them. Much like with our approach to product development, we encourage experimentation with the practices; nothing we do has to be set in stone, and we regularly encourage trying something for a sprint or two to see if it works better. If it does, we keep it; if it doesn’t, then we’ll try something else. 

Agile is, at the end of the day, about being able to adapt to change and to deliver value regularly and frequently to our customers. There is no perfect way to do agile, so we strive instead to be agile in our approach. 

Dan Alcalde, Agile Coach

• Tagged as:
• engineering