Product development – A Closer look into the kitchen

Over the last year, I’ve been working on a large CRM solution at CRM Partners. A solution meant to be sold as a product. At this moment we are working through the last bugs and requests¬†before we can ship the product.

The last year, I learned that product development is a total different game compared to project development (which used to be my world).


Project development is focused on writing the minimal amount of code and doing the minimal amount of implementation to get the job done.

Product development on the other hand is much more detailed than project development. You have to take into account that your product is going to be used by all kinds of users in all kinds of organizations.
This has a serious impact on the code you write and the testing that has to be done. The code has to be rock solid.

As any software development effort, a product development project is runned the same way as a normal project. In our case we chose to develop the product using SCRUM. SCRUM is an agile software development method, in which functionality is built in small iterations using the Must Have/Could Have/Would Have principles.

Within the development project, we defined a number of sprints (iterations). In each sprint a certain amount of the functionality was implemented.

In order to get a solid product the project team had its own dedicated product owner. The product owner was responsible for discussing requirements and wishes with a set of customers. Using these requirements and wishes combined with his personal vision and functional knowledge of CRM, he came up with a set of global user stories.

These user stories were discussed with the dedicated software architect on the project. The software architect used to apply a great deal of technical detail on the user stories.
Each user story was finaly broken up in a set of smaller user stories in which the complexity grew. The key was to start simple, once the simple scenario was built, the next scenario extended the earlier built scenario etc.

Each user story was divided in a number of tasks. Tasks for developers, tasks for functional consultants, testing tasks, documentation tasks etc. This way complexity was controlled in a simple and effective manner.

In order to make the code rock solid, we relied on a set of design patterns developed over the past years. Combined with a large number of custom libraries in order to facilitate development. No need to reinvent the wheel each time ūüôā

On top of that we hired a specialized tester, who developed a repeatable testing plan and an extensive test set of data. Using the plan and test set, she  the software and functionality we implemented. Before the tester could do her job, the development team and functional consultants were responsible to do their own testing (happy flow only).

From there on the code and functionality was being tortured by her. * did I mention she loved to break things? *

At the end of each sprint a formal delivery was done, by putting the new solution on the testing environment on which the customers could test the software.

At a given moment the development process was running using the following heartbeat…


During a sprint, the functionality that had to be implemented in the next sprint was being discussed within the team. Based on priorities, list of bugs, and availability of the team members a planning was made. From that point on the product owner and architect could work on putting as much detail as possible into the user stories.
At the start of the next sprint, the tester could test the software deployed on the testing environment. Depending on the severity a priority level was assigned to bug. The product owner had to decide what bug should be fixed at what moment. Once testing was done, the tester used to work on the testing scenarios for the next sprint.
The development and implementation team were rushing through the user stories,¬†tasks and bugs¬†to get the job done for the given sprint. At the end of a sprint, there was a formal code freeze, a release was made, and tfs was labeled. From there on it started all over again….

As a member of the development team I am still impressed by this well-oiled machine. In my long software development career, this was one of the few projects run by the book.

Not everything went butter smooth. One of the disadvantages of iterative software implementation, is that code grows organically over time. An organic grow means that the code is going into all kinds of directions over time. Making it hard to maintain and to extend.

In order to streamline the code, a couple of refactoring rounds were required. Another way to monitor the quality of the software was the frequent code review conducted by the software architect.
* Man, I hated those moments that I had to rewrite parts of my code! *

This is something that comes along with professional software development, and I’m still grateful for the CRM and product development knowledge I gained (Kudos to Evert Jan).

Time to iron out the last bugs… Almost another job done!