The Saleswhale approach to agile software development

What is agile in a nutshell, I asked James.

James Keys is one of our back end engineers and also Saleswhale’s agile coach. If there’s anyone who would know how to explain a big concept like agile software development in a concise and simple way, it’s James.

“To me, agile is about accepting that you can’t predict the future. Being flexible and adaptable to changes.”

“Other key characteristics of agile are: a focus on customers, plenty of communication, and cross-functional collaboration.”

Pre-Saleswhale, James worked at a large company with tens of thousands of people. That’s where he learned agile in and out: how to make it work, the pitfalls to avoid, etc.

James Keys, our agile coach

“Probably my biggest learning was that agile should not be limited to the engineering team. Agile was not a company-wide practice at my previous company, so we engineers were like an island of agile. I feel that to get the most benefits from agile, other teams like product and design need to be agile too.”

James took all those learnings with him to Saleswhale and devised an agile process that works for a fast-growing startup. A process in which our engineers, product managers, and designers collaborate to serve customers well.

In this interview, James shares more about how we do agile at Saleswhale, why we implemented it in the first place, and how it has benefited us:

1. Why Saleswhale went agile
2. Agile delivery, the Saleswhale way
3. Developing a stronger agile culture at Saleswhale

Part 1: Why Saleswhale went agile

YY: Which agile methodologies do we use at Saleswhale?

James: We engineers use scrum on a daily basis. We don’t follow it strictly, though.

When it comes to working cross-functionally, we use a version of the Spotify model. Under this model, there are different teams working on different features. Each team consists of members with different skill sets. The teams use scrum, but again, we don’t follow scrum super closely. The parts of scrum that we do use include daily standups, sprint planning, and retrospectives.

YY: Before we adopted agile, what was the software development process at Saleswhale like?

James: We used a waterfall approach to develop new product features.

The process started with Venus (VP of Product) speaking to our customers and identifying pain points. Next, she would discuss her findings with Ethan. Then Ethan would plan the required technical work. After that, Venus and Andrew (product designer) would collaborate on the feature design. Based on their specifications and lo-fi mockups, the engineers would build the features. Finally, Venus and Andrew would perform User Acceptance Testing (UAT) on the result.

It took about three to six months to deliver a new feature, from start to end.

The Saleswhale engineering team in September 2018

YY: But this old way of working didn’t work anymore, so we had to go agile?

James: Yes. Over time, our engineering resources grew strained.

Back then, Vincent was the only front end engineer. Whenever he was too busy, we had to pause some projects until he was ready. But sometimes, by the time Vincent is done, our backend engineers would be preoccupied themselves. Also, Venus’ and Ethan’s time became a bottleneck as we scaled up the engineering team.

Progress was slow and small. The other departments grew frustrated with us. Because of my previous experiences with agile, I was tasked with implementing agile at Saleswhale. In January 2019, we transited from the waterfall approach to a more agile approach.

Part 2: Agile delivery, the Saleswhale way

YY: Feature teams are a key component of the way we do agile here at Saleswhale. Could you explain what a feature team is?

James: A feature team is a cross-functional team that consists of a product designer, a front end engineer, and a back end engineer. Each team is in charge of delivering a specific product feature. When we have all the roles necessary to deliver a feature in one team, we don’t have to wait for engineering resources to become available. Work can proceed without delay.

One of our feature teams at work

As of June 2019, there are two feature teams working on two different features. Both teams are autonomous. They are not completely siloed, in that they have no idea what the other team is working on. But there is no need for one team to update the other every day on the details of their progress. We don’t want to create any dependencies that might hinder the development of features.

YY: How does a feature team work, from the start of the product development process to the end?

James: The process begins with a problem memo written by the product managers. This memo defines the problem that our customers face, based on customer feedback. It also prioritizes the things that need to be done to solve the problem. We try to give the feature teams as much context as possible. Then they will be able to make better decisions and operate autonomously.

Next, we do a high-level user story mapping that involves the entire feature team. This is followed by a design sprint. The whole team comes together to brainstorm and come up with a proposed solution, or a prototype. (At this point, we should test the prototype with customers and iterate on the design. We’re in the process of implementing that at the moment.) Then, we’ll revisit the User Story Map from before and flesh it out with more detail. We also break down and identify all the tasks that have to be done.

Development can then begin. At Saleswhale, our teams work in a series of one week sprints. Within each sprint, there are several activities. Daily updates, feature development work, testing what has been built so far, and a retro. A retro involves looking back over the week to identify what went well and what needs improvement. The next week, another sprint begins.

Sprint planning at Saleswhale

We normally have about five or six sprints, each with a deliverable increment. For some sprints, the deliverable will go into staging, or in production behind a feature flag. This means that engineers can test features by hiding parts of the app from users during run time. Once the feature has a minimum level of functionality we’ll go live with an external release.

If all goes well, after one to three external releases the product feature will be officially launched and we’ll move on to the next. There would be a final big retro at the end of the process, to review and wrap everything up.

Nicholas, one of our backend engineers, during a retro session

YY: Is there anything unique about the way we do agile here at Saleswhale?

James: We can move fast here at Saleswhale.

Our feature teams are small; they consist of at least three people. Each team works in one week sprints, in which members design, build, and test one deliverable. Our teams can also get meetings over and done with in as short as 15 minutes. So, even though it sounds like there are many steps involved in our agile delivery, the whole process moves fast. We make a lot of small but regular deliveries.

In contrast, feature teams at my previous company consist of about ten people, and sprints last about two weeks. With big teams, there’s also a greater likelihood of disagreement.

Part 3: Developing a stronger agile culture at Saleswhale

YY: It’s been about five months since we adopted an agile approach to software development. What are the biggest benefits we’ve gotten out of it so far?

James: Thanks to our regular and swift deliveries, the engineering team has won back the trust of the customer success and sales teams. We’ve proven that we can deliver good quality work within tight deadlines. It feels like we are making real progress with the product.

We’ve gotten some good feedback from our customers too. They like the dashboard we built and released this year. Customers are also happy to be consulted when it comes to developing new product features.

Our customers love the new dashboard, which was launched earlier this year

YY: What do you think can be improved about the way we do agile here at Saleswhale?

James: Right now, each feature team follows a scrum-based approach. Perhaps in the future, the teams can have the freedom to use other agile methods, if they want to.

It would be great if we could implement agile upstream as well. Specifically, we could be more agile in the way we discover problems and solutions. We’re working towards a more proactive problem solving approach now. Our product managers & designers plan to speak to customers and do more user research. The software development team will also be involved in identifying customer pain points alongside the product team.

We want to validate our proposed solution with the customer as much as possible, before building it. That way, we can maximize the amount of work not done.

YY: Hang on, did you say “maximize the amount of work not done”? As opposed to maximizing the amount of work done?

James: Yep, maximize the amount of work not done! It’s about being efficient: how can we minimize the amount of work needed to solve a problem?

Implementing agile upstream at the problem and solution discovery phase is one example. Here’s another. I’m Saleswhale’s agile coach, so the team normally turns to me for advice on all things agile. But that makes me a blocker when it comes to agile delivery, because things might slow down if I am not around to help. My long term goal is to empower the product managers and team leads so that they can apply agile on their own.

YY: Any final comments about the future of agile in Saleswhale?

James (engineer), Asher (product manager), and Nicholas (engineer) having a discussion. At Saleswhale, our engineers, product managers, and designers work closely.

James: Our team is growing bigger and bigger. I hope that we don’t develop an island of agile like what happened at my previous company. I’d like the entire company to come on board with agile, too. It’s a big challenge, and these things have to come from the top. If your CEO has a shopping list of features they want delivered in the next 12 months, then it doesn’t matter how much work it is, or what the user research says, you’re delivering those features.

Luckily, the founding team has been very supportive and seem to be totally on board with agile, so I’m optimistic for the future.

Saleswhale is growing fast and is actively hiring! Interested in joining us? Check out our latest job openings.