I had a chance to sit down with Yoav Shapira of HubSpot recently to ask him about how HubSpot uses Scrum and how they organize their Agile development process. It was valuable and interesting — and he was kind enough to allow me to share a summary of our discussion.
Small, self-contained teams (3-4 people)
He says that one of the keys to successful agile development is to divide the work into smaller teams of 3-4 people — plus a dedicated, full-time QA resource (and Designer if needed) for each team. The QA person is dedicated to the team and participates in the overall Sprint Planning process. Features are then built by the team one at a time until they are complete with QA testing the code as soon as it is available.
One of the keys here is that the teams have a great deal of say in how they organize themselves and their work. They set their own Scrum time and divide work amongst themselves. They set their own rules for working from home or in the office. In the end, they take overall responsibility for delivery of the features in that Sprint.
Release code when features are done, not when the Sprint is over
Even though Sprints are only 2 weeks in length, the teams have the power to push their code as soon as they get QA sign-off. This has the effect of minimizing the impact of any given push to production as well as speeding the overall innovation rate. It also minimizes the overall testing required for any given push.
If features don’t get completed before the end of the Sprint, they get pushed into the next Sprint. Since the code will get pushed to production as soon as it’s ready, the impact of any given feature getting pushed of the next Sprint is minimal — the feature will likely just be delayed until a few days into the next Sprint and will be the first feature of the next Sprint that gets completed.
25% of your time for bugs
Bugs (unless they are good sized) aren’t part of the overall Sprint planning process. Instead, all developers are expected to spend about 25% of their time fixing defects. This keeps the Sprint planning process clean and makes sure the effort for fixing defects gets spread around. It also helps fill time for team members when they might be waiting for QA or some other resource.
Not ‘staging’ — ‘Beta!’
One innovation they’ve made that’s made their agile process much more effective is that they’ve created a second ‘production’ application they call ‘beta’. Their Beta application is literally a second application executing against the exact same database that their production application uses. This allows them to test their application against real production data with real users prior to pushing their features into their actual production app. (After the features have been tested and developed in ‘beta’, a new feature in a future sprint will be created to migrate the feature to ‘production’.)
This allows the goal of the Sprint to be ‘migrate this feature to beta’ and reduces the overall risk of negative impact on the production app. It also makes it simpler to ‘migrate continuously’.
Another interesting twist they’ve implemented is putting on a ‘Science Fair’-type presentation once a month at HubSpot so teams can show off what they’ve accomplished.
On the first Thursday of each month, each sprint team sets up a ‘presentation’ on the work they accomplished over the last month. They might have a demo of their new work, or a ‘posterboard’ presentation or whatever they think is the best way to explain what they’ve done.
The teams all get one minute of time (literally) to discuss what they’ve done and then they are available for a few hours to answer questions or give demos on the work they’ve done.
This makes it easier and more fun for people around the company to get to know what’s happening with their product. People can drop in any time during Science Fair and talk directly to the Sprint teams that are working on features that they’re interested in; and the teams can get more direct feedback from others on what they’ve done since they talk directly to individuals (rather than presenting to a large group).
HubSpot has implemented what seems to me to be a leading edge, innovative approach to Agile development. Their most common programming language is Java, so they’ve shown that Agile development does not equate to Ruby and Rails.
As a result, Yoav is able to manage a large number of developers, QA and Design staff with almost no middle management. Their organization is extremely flat.
More importantly, they’re able to push their innovation rate to the max. By pushing responsibility for implementation onto the sprint teams, they take ownership of getting work down and hitting their short-term targets aggressively.