Today, we're launching a short blog series on the development process at Netmail. We'll start by introducing our R&D process, then tell you all about our recent Dev Days.
I have always believed that the main asset of a software company is not the software itself, but the people who develop the software for the client. Of course, the Development Team is important in this process, but we don’t talk a lot about them. Developers are weird people. We find a place at the back of the office, build a big wall, and sit behind it...
You don’t want us to communicate too much with the outside world because the language they speak is incomprehensible to the rest of human race. So let me take this opportunity to open the window and explain a bit about what’s going on behind this wall at Netmail.
A few years ago, we made the move from a more-waterfall approach to Agile methodology. We decided to go with a Scrum-like development process. This all starts with collecting the requirements. The requirement list is populated with change requests coming from our clients outside the organization or ideas from inside. Each requirement is weighted periodically with points that determine its complexity. Then the Product Management Team works on the functional specifications, screen mock-ups and then prototypes the most important ones. The functional specs are then validated by either our Professional Services Team, the Netmail User Board or directly with the client requesting the feature.
At the beginning of a release, a first pass is done to evaluate which requirements should be included in the cycle. Each requirement is associated with a user story. The user stories are then transferred to the Development Team for the technical design phase. This is what we call a design sprint. At this stage, developers start to write technical specifications and perform peer reviews of the design. Meetings are scheduled to validate the specs and make sure everybody is in agreement on the chosen design. The user story is then split into tasks and each task evaluated.
The evaluated tasks are then associated to a tentative sprint. Defects that were pushed from previous releases are also associated to the tentative sprint and a generic evaluation is given to most of these. Sprints are small iterations of development that deliver benefits to the client. At Netmail, depending on the iteration, sprints typically last from 2 to 4 weeks.
A sprint planning session including the entire team is held to distribute the tasks and defects between the developers. At this point, we also determine if more than one sprint will be necessary to complete the release and push whatever does not fit into the first sprint to a second one. The end of this meeting results in the kick-off of the development of the new release.
Stay tuned for Dev Days at Netmail - Part 2!