Implementing a New Product From the Scratch

Problem

The company won a tender which was to provide a software solution. Compared to the whole tender, the software part was small, and its description in the tender documentation was minimal – only a list of modules with a one-line description of each of them. But, in reality, it was a fully functional software stack for a medium telecommunication operator. It consisted of modules like billing, CRM, self-care, admin panel, and several others.

What made this initiative even more difficult was that one of the goals of the tender was to establish a legal entity that would run the whole infrastructure and deliver software. We wanted to use the opportunity to build a new product. However, the problem was a lack of requirements and analysis. Therefore, there were no business users to ask for their needs.

We started by gathering our knowledge about major business processes run by telecommunication operators. We identified usual issues that our customers face in their IT environments, which led us to additional assumptions and non-functional requirements. We proposed an initial architecture of our new product based on that, and we stuck. We had a comprehensive high-level design based on real-life processes, but we missed a starting point for developers. Something from which they could start and then keep building upon it.

Actions taken

We agreed to start with the Scrum process as it was a good idea to keep up the delivery discipline. In such initiatives – in which there are no customers and nobody checks the progress, we tend to spend more time on things that are not necessary. Thanks to time boxing, the Scrum process requires the team to deliver from sprint 0, which helps them focus on the most important things first.

We asked an external consultant to prepare a Scrum workshop for the whole team. To assure that we all understand it in the same way and agree on how we are going to work on this specific project. This was an important action as all of us had some experience from the past, but usually, people understand Scrum differently; therefore, such unification is a good idea to avoid misunderstanding in the middle of the project. Also, engaging an external person turned out to be a perfect move as he brought a broad experience gathered from many customers he was providing consultancy services.

Also, we found a product owner that took the responsibility of filling up our backlog. Lack of business verification of our ideas was difficult, but we had to start from something as the deadline was getting closer. Therefore, we used our experience to start writing down stories, and this helped because shortly, we began to see living applications instead of abstract architecture and processes.

Lessons learned

• Prepare a solid foundation on which you will be building your applications – an architecture. A clear one will guide you through the whole implementation process, and you won't be stuck in a dead-end street. This should happen before you start the implementation process as an architecture may imply what development tools and technologies you should use.
• Don't forget to document project decisions – write down your concerns and assumptions to avoid reinventing the wheel when something similar appears (you will be able to refer to your decisions and considerations from the past).
• Don't be afraid of changes – eventually, you will be asked for customizations and plan possibilities to develop them at an early stage.