Scrum ban

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

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

Initial data:
Distinctive features were:

• At the time of the adoption of the project, it was in development for more than two years;
• An impressive part of the functionality has been implemented;
• A lot of both demanded and not relevant solutions have been developed.

Our team had 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. We updated the backlog and started the formation of a two-week sprint.

Condition:

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

Problem No. 1 - Planning, which is rapidly losing its relevance:

• Lack of information on ways and methods of developing previously implemented functionality;
• The presence of unfinished tasks;
• Inability to assess the stage and percentage completion of tasks without detailed long-term immersion in the starting materials;
• Conducting hours of planning is irrational.

Planning is not rational, because 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 not relevant or completely absent. We begin active communication with the previous team, this allows us to soften the threshold of entry. Nevertheless, from the very first day of development, it becomes clear that we greatly underestimated some of the tasks. We adjust the sprint plan based on the updated data.

Problem No. 2 - Many urgent unscheduled tasks

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

Despite all the difficulties, the main thing was done by the end of the sprint: the customer was satisfied, reference tasks were developed. In retrospect, it was decided to ask the customer to plan their shares in advance, to approach the analysis of tasks before poker more carefully. Which immediately gives some improvements, but other difficulties appear.

Problem No. 3 - Changes in task priorities during an iteration.

After the evaluation, the customer changes the priority of the tasks, as some of them turn out to be more labor-intensive in comparison with the customer’s views and cover smaller and urgent ones. The plan begins to change again, urgent tasks appear, and priorities change. It becomes clear that these problems are not related to the change of team - the project itself has such specifics.

The abundance of emergency situations is unsettling, it becomes more difficult to work, productivity decreases, moreover, it is almost impossible to give any adequate estimates of the success of iterations. In retrospect, the question arose of how we organize the process.

Solution:

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

They took the approach of organizing the development process, proposed by the Kanban methodology, and left several tools from Scrum for transparency of analysis of the work done:

• The analyst documents and analyzes tasks for admission, adds them to the backlog.
• Product Owner adjusts task priorities.
• Preliminary planning is not carried out.
• The developer takes the development task with the highest priority from the backlog.
• The completed task goes into testing.
• The necessary checks are carried out.
• The decision is made about the possibility of transferring the task to the battle server, or re-return to development.
• In the absence of comments, the task is submitted to the stage server, where they are re-checked for regression or expects other tasks, without which its transfer to the battle server is not possible.
• The entire project life cycle is divided into 2-week iterations. They are only formal in nature for the ability to evaluate the dynamics of productivity, and also chronologically simplify tracking of completed tasks.
• Conducting a demonstration following the results of each iteration according to a simplified scheme, only those tasks that require additional comments are demonstrated, the customer is able to view the rest himself.
• Each iteration ends in retrospect.

The main tools used by us 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 planning and improving processes, the time taken to complete the task is used. Grades are optional You can add new tasks at any time. Continuous task flow not tied to iteration

Accordingly, the changes entailed a number of technical issues: I had to modify the status system in the bugtracker for transparency of the status of the tasks “testing”, “ready for removal”, “submitted”, etc., as well as to determine the rules for maintaining tasks in the version control system .

Results:

The technique showed its results already at the first iteration:

• Productivity growth;
• Unscheduled tasks no longer change the overall plan;
• Improving the overall mood and performance of the team;
• Maintaining 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, no longer need to puzzle over each of them. Over time, the process became more thoughtful and natural, which gave even more time for development.

Conclusion:

Over many years of work in various industries, people have come up with a great many methodologies for solving the tasks. All of them are called upon to unify development and, to one degree or another, are also suitable for us. No need to go in cycles on one thing, expand your horizons, disassemble methodologies into tools, take what you need, feel free to throw away excess, do not be afraid to change something. Experiment and you will surely get positive results!

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