After attending a talk on Agile recently, myself and a couple of other Genius folks became the center of attention because we have implemented the Agile process quite successfully. Most of the interest seemed to be around our day-to-day process and logistics—something that seems to be glossed over in most discussions of Agile. What follows is a rundown of what each two week sprint looks like in Genius Engineering.
As part of the continuous agile process, we have a sizing meeting every week where our product owner gives us a quick overview of user stories that are further down the backlog. We look at enough material to last us 2-3 sprints and give the team a long term view of our direction. These meetings are valuable for keeping the team thinking ahead about what might be coming in the future in addition to giving the product owner feedback about what details the team will need to complete the stories.
Our sprints start on Monday and stretch for two weeks until Friday of the next week. The first day begins with sprint planning, where we choose what stories we are going to do for the next fortnight. Our product owner presents a list of user stories, in priority order, along with detailed acceptance criteria. The vast majority of the stories aren’t new—they were previously presented to the team at the aforementioned sizing meeting. We go through each story in the list, spending a few minutes on each one reviewing the story and acceptance criteria that were defined previously.
When the team has chosen enough stories to keep them busy for the entire sprint plus an extra stretch goal or two, we head back to the top of the list to commit on which stories we will do for the sprint. Usually, this involves choosing the stories from the prioritized list until we have accumulated enough story points to keep us busy for the whole sprint; most likely, a number right around our current velocity. Sometimes, however, a story is sized large enough that we don’t feel ready to tackle just yet, and we’ll skip over it, grabbing some smaller stories further down the list. Occasionally, the team also decides that there isn’t enough detail in the story, or there are too many questions about how the story will be implemented. In these cases, we will put an NMI (Need More Information) story into the sprint. NMIs usually boil down to a couple of meetings amongst those who have the most knowledge of what needs to be done (product owner, users) and how it will be done (experts in affected code areas or tools) to flesh out the story.
After sprint planning, we take a break and have lunch; long meetings are pretty taxing. After lunch, It’s time for task breakdown.
By committing to a story, the team is saying that they know how to complete it. If we know how to complete a story, then we ought to be able to synthesize (nearly) all of the tasks that will need to be performed to Achieve. For each story, we get everyone who might be involved in it—not just experts in the area—to gather around our task board. Those most familiar with the story lead the discussion about how the team should go about implementing the user story; someone else notes down each task onto a square Post-it note, and puts that in the to-do column on the board.
Astute observers will notice that I didn’t mention quality assurance throughout the entire planning process above. That is because at Genius, unlike a lot of other organizations, QA is part of the engineering team. Our QA engineers participate in all of our planning, from Meet & Greet to task breakdown. QA being involved in a story from the beginning gives a whole lot of insight into what customers expect and how they will use what is created.
Once the team has chosen stories and broken out all of the tasks, we begin the real work. Whenever we open a new story, the team leads get together to make sure we have enough resources to dedicate to working on it, and that we won’t be stretched too thin—we try to swarm on stories, so as to get each one through development as quickly as possible. It depends upon the nature of the stories, but we generally have one to two stories open for every four developers.
Day to Day
Every day of the sprint, we have a daily standup meeting that takes about 10 minutes. The team gets together around our scrum board and each person answers three questions:
- What have you done since last standup?
- What are you doing until next standup?
- Have you had any impediments?
We usually don’t actually ask the questions—everyone knows what to do—except as a reminder if someone forgot to answer one of them. The first question is usually answered by describing what tasks you have completed, other team members you have been working with, or impediments you have resolved for others. Looking ahead usually means telling the team what tasks you expect to complete over the next day, or at least the stories you will be involved in. Impediments are hopefully rare, and usually include accidental breakage caused by other team members or waiting on external information.
Stories begin with all of their tasks in the To Do column on our board; a developer picks up the task and moves it to In Progress while they work on it. When the developer has done what is necessary for the task, including writing unit tests to exercise any changed or newly added code, they move the task to Security Review. Since any missed encodings can lead to exploitable holes, we have another developer review the committed changeset for vulnerabilities. When everything is deemed OK, the task moves to Ready for QA. From there, one of our QA folks grabs the task and moves the task to In QA. QA validates that the task does what it should, fulfills the acceptance criteria that are applicable and writes automated Selenium tests to be added to our application test suite. Once all of the tasks for a story have made it to the Validated column, the story is done! Or at least mostly so.
The last thing that happens to a story is validation by the product owner. We put the large, story Post-it into the In QA column and let our product owner know that he needs to give it one final check. The product owner isn’t looking to do an exhaustive examination like QA does, but simply ensure that the user story has been implemented in a fashion that he deems appropriate. At the next scrum, the product owner tells us that the story has been validated, and the team resizes the story.
The sprint review is where the team shows off the results of their work for the sprint. We schedule ours at a time convenient for the entire company. We build this software for our own sales & marketing people to both use and sell, so we invite them to come so that we can give them a detailed look at new features we’ve implemented. To encourage attendance, someone often makes treats or we stop at Costco for a case of Mexican Coke and churros.
The very last part of our sprint is the retrospective. We gather the whole team in the conference room to discuss things that did and didn’t go well during the sprint. The retrospective happens in a fairly agile fashion—for the first 10 minutes, everyone comes up with issues, writing them on Post-it notes and placing them in similar groups on the wall. We spend about 5 minutes summarizing those groups and letting everyone vote for the two they think are the most important. The remainder of the time is used to discuss those issues in priority order based upon that voting. In the last 5 minutes of the meeting, we choose action items in the form of something awesome, a mystery, and lessons learned, assigning someone to act upon each of those throughout the next sprint.