Twelve months of agile startup product development ⅔ – squads and cycles

In case you missed it, read part 1: Bowtie’s desired mission and team culture first.

Here’s how we set things up at Bowtie to build towards our mission.

1. Small, nearly autonomous, cross-function teams; we just call them squads;
2. A lightweight six-weeks agile development cycle;
3. Goal-setting at the squad level, with a living Now-Next-Later roadmap.

Autonomous cross-function teams

When I joined Bowtie, our software team consisted of 8 engineers, 4 designers and 1 product manager. Everyone wore multiple hats. 2 engineers focused on infrastructure and developer operations, 1 designer focused on Webflow and Wordpress, and another designer focused on user research. The rest of the team worked on day-to-day software design and development.

Every 4-6 weeks, senior team members looked at a long list of business and user requests together, to decide what projects would be picked up in the next sprint.

Like most early-stage companies, everything on the to-do list has an urgent deadline, or is a burning fire that needs putting out, or represents a significant revenue opportunity that can’t be ignored. The backlog is a mile long.

When prolonged, the team will feel like they’re always on the back foot playing catch up. This is not a motivating or productive place to be for long.

When your goal is to launch an MVP by a specific date, it’s easy for people to figure out how to get things done. You have a target audience, a set of non-negotiable bare minimum features, a basic launch plan, and a launch date. The goal is relatively focused.

But the day after the MVP is launched, things become more complicated. Users run into problems, request new features, and bring their friends to try your product. Internally, leaders and teammates have different opinions about what’s important to fix and ship. There’s never enough time for planning, for development, for quality assurance, for doing things by the book.

In this environment, the team is constantly pulled by competing and often opposing forces. It’s hard to get off the back foot.

Getting the team off the back foot is crucial for a mission-driven company.

But getting the team off the back foot is crucial for a mission-driven company. Only by keeping an eye on where it should be heading, can the team take control and build towards its mission.

Our solution was to give the software team more ownership. Specifically, more ownership over what the solutions we designed and built looked like. We would give them more influence over how to design solutions, and how to implement them.

Why? We had hired and continued striving to hire great people. Builders who were passionate about problem solving and serving the user well. Our big bet was that the whole team would move faster if we just trusted them to figure out how to solve the problems that needed to be solved. We decided to separate decisions on what problems to solve, from decisions on how to solve them.

We split the software team into 3 working groups, called squads. Inside squads, we increased squad members’ influence over what solutions would be designed and developed. At the same time, we encouraged collaboration with stakeholders outside the squad to determine what problems to solve and when to solve them.

In other words, if you were in a squad, you would influence what was built, and how it was built. If you weren’t in a squad, you could collaborate with squad members to influence what problems needed to be solved first.

Each squad would be setup with members who had all the necessary functional skills to achieve its goals. For example, if a squad was focused on building solutions related to our customer-facing web app, it would include designers and engineers familiar with that part of the product and related backend services. If a squad was focused on solutions related to marketing webpages, it might have a greater share of no-code designers and developers, working closely with marketers and a/b testing analysts.

With all the needed skills in place, a squad is now able to develop solutions in relative autonomy. Day to day, most teamwork and collaboration happens among squad members. When additional domain expertise, requests for support, and feedback was needed, squad members can then lean on stakeholders for support. For example, an engineer working on a claims feature who isn’t sure about how authentication works, will reach out to the go-to authentication expert for support and advice, but ultimately they will try to solve the problem themselves.

To keep collaboration quick, a squad need not be big. Something like Amazon’s two-pizza teams will do.

When we started running squads, several of the more experienced team members had to sit in more than one squad at a time. However, people thought this arrangement was unsustainable. Frequent context switching between squads would prove to be too costly.

In the long term, squads members will likely belong to only a single squad at a time, with the exception for exceptional teammates with unique domain expertise and above average productivity.

We’ll cover how we split up squads in part 3 when we cover goal-setting. In the meantime, Bowtie’s recruitment went into overdrive. Gradually, more engineers succeeded in passing our stringent recruitment process. The team started to grow.

Agile development without rigid frameworks

“The best architectures, requirements, and designs emerge from self-organising teams.” – principle eleven of the twelve principles of agile software development.

The best architectures, requirements, and designs emerge from self-organising teams.

I’m an agile minimalist. Agile is the style that I prefer, and I like the cherry-pick its best features to solve problems, without being too dogmatic about it. This has worked well for me throughout my software career.

Early-stage product management consists of coordinating actions across different teams towards a common product goal, given constrained resources and shifting priorities. When a company is first started, this is the founder’s responsibility. Later, oftentimes the CEO becomes too busy and brings on someone to take care of this.

This was the role that I found myself in joining Bowtie.

Earlier, we mentioned how we attempted to give squads autonomy over solutions. Within each squad’s scope, there was maximum freedom. Squad members were free to establish their own rituals. Some squads collaborated synchronously once a week, or several times a week, or never synchronously unless collaborating with outside stakeholders. They were free to determine how they wanted to work, what tools to use, and to what degree to follow established practices and templates.

But not everything was up to squad members to decide.

As a product leader, one of my responsibilities was setting up sandboxes for team members to play in. Each squad is a sandbox. Inside the sandbox, all the resources squad members needed (the sand, shovels, buckets) would be made available. But there would be rules to how one entered or exited their sandbox, and how sandboxes interacted with one another.

We adapted several approaches from Shape Up to Bowtie and our squads. Put together by Basecamp, their approach felt opinionated enough to be useful, but flexible and modular enough to customise. Unlike other common agile methods, we could avoid training the team in various strictly defined roles and rituals.

Here’s what we borrowed from Shape Up, and combined with our squads:

1. Six-week development cycles, two-week cooldowns;
2. Making bets, not backlogs;
3. Exercise shaping opportunities for betting.

Six-week cycles, two-week cooldowns

Our experience with six-week cycles matches what Basecamp published online. Everything from solution definition, scoping, user research, prototyping, journey design, interface design, backend development, frontend development, testing to quality assurance - it all happens within one cycle.

This is why it’s important for squads to be relatively cross-function and autonomous. If they don’t have all the needed skillsets, things won’t move quickly.

Usually, squad members take the first 1 to 2 weeks to fully understand the projects that have been picked for the ongoing cycle. We trust squad members to determine what the solution direction is, how much effort is needed, and most importantly what needs to be cut from the scope.

It is common for projects to start off with several solution ideas, matching several prioritised problems that need to be solved. These solution ideas get narrowed down and prioritised. The prioritised ones are those that the squad believes will have a high enough impact within an achievable amount of time and effort. Squad members will make time to verify assumptions and de-risk solution ideas with outside stakeholders if needed. This is the moment squad members start to think through functional and technical requirements in detail. They also proactively complete needed internal communication with marketing, customer service or compliance within the cycle.

Different projects have different tasks, in different order. For example, for a new insurance product launch, a cycle may start by backend engineers collaborating with actuaries on setting up pricing and benefit items, while designers work with marketers to mock new content for landing pages. Or for a new user facing feature, designers may kick off a cycle by prototyping potential solutions for a quick round of usability testing, with a frontend engineer discussing what can or cannot be done based on their best estimate on effort.

The point is, instead of enforcing a strict order of doing things, we let squad members project manage themselves with the minimum amount of processes or checklists. Time and effort estimates are considered but don’t drive decisions.

We let squad members project manage themselves with the minimum amount of processes or checklists. Time and effort estimates are considered but don’t drive decisions.

‍

The most important thing we enforce with cycles is a fixed start date and end date. Not everyone is able to make it by the end of 6 weeks and ship, but those who do get 2 weeks of cooldown when they get to work on whatever they think contributes to squad or team goals. In our time running six-week cycles, I estimate that around half of projects were shipped by the end of six weeks, a quarter were shipped during cooldown, and the rest had a launch that overflowed into the next cycle.

Most of the overflow stemmed from unexpected work, and unexpected time waiting for feedback or external approval. Given the goal of shipping fully functioning features by the end of each cycle, this situation is not ideal. However, I think that so far the benefits of giving squad members maximum project management freedom, has outweighed the benefits of micro-managing what happens each week during the six-week cycle.

At the end of each cycle, the whole team meets in a retrospective, discussing and enacting improvements for the next cycle.

So far, we’ve covered our decision to form small autonomous cross-function teams called squads. And we started to explore how we implemented a lightweight agile development process with six-week cycles. But that’s not all.

In part 3, we will explore how everything else ties together, with examples of what we shipped over a twelve months period.

Bowtie is hiring builders to engineering, design, and all roles. It is a hybrid remote company, with teammates distributed in several time-zones. It operates an excellent café and clinic in downtown Hong Kong. Reach out to Sara Choi or I.