In this blog post, I am going to tell the story of an Example Company (later also referenced as EC). Also, I need to add that “projects” in this article are understood as some topic on which developers perform continuous work (not very PRINCE 2 way).
Chapter 1. Being small is an advantage
Let’s say that EC is ubiquitous young IT firm. People there are working on a few products, mainly developed by the tiny group or even single developer. They are familiar with the goals they are about to achieve.
Furthermore, EC is doing well. Every product is giving revenue, so they can invent and develop new products. They rapidly extend their portfolio and at some point, they will advance to next phase. Right now they distinguish projects based on repositories existence. That means one developer is regularly working on a single project.
Chapter 2. Creating teams
Ordinarily, companies like EC build a wider and wider portfolio, yet not so big development team. They seek for some kind of reorganization to remain their ability to maintain all products and still develop new ones. What aswell bothers authorities with money is the Bus Factor. Natural idea is to create Teams inside the department and make them responsible for the set of projects matching their skills. In other words, the easiest way is to identify Team with the technology.
At first glance, it looks like a decent idea but unless every single thing is separated it creates major problems.
Firstly communication will become the bottleneck. Developing things in one technology usually requires at least information about solutions used in related projects.
Secondly, if the department is using some tool like JIRA, they tend to mirror repositories into projects. It is a simple and easy approach from the development point of view, but completely useless one from the business point of view. Imagine that requests from business need to be torn into pieces and addressed to different JIRA projects. In result, there are lots of duplicated stories and tasks with no clear value.
Last but not least, overall development tends to slow down and looks like Waterfall process when for instance Team Java willing to add new functionality needs to first address request to Team SQL and not start before their results.
Chapter 3. Return of the Products
At some point authorities with money will ask themselves another question. How can we optimize work and improve focus on our company goals inside the IT department? My answer here is simple. Go back to Product oriented firm.
However, there is a fundamental question they need to answer before doing so. How to define our Products? It is crucial since, you can’t have Product Owner, Product Backlog and team dedicated to Product… without defining what this Product is. I don’t want to rewrite what has been already written, so I recommend reading What is a Product? For purpose of this article, let’s quote the most important part.
I define a product as something (physical or not) that is created through a process and that provides benefits to a market. ~ Mike Cohn
I believe that after reading only the definition you will easily identify products in our EC. I also agree that we can identify products slightly differently, and it is still fine.
Such defined teams will work more effective mainly because they share an identical goal, which is to deliver a genuine quality product and satisfy business values.
I hope this article might help teams that see themselves in either Chapter 1 or Chapter 2. Those in the former case to avoid the situation from the second. And those from second to find the way out of the situation they are currently in.
Do you agree with me, that Product Oriented organization is most effective?