Our goal is to build greatness – we believe that results from building, not talking. Moments we take away from actively improving our technology come at a high cost, so we continually critique and refine our process to ensure that it increases our productivity, not diminishes it.
Scrum
InsightSquared engineering operates the Scrum agile methodology with four teams using two week sprints; we begin on Thursday and end on Wednesday. Below is the outline of our process:
Standup (10 min)
Each Scrum team has a morning stand-up. Engineers quickly review what they did yesterday, what they will do today, and any issues that are blocking them. The conversation is loose but fast – if people get too sidetracked, the scrummaster asks for the topic to be held until after stand-up.
Stories
Engineers are welcome to take their pick of the sprint’s stories – the only rule is that you can hold only one story at a time (no hogging!). The stories themselves are defined broadly, and it is up to the engineer and the PM working together to define exactly what gets built. Our PMs act as experts in our customers’ needs, not as product design autocrats.
Code Releases
We’re a continuous deployment shop – code goes out many times every day. When an engineer has completed a story, s/he creates a pull request in GitHub to merge the story branch. Pull requests are distributed evenly so that each engineer will review, and be reviewed, by everyone else. After any necessary changes are made, the branch is merged. The code change is noticed by Jenkins, and after five minutes of automated testing, it receives a “blessed” tag and is ready for deployment. We don’t deploy automatically (yet!), but any engineer can trigger a deploy of the blessed branch. When the code is live, the story is marked as delivered, and it is up to the PM to review the result and either accept it or request changes.
Testing
We don’t practice Test Driven Development. There, we said it. Instead, we have built a broad, ever-expanding set of automated testing tools. These enable us to maintain the speed we cherish while gaining considerable safety and security. Our automated tests have very wide coverage across nearly a dozen different dimensions (reports, architectural layers, etc.), and we have another dozen planned – if you’re interested, keep your eyes open for a blog post on this topic someday, or encourage us to write it sooner!
First Day: Planning
The first day of the sprint is designed to plan great sprints and launch them on solid footing. No one is in meetings for more than 60 consecutive minutes, nor for more than a combined 2 hours. When we’re not in discussion, we’re not just sitting around, of course – we’re coding stories, chores or bugs, just like any other day.
Estimation (15 – 30 min)
Each Scrum team meets independently with its product manager (PM) to review new stories and assign a point value. At InsightSquared, story points are used *only* for planning how much work can fit into a sprint – we don’t track who does how many points. We also don’t assign points to bugs or chores – if a team spends more time on these, the velocity simply goes down.
Each story is briefly discussed to evaluate its complexity, followed by a poker-style estimation – the median time per story is one minute. Each person picks either 0, 1, 5, or 13, holds up fingers or a card, and consensus is reached. We’re not terribly concerned about the accuracy; we just want to get in the ballpark.
Planning
Once the PMs have their stories estimated, they spend the next hour or so planning their sprints. Although the four Scrum teams operate independently, there are often dependencies between them. The PMs deftly balance these needs with their own priorities, the story point distribution, and the bug load. Meanwhile, scrummasters plan chores to reduce technical debt and improve infrastructure. At the end, each team’s scrummaster and PM huddle to discuss their plans, tweak as necessary, and commit to the sprint.
Kick-Off (5 – 10 min)
For kick-off, the entire product team assembles. The PMs present how the stories in the sprint relate to our company-wide business goals. They then depart, allowing the engineering team to get down to business.
Tasking (0 – 30 min)
Immediately following kick-off, the Scrum teams remain to discuss implementation of their more involved stories. Engineers change team semi-frequently, so it may be that the expert in a certain piece of code is on another team. Team members weigh in on concerns, impacts, and steps, all of which become tasks in the story. Stories that require significant architecture or pose scaling or performance issues are white-boarded by the engineer and a senior architect when the story is begun. Once tasking has ended, the sprint is officially launched!
Mid-Sprint
Dev Lunch (1 hour)
Dev lunch is an optional lunch meeting during which the team can nerd out about any topic of our choosing. Our Chief Dev Lunch Officer (CDLO) creates a poll each week of a few different topics and presenters. Topics are chosen for popularity and intrigue, and they need not be related to InsightSquared at all.
Last Day: Wrap-Up
Sprint Review (10 – 15 min)
The sprint ends at 4pm sharp as the whole company comes together to grab a beer from the kegerator and learn about the new improvements to the product. Each team’s PM covers the high-level accomplishments and is required to explain the business value delivered – savage heckling is in store for the PM who fails to do so.
Science Fair (30 min)
Immediately after sprint review, the engineers take over to demonstrate. We lead with our most exciting stories, always drawing applause, occasionally accompanied by high-fives, hugs and dancing. But after the customer-facing features, we give a wink and a nod so the business folk may escape before get into geekier detail. Science fair is very casual; people are encouraged to interrupt, ask questions, and come and go as they please.
Post-Sprint
Retrospective (1 hour)
Although we never want to slow down, we have found it valuable to reflect on the previous sprint’s successes, failures and learnings. Once per sprint, the teams grab a lounge to have their retrospectives. The discussion is free-form, and the mood is casual, enjoyable, and educational. Our only rule is that everyone brings a topic – we want to hear from everyone, not just the most aggressive of us.
Just as InsightSquared engineering has already grown from two engineers to over a dozen full-timers, so does our process grow and mature. As long as we continue to hold fast to our core values – speed, synchronicity, productivity – we are confident that our process will be a help, not a hindrance.
