We follow an agile approach, practice scrum and kanban in our embedded development process. All our development is based on two-week sprints. We have all the standard scrum ceremonies: daily stand-ups, regular PBR, poker planning, and a retrospective at the end of each sprint. We also run an internal demo once a month. Despite the fact that we have been following a flexible approach to embedded software programming since the very beginning of the company's activity, we started actively practicing scrum tools a year and a half ago. The prerequisites for this were the growth of the company, an increase in the number of clients, and, as a result, multiple increases in tasks. Globally, managing the development process is reduced to controlling two types of risks. The first of them is to violate the agreed terms. At best, we can find out that a task requires more time on the same day that the developer started it. At worst — a day or two before the deadline. The second type of risk is to make a functionality that no one will need later. And that's the worst thing that can happen. Read below about how we control these risks.