There is no silver bullet, or how we got from the waterfalls to Kanban through the Scram Ajails

In this article, I would like to share the experience of using different development management techniques (Waterfall, Scrum, Kanban) in Acronis and tell you what caused the choice of a particular technique or practice.



First, a couple of introductory words. The product development cycle in Acronis, as a rule, lasts from six months to a year. A team of 40-45 people takes part in the development. The product itself is a system application, and the main development goes to C ++. Important point: the product must be released exactly in time no later than a fixed point in time (yes, it happens).



The latest brainchild of our company - ATI, in the world known as Acronis True Image . This product has been in development for quite some time, so much so that we managed to write about it on Habr not one , not two, or even three articles (find the fourth one yourself ). The ATI development team is quite impressive, and therefore we have a lot of experience in managing such projects.

')

So, once upon a time we had the classic “waterfall” model of development:

Requirements -> Design -> Implementation -> Testing and Stabilization -> Support.



What was the reason for this? Partly, it happened historically, partly - because almost every year some new technology appeared in the product. It is more convenient to develop exactly the technological solution, and not only the product based on the existing technology, in a cascade model. Indeed, it is difficult in one iteration to put the development of creating a hard disk snapshot and still manage to stretch it to the user interface and be able to show the result in one short iteration.



The following discussion focuses on flexible development methodologies. Looking ahead, I will note: flexible methodologies with short iterations push the team to create solutions that are not very architecturally correct: technical debt begins to accumulate, which sooner or later will have to be paid. And, frankly, in 2004-2006 in Russia (and indeed in the world, probably) were not yet so popular and known for Agile or Scrum.



But, obviously, there were also disadvantages. In our case, the biggest problem was getting into the deadlines. Yes, planning and sometimes prototyping were done, but it was extremely difficult to predict whether the creation of this set of functionality would be met in time. In addition, the development in this case was carried out horizontally (first the system logic, then the business logic, and then UI), the result was an even layer of equally unstable functionality that required a long and costly stabilization cycle.

Agile . Long iterations

To begin with, we decided to move to iterations of 1-2 months, more often 2. Each iteration was, in fact, a small cascade subproject. In the first iteration, we took on the important and hard-to-implement functionality, the next - on the less important, and so on. It turned out that we often discarded the last iteration and devoted this time of stabilization. A positive result was evident - the project became more predictable.







However, as you know, there will always be their "BUT". Iterations, as a rule, did not fit in time, technical debt and errors began to accumulate, since in a long iteration a lot of functionality was implemented, and we did not have time to stabilize it. As a result, we still waited for a period of stabilization. True, we could decide to start it earlier, at the end of one of the iterations.

Scrum

As we worked on projects, practices themselves began to be born, the need for which we felt on ourselves. So, we noticed a lack of communications in the project: some team members were inclined to write “bicycles”, duplicate code, or delayed terms, because they were embarrassed to clarify details. Noticing this, we decided to hold morning meetings to discuss the problems of the past day and plans for today. So, without knowing anything about Scrum, we introduced one of its elements into the work. Moreover, the technique was perceived quite positively by the developers themselves (which, as we know, does not always happen). I think this is due to the fact that the approach solved our immediate problems at that moment.



Now let's dwell on how we understood that we should start using Scrum practices.

Let me remind you that it is of paramount importance for us to meet deadlines, so the first step is always the need to understand where the project is on the timeline. In principle, this question can be answered by a burn-down schedule for current tasks.

But there are a few nuances:



1. From the beginning, you need a good project plan. Good means very detailed: all functionality must be described, thought out and planned. Very similar to the first stage of the cascade model.

2. In the course of execution of the plan, surprises will be guaranteed.

3. Time passes, and with it people usually come and set new tasks for us.







It turns out that what is needed is not a detailed project plan from the very beginning, but the ability to quickly respond to changes, while keeping control of the quality and the final release date. Scrum implementation took us quite a long time, and not everything went smoothly. Here is a brief summary of what we do from Scrum practices:



1. Sprint for 2-3 weeks. Recently, we decided that it was still more effective for 3 weeks;

2. Each sprint includes rescheduling, demonstration and retrospective;

3. Clear goals for the sprint for all project participants.



The goals of any sprint are user stories. I would say, without good user stories, you won’t get effective sprints.

User stories

Why do we even talk about them? A typical requirement for Acronis developers is a large “sheet” that describes the behavior of a certain part of the product functionality. For example, creating a backup of the entire computer. And the requirements that describe what to copy, where to copy and how to copy are also dropped here. And if you seriously sit down and paint it all, you’ll have more than one page of text.



Suppose we got this description. Further this description needs to be comprehended by the project manager, developers, testers. One needs to have tasks on developers in order to implement all this, others need to write a lot of test cases to test. The main question arises: how to understand that the requirement is fulfilled? That's it for this we decided to describe the stories and user scenarios.



The typical format of our stories looks like this:



1. The user's problem, which the story is intended to solve;

2. The story itself;

3. Checklist.



Description of the problem is very important for a clear understanding of what we are doing and why. A checklist is a kind of minimum set of test cases that a story must go through. In essence, this is the definition of what has already been done. An important requirement for our stories is their size: one story must fit into one sprint.

Kanban

The introduction of the mechanisms described above exposed other problems: the team’s out of synchronization and the defocusing of its individual members. What is this manifested in? Difficult to work out product requirements for a long time hung in the stage of "working out requirements." Why? First, it was always possible to take some simpler demand into the work, postponing negotiations and solving problems with other participants of the process for later. The second problem is the lack of a holistic picture of the sprint: where are we, what is now important for the successful completion of the sprint? Is it possible to take something in the work? On whose side is the ball?



The solution to the problem for us was the use of Kanban-boards with a limit on the number of stories in each of the columns (to maintain focus) and with clearly marked people responsible for each specific stage of work on the user history. Moreover, the use of Kanban-boards does not contradict the practices of Scrum in our work.

findings

Our main message to the reader: first - understanding the problem, and only then - its solution.

I often see a desire to choose one of the methods for the sake of the method, and not for the result or solution of problems. Therefore, in this article I have tried to describe with concrete examples what is necessary and when this or that methodology is appropriate.

Cascade - for orthodox classics, adepts of the code.



Agile - for teams, especially those who are not indifferent to the process, with a competent leader and time management guru at the head.

Scrum - for a team with streamlined communication, a clear role system and interchangeability. And, not least, this system is suitable for the customer who is ready to adopt your work rhythm and participate in the improvement of processes.

And, finally, Kanban - for teams that are ready to solve large problems in the absence of timeboxes; that is, for those who find it most important to minimize the volumes of work in progress.



Each projects deserves it's methodology of development

(mantra of the Acronis development team)