Scrum-ban

In custom development there are always many features and unforeseen problems. I will share the practical experience of combining Scrum and Kanban technician . I will tell about how we used them, adapted them, optimized them to achieve specific goals, why it was needed and what it led to.



In our current work, we traditionally use Scrum. This effective set of tools has always coped with all the difficulties until a new specific project appeared:



Initial data:

Distinctive features were:

• At the time of the adoption of the project, he was in development for more than two years;
• Implemented an impressive part of the functional;
• Developed a variety of both popular and not relevant solutions.

Our team was to complete the final stage of the project.



After the preliminary work, we set up the environment, raised the server and organized the workflow according to the usual Scrum methodology. Updated the backlog and set about forming a two week sprint.

')

Condition:



1. Planning

In the planning process (Planning Poker, with cards and relative units of measurement of labor intensity S, M, L, XL, XXL), despite the fact that the tasks were worked out in detail and the requirements formed did not raise any additional questions, the practical assessment was far from transparent The following conditions have formed the first problem:



Problem number 1 - Planning, which quickly loses its relevance:

• The lack of information about the methods and methods of developing previously implemented functionality;
• The presence of unfinished tasks;
• The inability to assess the stage and the percentage performance of tasks without detailed long-term immersion in the source materials;
• Conducting hours of planning is irrational.

Planning is not rational, for the reason that the “pitfalls” hidden in the inherited code and hundreds of dependencies cannot be foreseen at the initial stages of working with the code.



2. Development

In practice, everything is even worse. The CMS on which the project was created turned out to be thoroughly revised, the documentation is often irrelevant or completely missing. We begin active communications with the previous team, this allows us to soften the threshold of entry. However, from the very first day of development it becomes clear that we have greatly underestimated some of the tasks. We adjust the sprint plan, based on the revised data.



Problem number 2 - Many urgent unplanned tasks



The project is quite loaded, about 25,000 unique users per day. On the 3rd day of development, critical errors are detected that require immediate correction. Throughout the iteration, you have to rebuild plans, switch between tasks, and take on urgent tasks. What entails additional documentation costs and a sense of total confusion and chaos.



Despite all the difficulties, by the end of the sprint the main thing was done: the customer was satisfied, the reference tasks were worked out. At a retrospective, it was decided to ask the customer to plan their actions as far as possible in advance, to approach the analysis of poker problems more carefully. Which immediately gives some improvements, but other difficulties appear.



Problem number 3 - Changes in the priorities of tasks during the iteration.



After evaluation, the customer changes the priority of the tasks, as some of them are more laborious compared to the customer's ideas and overlap smaller and more urgent ones. The plan starts to change again, urgent tasks appear, priorities change. It becomes clear that these problems are not related to the change of the team - the project itself has this specificity.



The abundance of emergency situations knocks out of the rut, work becomes more difficult, performance drops, moreover, it is almost impossible to give any adequate assessment of the success of the iterations. In retrospect, the question arose of how we organize the process.



Decision:



For this, it was decided to disassemble the two Agile methodologies (Scrum and Kanban) into tools, take only what was needed, put the development on the conveyor.



They took as a basis the organization approach of the development process proposed by the Kanban methodology and left a few tools from Scrum - for the transparency of the analysis of the work done:

• The analyst performs the documentation and analysis of tasks for admission, puts them in the backlog.
• Product Owner adjusts task priorities.
• Pre-planning is not carried out.
• The developer takes the development task with the highest priority from the backlog.
• The completed task enters the testing.
• Necessary checks are carried out.
• A decision is made about the possibility of carrying the task to the combat servers, or re-returning to development.
• In the absence of comments, the task is placed on the stage server, where it is re-checked for regressions or expects other tasks, without which its removal to the combat server is not possible.
• The entire project life cycle is divided into 2 weekly iterations. They are only of a formal nature in order to be able to assess the dynamics of productivity, and also chronologically simplify the tracking of completed tasks.
• Conducting a demonstration at the end of each iteration in a simplified scheme, only those tasks that require additional comments are shown, the customer is able to view the rest himself.
• Each iteration ends with a retrospective.

The main tools we use in this project:

Scrum	Kanban
Roles (Product Owner / Scrum Master / Team) Prioritized Product Backlog Time-limited iterations. Demonstrations at the end of the iteration Daily Stand-up	As the main metric for the planning and improvement of processes, the task time is used. Task scores are optional. You can add new tasks at any time. Continuous flow of tasks not bound to iteration

Accordingly, the changes entailed a number of technical issues: we had to finalize the status system in the bugtracker for transparency of the “testing”, “ready for removal”, “rendered” tasks, etc. .



Results:



The technique showed its results already at the first iteration:

• Productivity growth;
• Unscheduled tasks no longer change overall plans;
• Improving the overall mood and performance of the team;
• Preserving the transparency of organized processes, everything is simple both for the team and for the customer.

Of course, not all problems were solved immediately, but the answers began to come by themselves, you no longer have to puzzle over each of them. Over time, the process became more thoughtful and natural, which gave even more time to develop.



Conclusion:



Over the long years of work in various industries, people have come up with a great variety of methodologies for solving their tasks. All of them are designed to unify the development and to some extent suitable for us. You do not need to dwell on one thing, expand your horizons, disassemble methodologies into tools, take what you need, boldly throw out the excess, do not be afraid to change something. Experiment and you will definitely get positive results!



Author: Syrovatkin Boris - / Test Engineer / Softline Development Department