It is all about Agile - 1: popular myths about agile development

Agile methodologies have taken root in IT and non-IT, overgrown with their signs, stereotypes, superstitions and mythology. The editors of the Mail.Ru Cloud Solutions blog decided to talk about this mythology with Agile-Coach Vasily Savunov from ScrumTrek.

Agile is a philosophy of agile development, the basics of which are described in the Agile Manifest of Software Development . At the foundation of the concept are four basic values:

• people and interaction is more important than processes and tools;
• a working product is more important than comprehensive documentation;
• cooperation with the customer is more important than agreeing the terms of the contract;
• willingness to change is more important than following the original plan.

Agile principles have transformed the development process and won respect. The modern world is greatly accelerated - dozens of new services, digital solutions appear every day. Agile allows a business to be fast enough when developing new products to keep up with this fast rhythm and to give users and customers something that will solve their problems as early as possible.
')
Together with the popularity of Agile came and its formal interpretation. Let us analyze the myths and stereotypes that make it difficult to see the essence of the flexible approach and get more from it.

Myth 1. Agile is for IT only.

No longer. Just look at the list of companies on behalf of which speakers speak at the Agile Days and Agile Business Conference conferences: Gazpromneft, Rostelecom, Severstal, PTG-Group, 12Storeez. These and many other organizations not related to the IT-industry, more than successfully use Agile-approaches.

Myth 2. Agile - not for projects with a fixed budget

In a fixed budget, you can work very differently. The question is, what is the relationship between the performer and the customer. If you use Agile, then you need to focus on what solves the problem of the customer. In other words, if at the start the customer and the contractor together plan and highlight the main priorities of the product, then nothing will prevent them from determining which part of the product is as useful as possible within the limited budget. And if we also stipulate regular demonstrations made to the customer, then it is quite possible to correct the process for short periods and, accordingly, to adjust the costs of the project.

Myth 3. Agile - a panacea for business and development: implement, something will improve

I think this is a simplified and very harmful view of things. All cases and businesses are different, and you need to choose the right approach that will help in this particular case.

Certainly, Agile is not needed where the key to success in following a clearly defined algorithm of actions. For example, in the work of the call center, where, for better service, operators should talk on “scripts”, i.e. pre-written communication scenarios. There is no field for experiments, and they may even be harmful here. So, Agile in the activities of call center operators is not needed.



Agile will be harmful where the cost of “processing” or “reworking” a product is enormous or may even be associated with human victims. Say, during the construction of a nuclear power plant, it is obvious that we cannot build it iteratively and incrementally, as Agile dictates to us.

Myth 4. Scrum, Lean, Kanban do not overlap

Methodologies and tools should be separated. Methodology is an algorithm for building a workflow. Tools are those “bricks” that are used in this algorithm.

Different methodologies may include the same tools, but in a different layout. You can often see how, when implementing Scrum, they use XP (extreme programming) or Kanban tools. And this is normal, as they all meet the values ​​of Agile, and allow you to make the workflow of creating a product flexible.

If you talk about the specific Agile-approaches that are now most common, then this is certainly Scrum and Kanban. Others - FDD, XP, RUP, and so on, either left the stage or are rarely used entirely, but some tools from their arsenal are involved in the implementation of Scrum or Kanban.

Myth 5. Scrum is how to quickly and cheaply make a product.

As for “fast,” everything is correct, but about “cheap” - no. Judge for yourself: you need to form a full-fledged team, highlighting in it the necessary competencies at 100%. These people will be engaged only in the development of the product entrusted to them and nothing else, which means that they will have to either hire such specialists or “tear them away” from some department. The same applies to the business part: if you want, you do not want it, but you will need to allocate the owner of the product, who will spend 50–80% of his time only on this team and its product.

In addition, it will be necessary to bring them all together, into one room, provide them with their own space, props for team activities, and so on. Plus, you need to keep in mind that at least eight hours per sprint will be spent on communication, as Scrum involves a series of mandatory meetings lasting one to two hours. You have to invest in any case, but the final gain in speed and quality that Scrum provides is very large.


Sprint includes 4 mandatory meetings: planning, implementation, release, sprint review with a retrospective. In addition, short-term meetings (stand-up meetings) are held every day, at which team members in a single format “check the clock” and coordinate their actions. It is impossible to add new tasks to an open sprint - this teaches the team to plan and insures against the emergence of managerial chaos.

Myth 6. Kanban are boards with tasks hung on them.

Not at all! Boards are just the first, easiest step in Kanban. But it is not limited to them . At the heart of Kanban is a complex mathematical apparatus based on statistical data. Therefore, equating kanban to boards means not to look beyond its facade.

In a nutshell, the main point of Kanban is to:

• Make the current workflow transparent, and cover all stages - from the emergence of the task in the head of the business to its implementation and shipment of the product to the consumer.
• Manage your workflow, identifying wasted time and eliminating it. In this way, we make our workflow predictable.
• Make management decisions based on metrics, not sensations.

Myth 7. Scrum and Kanban can be planted in any projects and companies.

I do not like the word "planting", yet Agile is about working with people. It would be more correct to talk about “instilling” in the team a new philosophy of thinking.

At the same time, Scrum and Kanban grafting algorithm is different.

The success rate of using Scrum depends on the company's corporate culture. In a rigid hierarchical structure, where every piece of paper needs a piece of paper, no efforts to “grow” Scrum will succeed without the support of top management. We'll have to build a new, parallel structure based on a team approach. A kind of "reserve Agile", which will protect some of the managers of the highest echelon. In such conditions it is possible to show a quick result in three to four months. But there will be more difficult task ahead - to extend this culture to the whole organization. How long it will last is extremely difficult to assess. But, in my experience, if a new approach has covered 30% of the company, then it begins to spread itself, and he no longer needs protection from above.

The implementation of Scrum generally requires major changes, both in the structure of the organization and in contracting with contractors (a time & material contract is needed), and in budgeting (stage-by-stage budgeting), and everything else.



Kanban does not require such a radical change. He suggests: “Start with what you have, and start evolutionary to improve it.” The rate of change will be significantly lower than in Scrum, but all changes will be based on statistics and have a clear rationale.

Myth 8. Scrum is designed only for projects that are made from scratch.

There are different cases, there is no hard and fast rule that Scrum is intended only for development from scratch. Transferring existing projects to Scrum is not only possible, but often and advisable. It all depends on the willingness of artists and customers to restructure their work in order to speed up development. If they are ready, everything is achievable.

For example, one of the creators of Scrum, Jeff Sutherland, in his book Scrum: The Art of Half the Time, recounted how he applied Scrum to develop an automated FBI data accounting system. When he took up the project, the development was going on for the fourth year, not a single function was brought to release, and neither the end nor the edge was visible to the project. Jeff was able to drastically speed up development and make it transparent to customers. Six months later, the first working version of the product saw the light, and within two years the development was successfully completed.

Myth 9. When introducing flexible methodologies, conflicts with representatives of the traditional hierarchy are inevitable.

If everything is done correctly - to separate the team from the traditional hierarchy, give the budget to the owner of the product and hire a truly skilled Scrum master, then there will be no conflicts. But this is not always the case. It is often impossible to combine these two structures, so there is only one way out: to build a new structure, sharpened by quick decision making and product implementation.

And you will find out about who the Scrum master is in the next series. Wait in the second part for Vasily's story about the implementation of flexible development methodologies: difficulties, benefits, pitfalls and time bombs.

There is no time to explain, the Mail.Ru Cloud Solutions team prepared the material disinterestedly and lovingly.