Nimble Rabbit (aka Lapin Agile) is our software development process / guideline we will follow for our development efforts including NTOSpider.
History
In 2009, Dan Kuykendall and the team at NT OBJECTives, Inc decided to make slight adjustments to their product development. At the time, the team would struggle to put releases out in a timely fashion. The team was creating good software and communicated fairly well and simply needed a bit of improvement to the process that would help sync up tasks to create stability windows in which a stable build could be generated with a reasonably predictable set of new features.
The innovation of the product is not driven purely by a design team, but rather started by the design team with customer input and then adjusted based on developer feedback. The developers are also encouraged to innovate during the daily development as issues are found while reviewing code needed to make their changes. This iterative development cycle allows and encourages developers to also be innovators.
Characteristics
Nimble Rabbit is a flexible development process/framework with a set of practices and overlapping roles that are intended to help define what we do well and the solutions to improve our process. Nimble Rabbit is also specifically designed to work well in a telecommuting/distributed environment. It also avoids many of the false assumptions and traps of existing Agile frameworks such as Scrum.
The project is run by a “Freddy”, which takes its tasks from the decisions of the “Picasso Group”. The Picasso Group is comprised of management, research, the engineers as well as customers.
During each “Hop”, typically a two-to-four week period (with the length being decided by the team), there is the intention of having a releasable build. During the entire Hop, the Trouton Group will be performing tests against the daily builds, and ramp up stability testing efforts in earnest toward the end of the Hop.
If during a Hop a developer finds an issue in the code while reviewing code needed to make their changes, the issues are discussed briefly during the “Morning Checkup” or a follow up meeting and are either “Bunny Eared” for later, or considered “Cecal” which gets done right away.
Roles
The roles in Nimble Rabbit are intended to overlap in order to foster shared goals.
- Freddy: The Project Manager. Runs the project and is responsible for the outcome.
- Picasso Group: Research team that finds new features that can be added and comes up with possible design options.
- Gaston Group: Customers and partners chosen to participate with feature requests and testing of new builds at the end of each Hop.
- Einstein Group: The software engineers/developers who actually build the stuff.
- Trouton Group: The QA team who make sure things work as expected.
- Schmendiman Group: Handles determining the feature sets for each Hop. Each of the listed groups are allowed to participate in the Schmendiman Group and its meetings.
Meetings
- Morning Checkup: A daily meeting limited to 15 minutes. Each member of the Hop gives a brief account of the previous day’s activity, goals for the current day, and any blocking issues.
- Schmendiman Strategy Session: The Schmendiman Group works out the general plan of features for the next Hop.
- Road to Montmartre: The meeting at the beginning of each Hop in which the Einstein and Picasso Groups meet with the Freddy. Ideas for the next Hop are debated and decided upon, then tasks are assigned so everyone can finish at the end of the Hop. The group has lunch together afterward.
- Montmartre Retrospective: The meeting at the end of each Hop to review how it went and what was learned. Completed and incomplete tasks are compiled for the Trouton Group. Lunch follows.
Terminology
- Hop: The 2–4 week development cycle. At the end of a Hop all developers must have their latest working code checked in and ready for the Trouton Group to run full testing.
- Pellets: More commonly called bugs. These are problems in the code that cause problems.
- Cecal: Bugs found in the code during a Hop that are decided to be worth fixing immediately (re-digested into the Hop).
- Pocket Builds: Whenever a developer is making significant changes to existing code that has the opportunity to cause major stability issues, they must check in their code into a properly named branch. The build generator will be able to generate the Pocket Build for the Trouton Group to run separate stability testing of that build.
History of the naming scheme
The naming scheme came from a group discussion about a fun play on the “Agile” development process and the “Picasso at the Lapin Agile” play by Steve Martin. Using this play on words began the process of naming the groups, steps and organization. The play is a fun little debate between Einstein and Picasso about the value of their genius and talents. The cast was used for naming the groups and the little guest appearance from Elvis Presley (The Visitor) was used for naming the daily morning conference calls.
Lapin Agile means Nimble Rabbit, so the “Rabbit” part inspires the naming of the process steps, such as Hop, Pellets (rabbit poop, alternate name for bugs) and the Cecal (the rabbit poop that they re-digest as part of the digestion process).
Since the developers are the Einstein group, the QA team gets to be named after Frederick Trouton, who was one of the early experimenters that confirmed parts of the Theory of Relativity. The big meetings are named after the location that the play takes place in.
The name “Pocket Builds” does not derive from the play. It was made up long ago by Matthew Cohen to refer to custom builds the developers would provide him when he was running the QA department.