Sebastian Gnagnarella

Lot of things, but deep inside just a Geek,,, well not so deep…


Product Development

Continuos Integration as a Martial Art

Few months ago I read a great article that was suggesting a journey for CI comparing it with the different steps in learning Karate.

Unfortunately the article was in Spanish so I couldn’t share it right away, but I decided to take some minutes this morning and come up with a rough translation for y’all.

Original Article from Martin Salias:

* In case you are a Karate guru on the team ,  the belt colors may be out of order or just wrong 🙂 *

White Belt

  • Install Team City or Jenkins
  • Every team should learn how to configure their own projects
  • Each commit has to automatically compile
  • Projects in RED are not allowed

Yellow Belt

  • Start with tests and run them with every commit
  • Again, projects in RED are not allowed, use this opportunity to learn what the others are doing and stabilize the tests

Orange Belt

  • Start with TDD and ATDD, increase the number of tests too
  • Start measuring code coverage and enforcing it (at least 1% for each new class)
  • Start increasing the code coverage limit, if the code coverage is not satisfied the project should go in RED
  • Every time a bug is reported in test or prod, write the test to demonstrate the issue first, and then fix it

Green Belt

  • Start executing static code analyzer and have the build server reporting on them
  • Focus on the main issues reported, and once fixed, start enforcing code quality (project goes into RED if it is not passing)

Blue Belt

  • Start versioning code together with database migrations, configurations and libraries
  • Make the build server compile, run all the tests and validations and generate a new testing environment from scratch

Brown Belt

  • Work with dev ops and web ops to validate and adopt environment deployment scripts and processes
  • Have the build server create a test environment from scratch with every commit and also an incremental one (upgrade/update)
  • Automatic rollbacks in the incremental environment using scripts

Red Belt

  • Every time there is a commit and all tests and validations pass, generate a package that can be deployed to production with the click of a button.
  • Start working on hot-deploy , non user impacting , deployment automation

Black Belt

  • Every time there is a commit, goes to production without interrupting the service

Some Thoughts on Product Development

This blog is based on my participation in a panel during the Denver Startup week on 10/1 at Spiredigital.

Thank to Nick Coppolo for putting the questionnaire together.

What’s your view of product development and how does that guide what you do each day?
I could give the PMBOK definition, but, no,,,, for me Product Development is the art and process of marrying customer/business needs with technology solutions.

In my experience I’ve seen 3 challenges with this :

  • Customer needs are different from what they tell you they need.
  • Sometimes customers do not know what they need and requiere an expert advice (as Henry Ford said “… If I had asked people what they wanted, they would have said faster horses…”.
  • (We) Technologists like to build cool Shi*, that may not have anything to do with business needs or could include a lot of gold-plating.

To avoid all of this I usually recommend a lean development approach, short iterations and a lot of prototype development (when possible) – allow you customers to experience often and provide feedback.

What were some initial challenges you face in receiving approval or proving a market fit for your product, prior to beginning development?
This varies from project to project but everything usually boils to $$$, the easiest path to receive approval is to compare investment with ROI.

Did you often have to pivot throughout the ideation and development process, and why? Was it for the better or worse?
Pivoting throughout ideation and development is a key part of agile development, however I like to have a clear picture of the end result before starting. The worst thing we can do to a development team is to switch gears in the middle of a project and start building something completely different. On the other hand, fine tuning is expected and should be welcome.

What does your product development team look like?
This also varies from project to project. Ideally we have a project manager, a BA, a product manager (the liaison between the business and the tech team), a testing team and a development team. If the project is developed using a partner or an agency, we usually try to match up their resources with few internal resources (which I name “champions”). I.e. have an in-house product manager working with their product manager and BA, an in-house developer working with their development team, etc – this practice helps to keep key knowledge in house and drive the use best practices.

What’s your view on outsourcing or using outside resources to develop your product?
Related to this question I distinguish two types of outsourcing: by project and staff augmentation. The earlier implies that the vendor/partner/agency provides a full project team and sometimes own processes (that I rather complement with internal resources as I said before), the later means just an addition of developers to augment delivery.
In both scenarios it is just a matter of finding a partner that clicks with the company culture and the internal team. Sometimes that click will be driven by really subjective things (I “like” their developers), sometimes will be driven by objective things (we can only work with local/on-site resources) and sometimes a combination of both – the key is to find what works for your team and company and find “partners” not simple “vendors“.

What are the keys to shipping product to market quickly and successfully?
The main challenge is to go from 0 to 1 and come with that MVP. Projects get delayed a day at a time and frameworks like scrum help to mitigate or prevent this.

What advice would you give people in the beginning stages of developing or ideating their product?

  • Have a clear vision for your “forest” and start planting “tree by tree”.
  • Spend good time in ideation and architecture, but do not over spend. Build a bazaar not a cathedral.
  • Adopt agile methodologies.
  • Build you architecture to scale (do not underestimate your possible success), this applies to both hardware and software.
  • Decouple your architecture as much as possible, this will allow you to distribute and parallelize work.
  • Create prototypes and get user feedback soon, do not ideate in a vacuum.

Create a free website or blog at

Up ↑