Implementing a New Product From the Scratch
9 December, 2021
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.
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
This was not a high point in my career. It's a story of single metric bias, how I let one measure become a 'source of truth', failed to manage up and ended up yelling at one of the most respected engineers in my team.
Chief Technology and Product Officer at Hive Learning
Consideration for starting a multi year software infrastructure ( V2 ) project that involves hundreds of globally distributed engineers.
VP Software Engineering at human
Why DevSecOps matter and what's really in it for you, the team and the organisation?
Head of Engineering at Xero
Teams have tremendous impact on the products on they build. T.E.A.M definition - Together Everybody Achieves More is true. A collaborative and empowered team builds great product versus the good ones.
Senior Software Engineering Manager at Anaplan
Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.
Viswa Mani Kiran Peddinti
Sr Engineering Manager at Instacart