The SCRUM methodology was first described by Hirotaka Takeuchi and Ikujiro Nonaka. They noted that the projects that small teams of specialists from different fields are working on, usually systematically produce the best results, and explained this as the “rugby approach”.
I strongly recommend reading the book, which is in our team the bible of any project - “Scrum. A revolutionary project management method” By Jeff Sutherland. With this book, Magneex has achieved tremendous results in the field of project development.
We didn’t take the methodology completely and use all existing artifacts and rituals of SCRUM, but, as always, we adapted a lot to the peculiarities of our business.
In this article I plan to tell you what and how we apply in our company, and at the same time I will talk about the internal processes of how the magic of developing digital projects is going on in our country.
So, the technical specifications is written and agreed upon, up to this point there was no discussion of any flexible methodologies, there was a cascade model of performing work with a clearly formed sequence of actions by the project manager.
After reading the development assignment by the technical director, he compiles the so-called Product Backlog. In essence, these are the very modules that need to be developed within the project, described in the estimate. Then the project development team is assembled and makes an informal assessment of each of the project’s Story points. In our company, we use the mechanics of Planing Pocker. After the task weights are defined and affixed, the project manager then contacts the owner of the product, in 95% of cases the owner of the product is the client, our client. The highest priority project modules that need to be implemented first are determined in collaboration with the client. This process is called the Sprint Planning Meeting.
The sooner the product is released and the target audience starts to use it, the faster it will begin to pay back the cost of its development. The ideal site is like a radiant star, to which we can only strive, constantly improving and modifying the product, but completely unreachable in such a rapidly changing world. Therefore, do not be afraid to release the "raw product". Failure to release a product or delay its release can cause irreparable damage to the business and your nerve cells!
Empirically, we calculated the power of our team and how many Story Points we can close as part of the sprint. Our sprint is always equal to one week, the shorter the sprint, the more accurate we can spend on evaluating the labor costs, plus frequent meetings with the client and a demonstration of the work have never harmed anyone. We compile and sign Sprint Backlog. In fact, this is a list of tasks that we undertake to implement in the framework of the sprint. We also preliminary discuss with the client on how are we gonna demonstrate the result of our work.
It is important to understand that after the approval of Sprint Backlog no changes are made, because this will certainly affect the result of work and in 9 cases out of 10 will lead to the sprint failure.
After all the preliminary work, the sprint begins. We start every sprint on Friday, because some developers like to work on weekends. The last day before planning is Thursday.
Every day at 10:00 local time, all project managers gather with their SCRUM teams to monitor work. This ritual is called Daily meeting or Daily planning. Each member of the SCRUM team gets up and answers 3 main questions:
- what did I do yesterday?
- what will i do today?
- were there any problems?
In case of problems, the project manager is obliged to eliminate them as soon as possible so that nothing distracts the developer from fulfilling his direct obligations in the team. This technique allows you to quickly respond to abnormal situations and engage in internal redistribution of resources, if it is necessary to comply with the quality and timing of work.
Upon completion of the sprint, the project manager contacts the client, demonstrates the weekly result of the team’s work and forms the Sprint Backlog of the next sprint. At the time of such meetings, the client has the right to make changes to the Product backlog and change the essence of the project as he wants, or in the way the market requires, existing circumstances, etc. Often, in case of significant changes, the site ceases to be that initially described in the technical specifications, which leads to a revision of the cost of the project.
This can be repeated an unlimited number of times until the client wants to stop development, or the Product Backlog is completely exhausted. Many of our projects were started 3-5 years ago and continue to be improved to this day. Some of the projects are continuous, and the sprints are one after another, others have gaps in performance in a month or more. Any scheme of work is possible due to the flexibility of this methodology.
Conclusion:
- when using flexible development methodologies, changes are made to the project as quickly as possible;
- there is no need to formulate long-term project implementation plans, which are often deceptive due to the impossibility of taking into account everything at the early stages;
- close cooperation with the client at regular intervals, which allows us to produce the most effective projects that meet the expectations of both parties;
- meeting deadlines of the project at short intervals (sprints).
This is how the internal development of projects in Magneex is done. If you want to learn more about magic, be sure to contact us through the form below.