It is all about Agile - 2: features of the introduction of agile development

We continue to discuss the nuances of agile development (Agile) that occur in practice. How to understand whether Agile is correctly implemented, what practice is suitable for which task and industry, who in the company should transfer work to Agile Rails? Agile-Coach ScrumTrek Vasily Savunov continues to share his experience with the editors of the Mail.Ru Cloud Solutions blog .

Vasily last time told us what Agile is, what methodologies it includes and what stereotypes have formed around it. Now let's talk about its implementation.

About Agile Companies

- Are there “industry preferences” in flexible methodologies?
')
As the Agile Russia study shows, which we have been conducting for the second year in a row, Scrum is mainly used in software development, Kanban is used in financial organizations, and in the telecom industry both.

As a person who directly analyzed the collected data, and worked with many of the respondents, I believe that this situation is due to two reasons:

• The rate of change in IT is significantly higher than in finance. Therefore, Scrum is preferred there as an approach that allows, through fast experiments, to flexibly manage priorities and change direction depending on changes in the external environment and conditions at the entrance. Finances are more conservative.
• The cost of a mistake in finance is much higher than in IT development. Therefore, they are more appreciated by Kanban, based on mathematics, rather than on experiments, and allowing to improve the work process as a whole through small but constant changes.

Kanban telecom is also suitable. If only because the vector of development of the industry is digitalization. However, so far few people understand how it should look like. In addition, in the telecom, the “fast” part of the work (software development) is adjacent to the “slow” part (support and development of the hardware infrastructure). Therefore, along with the experiments that are carried out according to Scrum, it makes sense to accelerate evolutionary processes using Kanban.


Agile development techniques adopted in various industries. The amounts are not equal to 100%, because you could choose more than one item. Image / ScrumTrek

- How are mobile developers doing? Does Agile have any specificity in mobile development?

From my point of view, the main difficulty in developing mobile applications is identifying application requirements, because it can be difficult to identify stakeholders. These difficulties can be overcome if customer development is used to research customer needs and Scrum to quickly test product hypotheses.


In general, Agile is perfectly combined with mobile development: it requires a quick response, involvement and well-coordinated work of different specialists, the ability to quickly provide the result and, if necessary, change it.

In addition to Scrum, you can also use mobile-oriented approaches here. For example, Mobile-D is based on XP, Crystal, and RUP — approaches that are rather ancient and well-developed. The main difference between Mobile-D and Scrum is that there are clear phases and a dominant focus on the engineering side of the product development. If Scrum pays more attention to the management and delivery of the product, then Mobile-D focuses on the production process and includes XP practices that significantly improve the quality of the final product. At the same time, the influence of RUP affects, therefore the process is rather formalized.

Another, the most modern approach to mobile development is SLeSS , combining Scrum and Lean Six Sigma . First, he implements the Scrum workflow, and then he uses Lean Six Sigma approaches for statistical quality management. It seems to me, SLeSS combines the necessary flexibility with the mechanisms of informed decision-making based on statistics.

At the same time, Scrum Guide does not initially prohibit the inclusion of any other approaches and tools into the Scrum workflow that may be useful for product development. Therefore, all of the above can be implemented in the framework of the "classic" Scrum.

- How flexible are the methodologies that can be modified for particular conditions?

Here it is necessary to consider separately Scrum and Kanban.

Scrum is a framework, that is, a framework, all the elements of which are mandatory: events, and roles, and artifacts. None can be thrown away. But there are no strict requirements on how to implement these elements exactly - do as you like. And Scrum does not forbid adding new elements: meetings, artifacts, roles that you need to work and help speed up the process.

Kanban - a set of tools and metrics. It does not give rigid installations about what tools and in which combination to use, since it is designed for a long evolutionary change of the existing system. But at the same time, the success of Kanban is determined by the collection of data on the working process and their regular analysis. If this is not done, with time everything will stall and there will be no further improvements. But do not worry: as Edward Deming said, you do not have to change, survival is voluntary.

- What are the typical mistakes when adapting a Scrum makes a business?

The main mistake in the implementation of flexible methodologies is the use of tools without understanding why they should be used specifically.

For example, in large organizations, when implementing Scrum, they often simply rename the project manager to the product owner, and the project team - to the Scrum-team and begin to demand to give the finished result in two weeks. But this does not work, and for a very simple reason: the conditions under which Scrum can work are not fulfilled.

• Although the project manager was dubbed the Product Owner, he did not receive the necessary authority and therefore had no right to form a product vision or change implementation priorities. As before, he is forced to coordinate his every step with the management and is clamped into the framework of the requirements for terms and volume of work. So, the speed of decision-making remained the same. No acceleration or adaptation to changing conditions.
• Though the project team was called the Scrum team, the people included in it can still be listed in their department and report directly to their line managers. Accordingly, each of the team members first of all does what his line manager will charge him, and not the Product Owner. As a result, product tasks will always be lower in priority, which means that the speed at which the product for which the Scrum team was “put together” will not increase.
• Most likely, as before, team members will be busy in other projects. While Scrum directly stipulates: team members must be allocated to the Scrum team for 100% of their working time, and deal only with the product, which their Product Owner leads. If people are “divided by interest” between projects / products, they will switch between them, which will drastically reduce both the involvement and the effectiveness of work on each specific project / product.

There are a lot of negative consequences of such inept "implementation", and they begin with an attempt to reproduce the mechanics, but not the essence of Scrum. The main errors in the implementation of Scrum, I described in detail in his report " Stop signals for Agile " at the conference CodeFest 2017.

- How to evaluate how competently flexible methodologies are implemented in the company?

There is a test Scrum Open , but it is more likely to test theoretical knowledge. What happens in practice, he does not understand. Given that Scrum's foundation is teamwork, and its priority is product delivery speed and customer value, it is best to conduct 360 surveys . So it is safer to establish the degree of maturity of the team and customer satisfaction.

We use our own methodology, which is embodied in the service ScrumTrek Diagnostic Tool . It works like this. The team and stakeholders outside it are asked a series of questions about how they assess the level of teamwork, the planning of their work, the value of the result delivered to the customer, interaction with other teams, and so on. For each parameter, a median of opinions is calculated and a complex pie chart is built - Radar, which displays the view both from inside the team and from the outside.


ScrumTrek radar. We look at the range of estimates


ScrumTrek radar. We look at the medians

The scheme contains a lot of useful information.

• Atomic estimates of individuals and their averages are interesting in their own right; explanations are not needed here.
• A scatter of ratings in a team is an interesting thing. When it is very big, there is a reason to agree on what we, as a team, mean by this or that aspect of our work. What do we mean by “customer value”, for example? And the "speed of delivery"? The large scatter indicates that the team has not formed a unified position on a number of issues.

A small scatter speaks of consensus and good teamwork.

• Ratings are categorized. You can see that everything is fine with the culture, but the performance sags here and there. It is clear where to "dig."
• The difference between evaluating inside and outside the team is one of the most important indicators; it shows the discrepancies between the expectations of customers and other stakeholders from the team and how the team perceives itself. Agile is about close cooperation between business and those who sell the product, so these discrepancies are an excellent reason to “check hours” between these two areas and agree on how to restructure the team’s work.

After data collection, a chart analysis is necessarily carried out with the involvement of the whole team and stakeholders. Everything to show them how the work of the team looks from different sides, and to reorganize the results of the analysis into concrete steps to improve the work.

About Scrum Implementers

- From whom should the initiative of introducing agile development methodologies come from the company?

Scrum implementation always comes from a business goal. Therefore, the customer should first think about acceleration - either internal or external. Then you need to work out the concept of the product so that it can be done iteratively. And only then form a team. Scrum for Scrum doesn't work. Moreover, it may be too expensive for specific tasks.

Who will be Agile's guide to the company is a question without the only correct answer. I saw the technical director become the "instigator" of changes. There were cases when the initiative came from the business, and even saw how such an initiative was born “from below”. Everything depends on the energy and motivation of the person, on whether he will be able to embed his vision of development using flexible approaches in the business context of the product or division.

Ideally, when the initiative comes from top management. Advances in this direction in the Russian market are noticeable.

- What new roles and functions arise in an organization or team with the introduction of flexible methodologies? Which ones are required, which ones are optional?

In the case of Scrum, these are the roles of the Scrum master, product owner and development team. All of them are required. The development team is also considered a “role”, as it unites not only developers, but also all those who need it, so that a product basically emerges: analysts, designers, and so on.

A Scrum master and a product owner may have assistants who take on part of their responsibilities, while the responsibility for the result remains with the Scrum master or the product owner.

The product owner is often a person of business. But not necessarily: for example, if we create some kind of engineering solution for production, this role can be performed by the chief engineer. Ultimately, this is the person who best understands what consumer we are making the product for, what problems it solves in the first place, how priorities should be set up when creating it. It is very important that the product owner has the authority to independently determine the composition of the product on the basis of data from the market and from the consumer. He should have the right to say "no" to interested persons with whom he interacts. It is necessary that priorities are agreed, and decisions are made promptly.

A scrum master is a person whose task is to create a strong, cohesive, responsible, and ideally self-organized team. What is important is not a tmlid , that is - not a leader. Scrum-master has no right to give guidance or directly intervene in product development. He is an organizer, facilitator, coach and Agile practitioner. In my experience, the best Scrum masters are obtained from project managers - provided that they have been trained and managed to move from the directive format of communication to the coaching one.


Speaking of coaching communication style. There is also an Agile Coach . His task is to customize the workflow, train people and give them the tools for daily activities in Agile. Including conflict resolution tools. Everything else is outside his remit. Ideally, an Agile-coach should set up the work of a team or even a department so that everything works on its own, and the Agile-coach is no longer needed.

The transition period is always associated with discomfort. Agile-Coach is designed to help the team go through this period with minimal friction and develop new - convenient and effective - methods of work.

When scaling, additional roles may be introduced, as described, for example, in the SAFe framework , but they are still based on the terms of reference and principles of the Scrum-master or product owner: there are simply hierarchies relative to the product.


- How are the functions of the product owner and the Scrum master "in an ideal world" delimited?

On one side of the scale are the interests of the business that the product owner represents, and on the other, the viability and effectiveness of the team for which the Scrum master is responsible. In order for the team to quickly achieve results, the system must remain in balance. If the product owner “wakes up”, the team will work on nights and weekends, and soon he will be in front of a handful of demotivated, non-involved people instead of a well-coordinated team. If the Scrum-master drags itself over the blanket, the development will be conducted neither shakily, nor shakily, with constant disputes and much longer than necessary.


- What methodologies and management models should be mastered by those who are going to take on one of the previously described roles?

In terms of business competencies, everything is “in the classics”, as with ordinary management, except for the need to define priorities in stages and work more closely with the team.

The product owner should learn Lean Startup, customer development and other modern approaches to creating products.

For the Scrum-master, the set of competences is wider: facilitation, conflictology, group dynamics, coaching and, of course, Agile practice. Rather, these are skills from the field of psychology, so their lack in training managers is felt.

- Does collective ownership of the code really reduce the company's dependence on “star” developers? Is their motivation falling?

Collective ownership of a code is feasible without flexible methodologies. There is enough agreement on code review and other formal rules, and developers can act atomically.

Often, the company itself provokes the "star" behavior of engineers: at first glance, it is more profitable for it to fork out for a superspecialist and entrust him with a whole direction with his full responsibility for the result, than to collect a team of average people, systematically reduce risks due to mistakes, increase their professionalism.

This is a dilemma: either short-term or long-term success. It seems that hiring a "star" is good for business. But what will happen in three years, in five, seven years after such a pro joined the company? It will become indispensable. And with at least three negative consequences.

First, such a person has almost no free time , and the company, by and large, is indifferent. Her logic: "We pay you a huge salary not for you to rest." Getting into a similar situation, people quickly burn out, fall into cynicism and try to extract maximum benefits from their position.

Secondly, an indispensable employee begins to fill the priorities of the company. Instead of embodying the intent of the business, he can independently make decisions about what is necessary and what not to do. And there are no levers of influence on him : for several years he learned everything about the product and system, and the horror is that, as a rule, no one else knows. Such specialists will carefully protect their knowledge, their expertise as insurance against dismissal or lower wages.

Thirdly, the achievements of such a person cannot be “scaled” . If you have conceived to expand the development team, be prepared for a big turnover: newcomers will be rejected, “hazing” will flourish with a terry color, since it will be unprofitable for the “old men” to share experience and knowledge. It is hardly possible to speed up the development either: everything will be limited to the performance of an individual and indispensable Vasi Pupkin, who is satisfied with everything and who is not going to change anything.

- What to undertake, to still go to the team approach?

• Take the risk that we will inevitably lose part of the current stars team: not everyone will agree with the new approach. It's unavoidable.
• Change the structure of rewards. For example, to introduce bonuses for writing documentation or for training new employees, so that this will gradually become common practice.
• Among the "stars" to find those who want to grow, and help them master the skills of management, facilitation, coaching. Open them new horizons. Not everyone will agree to this. But those who agree will be the best adherents of the new principles of work.
• Blur the culture of "hazing". Including to pull the "stars" out of their usual environment, for example, forming new teams on the principle of "four or five newcomers for one old man." Plus, in such a team, you need to appoint an intelligent and skillful Scrum master who will make it clear to the “old man” that nothing threatens him, and at the same time will set the “newbies” to respect those who know more . And it is good if such a team will sit in the wrong place where the “old man” used to work.

Remember, we are dealing with the transformation of corporate culture, and this is a daunting task. As Peter Drucker said, "culture eats breakfast strategy." No matter how perfect a formalized strategy you propose, it will not be possible to bring it to life, if people have "not accepted" the corresponding behavior. To better understand the issue, I advise you to read the book by Daniel Brown and Itse Kramer " Corporate tribe. What can an anthropologist teach a top manager ? ”

The material was prepared by the team Mail.Ru Cloud Solutions .