Scanbuy

Growing Teams in a Startup Small LeSS Adoption

(by Alan Atlas)

Scanbuy, Inc., located in New York City, offers a QR code publishing product and code-scanning mobile apps. The publishing system is web-based and runs on a Java stack. It provides QR code publishing, tracking, distribution, and management functions, and analytics.

The Engineering department adopted Scrum in the small scale in mid-2011. By September, 2013 scaling was needed because of a management decision to significantly increase engineering capacity by outsourcing, along with continuing to recruit. The approach that was chosen was to create a separate but equal nearshore team that would act as an independent and complete Scrum team. All teams would work together using the LeSS framework.

Implementation of the nearshore team took nearly six months because it involved hiring the new team members one at a time. Initial training for the first two new team members was conducted at company HQ, and then they joined the existing Scrum team. Mentoring responsibility was largely assumed by one of the senior developers.

When the team had 4 people, it was spun off to be independent, having its own Scrum Master but working for the single Product Owner for the entire product, with a single Product Backlog. The model was imperfect in that the mentor also had to stay on the nearshore team to provide knowledge and senior technical leadership. The new team handled items related to the web-based QR code publishing product but not on the mobile apps. They also took responsibility for publishing system releases.

Other typical features of a LeSS implementation that were instituted included a common Spring Planning One, working from a multi-team Product Backlog, a common multi-team Sprint Review, use of a single build system with the teams (usually) practicing continuous integration, and the release of a common Potentially Shippable Product Increment each Sprint for the publishing system. All teams shared a common Definition of Done for the product.

The approach definitely gave us an organized and orderly approach to scaling and allowed us to inspect and adapt to respond to problems as they arose. We were able to scale our development and increase the overall net velocity of the entire organization as it grew. In hindsight, the biggest impediment we had was the unequal distribution of knowledge, with teams specializing and mentors having to span distributed teams.