Methodology as a Constructor: Assembly Instructions

    Only one toy model can be assembled from the modern LEGO designer, for example, an airplane. Customize? You can swap pilot seats - that's all customization. About 30 years ago, from the designer it was possible to assemble almost everything, from an airplane to a truck, with the same number of parts as in modern ones. The creators of most modern methodologies in childhood played the old Lego. Those who now use methodologies have already played in modern. The difference in engineering practices is huge.

    Under the cut Philip Delgado ( dph) will talk about the engineering approach to the formation of the methodology. All projects and teams are different, and leaders are unique. Fit one methodology for all will not work - there simply aren't any. We'll have to take a designer and build something unique from it. In decoding one of the best TeamLead Conf reportsthere will be no secret secrets of the Shaolin monks - only platitudes verified by experience. We are waiting for a catalog of details of the development methodology, what to look for when designing and implementing it, and the rules for rebuilding methodologies. For all ideas, real examples are given from Philip's experience. During his career, he tried everything from Visual Basic to hardcore SQL, developed the largest bookmaker engine in Russia and Yandex.Money, and now works on loaded Java projects. She regularly gives presentations at various conferences, including HighLoad ++.


    A few years ago, I once again came to a project to create a payment system from scratch. At the very start of the project there was nothing: no developers, no processes, no productions. Where to start work if there is nothing? Immediately introducing something is strange and even stupid. Therefore, the first step is to understand what is actually needed from the technique.

    Kent Beck, at the end of his book on SCRUM, wrote:

    All methods are based on fear. You are trying to develop your habits that will help you prevent your fears from becoming a reality.

    Therefore, the first thing to do is to find out from the business what it is afraid of .

    Typically, the business is scared for the whole project: scary to do too long or not to do at all . Technologically, he is scared for reliability and safety . In our case, these fears are justified: the payment system is counterparties, money and serious obligations.

    Different fears lead to different methodologies. Fear of overpaying leads to hiring cheap developers that are easy to change - it's SCRUM. Fear of error leads to GOSTs or RUPs with a bunch of formalized documents.

    Developers also have their own fears: write unsupportedor do bad . Unfortunately, almost no one is developing methodologies under the fear of developers. Only XP briefly mentions that developers are afraid to do poorly, let's try to help them do their job well.

    In addition to fears, the business has wishes for what purposes to optimize processes:

    • quickly;
    • cheap;
    • predictably;
    • in a controlled manner;
    • qualitatively;
    • scalable
    • HYIPOVO.

    Choose any one option, and maybe, perhaps, someday, probably, if nothing happens and Mars converges with the Moon in Capricorn, you will succeed. Most of the wishes for optimization are also about fear, but in a different wording: cheap - about fear of overpaying, controlled - about fear, do not do it, predictably - about fear there is no time.

    Usually a business wants everything at once . When collecting requirements, adhere to the presupposition "the patient always lies." When a business wants everything, he lies. Try to understand what the business really wants and try to sell it to him. This is not the most standard set of skills for a team leader. But if you do not know how to find out the real requirements of a business, then you need to find a person who can.

    In addition to the wishes of the business, you need to find out the significant limitations .

    • Tight deadlines . In my case, there was no hard deadline, for example, the Olympics, when there are only two options: either to be in time or not.
    • Strict contract . If you work with a state-owned company, then the contract is something that must not be violated. Everything else can be done as you wish. This greatly affects the technique.
    • Regular shipment . You need to constantly roll out new features, this is important for business.
    • Certification: CB, PCI DSS . This is the main limitation of the design of the payment system. The biggest risks and concerns are related to certification of securities, PCI DSS and others.

    It is the essential limitations that distinguish, for example, FixPrice processes from Time & Material processes.

    In our project of the payment system, as it turned out, it was scary to do too long and not to be scared, scary for reliability and security, but it is advisable to do everything quickly. At the same time, there are no productions at the beginning of the work, there are no developers, but there are specialists in the subject area (for example, me). Only large and quite independent from each other blocks are clear: processing, clients, integrations, back office and front office.

    Having figured out the goals and limitations, you can begin to build a methodology, to understand how exactly we will develop the desired system - at least at the very first stage.

    We are building a methodology for starting a project

    But what is a technique? What do we want to build in general? The answer to the questions is a beautiful picture of Alistair Cowber with a bunch of points.

    Three things are important to us from this picture in the first place: people - those who do; processes - how they do; and artifacts - what needs to be done. We don’t have people and processes yet, so we’ll figure out what artifacts we need.

    Starting with artifacts is a good pattern when designing a technique ,even if people and processes already exist. It is advisable to begin the design of artifacts “from the end”, with the delivered value, from those artifacts that will be laid out on the sale or sent to the client. Why is it better this way - a separate question for a separate article. If you know the answer - write in the comments.

    Choosing Artifacts

    We take fears and understand what artifacts which fears close.

    The fear of “working on a project for too long” is saved by a long-term plan and a milestone fact . From fear for reliability - autotests . For fear of "not doing" - raise the "almost combat" stand. We will demonstrate business progress to it . So you can immediately see what is and what works, and in a pinch, we’ll post at least some result.

    We form processes

    We are at the beginning of development, so there is no time and reason to create complex formalized processes. So we simplify all processes and focus on facilitating communication .

    As a result, there are exactly two processes: to figure out a big task - to think about a solution, and check what has been completed . These processes are long, research and little connected with each other, which leads to appropriate development practices.

    To make it fast - we hire cool employees. But cool specialists do not go to a payment system that is unknown to anyone on the market. Somehow it worked out, but the solution to this issue is a separate discussion. By the way, write in the comments how you solved it at home and did you decide at all?

    Retreat: about hiring

    When hiring, they usually look at the standard job descriptions and the usual gradations of the candidate levels, drawing about such a map of the roles in the team:

    But standard descriptions do not allow us to understand the need for a specific person on the project. I usually try to keep several different maps in my head for different projects, highlighting different roles and competencies that are important for the project. For example, technological .

    Troubleshooter . This is a person who can dive into a legacy code with some kind of bug without documentation and tests for 2 days, and emerge with the phrase: "In this line, replace + with - and it will work."

    And it will work. People like the four-leaf clover are rare. Unfortunately, the market does not value such people, it is difficult to explain to the business that a troubleshooter is critically needed and deserves respect and a big salary. As a result, most of them go to team leaders, and this resource is exhausted. It remains only to promote the usefulness of such specialists, and perhaps after some time the situation will change.

    Integrator This is a person who knows how to create something integral from several different components, libraries, modules. He is no longer an XML programmer, but one who understands the internal structure. This is an extremely rare skill, which is usually very much in demand in real development.

    Guru: Framework, Security, Database, DevOps. Everything is clear about the guru - these are people who can be contacted with questions on relevant topics.

    In addition, there are also "non-technological" roles, a social map of roles. An idea generator is a person who can come up with something. Critic - who can constructively criticize. Experienced - an experienced person who can say: "We tried so and it turned out nonsense." A perfectionist is a person who wants everything to be good. This is an important role. If it is not there, usually everything quickly falls into decay, because there is no one who tells you: “You got it again, everything is wrong - let's fix it!”

    If some role in the role map for your specific project is not filled, then the team will have to fulfill it.

    Therefore, think about whom to take, and keep in mind that different interviews are suitable for different roles and positions . With a seasoned senior, the interview will be quick - just find out what he was doing. You usually have to talk with a junior for a long time, give test tasks, and find out what he can do.

    The higher the candidate’s level, the shorter the interview.

    What other people do you need?

    An extrovert is one who wants and can actively communicate outside of development. We do not have exact productions, so we need a few people who can understand the end users, including internal ones, for example, our accountants. An extrovert is not afraid to go talk, find out the needs of such unusual "non-programmers" - and there are few such people.

    Critic - I first need a critic of me. This is the person who will criticize my decisions. Without criticism, I am afraid that I am carrying some nonsense. When they criticize me, I have to seriously think about the arguments, and it turns out that this is not entirely nonsense.

    Monotone Tasks Specialist: reports, integrations. I knew for sure that we will have a huge number of reports in the project. Six months to write accounting reports and not go crazy - a rare skill. Scattering this function among different people is also inconvenient, so I needed a specialist in monotonous problems.

    Do not care . This is a person who does not care what tasks to do, if only to pay. This role is extremely important for the project, because there were different tasks: monotonous, but complex, insanely interesting or not related to our previous experience at all because of the creeped out external requirement.

    Let's get back to our project. We do not need Troubleshooter, because legacy is not there yet. We needed an Integrator and a set of gurus. Security Guru is actually grown inside.

    Database Guru has been successfully outsourced. I really like the idea of ​​“taking competency in the database somewhere outside” - to find such a person on staff is usually unrealistic if you have not a huge company, and at least 5 people are required to support an important 24 * 7 database. We also first outsourced DevOps Guru, but not so successfully, this role is more difficult for external performers.

    Social roles were also filled (and there were even a few critics).


    So, we figured out the necessary artifacts, found out what people need and what process requirements. What happened, how exactly we organize the development:

    • We plan large strokes. We have no productions, so it’s impossible to plan more accurately. There is a need to create a personal account in three months - and that’s all. We carry out plans in Confluence.
    • Each is a little bit of an analyst . There are no normal productions and competence in the subject area is held by people who do not know how to write productions. Nobody taught them, you need to remove this information from them. But we have "extroverts."
    • A tracker is not needed . We have only 20 major tasks for the project - why start a tracker.
    • One branch in VCS. At the initial stage, complex work with version control is not required.
    • The processes are approximate . There are still few people, there are no communications and problems, and the project itself is unstable. No need to describe anything in detail.

    When people talk about similar, not too formalized methods, they often simply say: “ We have an agile.”

    We also got the classic "We have Agile." But I clearly understood why such a technique and why it was “agile”, and not something more specific and complex. And I (and business), this technique was quite suitable.

    An attentive reader will notice that when designing the methodology, we forgot about two important fears: fear for safety and the need for certification . Let's try to figure out how to deal with them.

    Digression: Cowburn Matrix

    In 1980, Alistair Cowbern drew a matrix of the complexity of the project .

    Vertical - the criticality of the project . What can be lost in the event of significant errors: from loss of comfort by the user to loss of life of the user, for example, if we design software for nuclear plants. Horizontal - the size of the team . Size affects the number of communications. Criticality is on the detail of these communications. All in total affects the complexity of the process.

    Alistair argues that moving right or up in each square greatly complicates and increases the cost of development. This is logical - more people require more communication costs. If more formal relationships are needed, then more communication costs are required. Those. the farther, the more resources are spent on unproductive tasks and losses.
    By the way, as a third axis, Alistair draws optimization for different business wishes.

    Let's try to place our payment system on this matrix. The matrix is ​​very convenient as a model for understanding the estimated complexity of your project, your system.

    We have a payment system, which means that in a pinch we will lose some user money. This, of course, is unpleasant, but does not lead to a sharp increase in complexity.

    But we have almost a bank, and in some cases, in case of violation of the standards or requirements of the Central Bank, a license can be taken from the bank. This is already a loss of a lot of money, almost closing a business, very sad.

    We have a team of about 20 people, so we get into the E30 square . This is bad, because a good example of the technique in this square will be the full-fledged Rational Unified Process - formal processes, many documents, clear statements. 20-30 people cannot cope with this. You have to hire 50, and the difficulty will grow like a snowball. Similar systems in such methodologies are usually written by hundreds or more people.

    What to do? Trouble? No, not the whole project is equally critical . We have only a few critical pieces.

    • Money laundering check - for which the Central Bank hit hard on the head.
    • Working with bank cards - for which world payment systems hit hard on the head.
    • Storage of personal data - for this, the state hit hard on the head.

    Let's highlight individual critical modules . We will write special practices for working with these parts of our project for them: a full PCI DSS Audit for every commit , good documentation, a double Code Review, a special calculation process and a lot more. Let only senior developers write these parts of the project.

    But such parts are few. Therefore, the Cowbern matrix for the project is as follows.

    For different parts of the project there will be different complexity of the methodology, a different set of practices. The most difficult and terrible is three people . Payment logic - person 8. Any other less important tasks, which are most of all, such as a help system or layout of a site for back office, in which the error is not fundamental, is handled most of all by people. But there processes can be the easiest and most informal.

    A large complex project may use different sets of practices for its various components.

    This is one of the big advantages of microservice architecture - the ability to prescribe a picture in which different services respond not so much to different techniques, but to different practices within the same technique. At the same time, important things remain common: planning, artifacts, a common approach to interaction.

    To summarize

    We found out the requirements for the methodology : goals and limitations. Identified the basic elements : processes, artifacts and people. They described practices : how to implement processes, requirements for artifacts, what kind of people are needed.

    This is a classic engineering design scheme: we have requirements, then we specified the architecture, and then programmed it.

    Designing methods is an engineering practice, an engineering process that is no different from programming a module.

    Stage One Practices

    A little practice to distract from theory to reality.

    Right to “Why?”

    This is my favorite practice.

    Each employee has the right to ask about any task: why do it, why do it this way, and who needs it at all?

    People are afraid to ask “why” - perhaps because in childhood they still did not answer such questions. If you have explicitly written down and repeated “can and should” many times, people do it. As soon as you start asking “why” at all levels, including business, the volume of tasks decreases many times and the motivation also increases. People understand the meaning of work and do it faster and more economically, cutting corners.

    Do not generalize to three

    Do not create a one-stop solution until there are three different examples . If you are designing three different airplanes, you cannot write the correct class that it represents on one of them at once.

    This solution is also for development - do not build universal integration with contractors, until there are three different integrations and there is no understanding where they are different. But when designing a technique, do not immediately draw a formal description of the artifact - a diagram or template - until you try three different approaches and find out what is common in them. This is a simple but useful practice that allows you to not create redundant abstractions out of the blue.

    IDE Driven Development

    JetBrains Almighty has given us a good tool - let's use it to the fullest! Implement what is easy to do and verify in the IDE.

    Do not use anything that is not supported in the IDE.

    I respect aspect programming. But I will not use it in the project until I can easily analyze my aspect code without leaving the IDE and without pressing more than two buttons, because this greatly complicates the support. Once this feature has been added to the IDE, aspect programming is usable. The more IDE features - the more opportunities in your work: faster refactoring, code replacement, error analysis, more complex logic management. This avoids unnecessary: ​​testing, processes, communications and even documentation.

    In our project, we added a lot of special strange code, for example, so that in the IDE it would be possible to look at the call stack with one button for an actor asynchronous model. This is usually not possible.

    The simplest use of the IDE is to write a set of settings instead of a long standard for code design and approve it as a coding standard.

    Friday cake

    In the new team, in which people are still not very familiar, it is not possible to conduct classical retrospectives on Scram's models. People do not understand why this is. A person thinks: “Why did I come to this company and what am I doing here?” It’s easier on Friday to buy a cake for your money and drink tea, while at the same time discreetly figuring out problems in the project. People are more likely to open up when they are fed something sweet in the evening and informally. You can beer, but it really depends on the company and the team.

    After 3-4 months, you can move from cakes to normal retrospectives and reflection. But starting with the practice of the Friday cake is more convenient.

    These are all practices for specific processes that can be used. But this does not mean that they should always be used. In general, there are no practices applicable in any cases, you always need to think first.


    Using the method described above, we made the first version of the system. And then there will be a launch - going into production, showing the project to the investor and customer, the first real users and real money.

    In our particular case, integration with contractors and beta testing were required with a small number of external, but very demanding users. Here begins a little hell.

    Many unexpected requirements - our plans are faced with reality.

    There are many urgent requirements : "We need to fix it tomorrow, because today our important counterparty found a bug, and if we do not fix it, he will be offended."

    Frequent product updates - every day, and the more often, the better. Scope of tasks is generally unpredictable. But there are technological pauses - since there are no users, we can, for example, cut everything clean at night.

    The previous technique does not work at all under these conditions. It is clear that something new needs to be done. Therefore, we again went to the business to find out his fears.

    New fears

    As you might have guessed, now the business is scared only for reliability - for the fact that everything will fall at the wrong time. And improvements need to be done quickly: quickly fix bugs, quickly fix integration, quickly find problems.

    Well, we have new processes: urgent laying out and fixing errors. Based on this, we make a new technique. New practices are emerging.

    • Normal tracker . We have bugs, and if before this the tracker was not needed, now it is necessary.
    • Ручное тестирование. Мы не успеваем все покрыть автотестами, и есть вещи, которые сложно покрыть автотестами, например, изменение цвета кнопочки под чей-то корпоративный стиль.
    • Командная работа. До этого можно было пилить 3 месяца свою большую мега-фичу, а потом аккуратно смержиться, и все это были отдельные интерфейсы, отдельные сервисы, поэтому проблем не было. Сейчас если упал продакшн, его поднимают все.
    • Мотивация. В этот момент люди точно будут перерабатывать, иногда выходить в выходные. Чтобы просить людей разбираться с багами ночью в выходные, их надо как-то мотивировать — хотя бы премией или тройной оплатой переработок.

    We launched a technique that can be called a one-day SCRUM , although it has nothing to do with SCRUM. In the morning we gathered for planning, distributed tasks, performed, and in the evening laid out a new version and conducted a retrospective.

    And so every day for about a month. In a month passed 20 sprints . Of course, this process has nothing to do with SCRUM Sutherland, although it is somewhat similar. But in our case, this technique worked.

    Launch stage practices

    Two practices were especially useful to us.

    A checklist is a ritual that unloads the brain and makes it possible at 3 a.m. to do a calculation on production and not to drop it.

    The checklist allows you not to think.

    We did a lot of checklists on various topics: how to check the PCI DSS code, how to put a new service on production (including messages to contractors and the operations department and other organizational details, which system administrators prefer to forget about at night), which should be checked for potential problems with a database or with something incomprehensible in monitoring.

    Duty . This is not formal duty such as “I'm sitting and waiting for the server to fall”, but an understanding of the plans of the people in the team. If it turns out that half of the team on Friday, September 1, goes to the line to their children and takes time off for this time, we will know in advance which team can still be near the computer. If a person is asked to change plans in advance, he can change them. If you have shit happens right now, and the employee is in the theater, he will be unhappy if he is torn off. If he is asked to postpone his trip to the theater for a week, he will most likely agree, especially if this is compensated .

    So we went into production, we lingered there, settled down, and the third stage began - the normal development of the project, when everything is already working, but we must actively move forward.

    Project development

    The third stage - the project becomes a product . There were fears for reliability and safety. There was a fear of overpaying . The project is and brings a certain amount of money, and the less we spend on it and the more money it brings, the greater the benefit for the business - it does not want to pay too much.

    Another new fear is to do unsupported . Now the team is growing, the "old" people are no longer so important, you need to somehow increase the bus factor - we are a normal business, everything should be serious.

    And now you need to do it predictably and scalably . Scalable not in the sense of increasing the load, but in the sense of increasing the number of developers and teams, because business and tasks are growing.

    It turns out a bunch of new processes.Short-term plans and regular calculations , because you need it predictably. Documentation , because it’s scalable so that new people can learn and integrate faster. Normal performances , which are easy to cut for not very expensive developers, and regular shows, because it’s scary to do too much. Style guides and code review are not needed so that developers do not do anything totally bad, but to make code easier to maintain.

    This is a familiar set of processes, you all regularly use something like that. But how to choose specific practices for these processes?

    Practice Choice

    Consider Planning poker . It’s good practice to create a “ short-term plan” artifact — let's use it. But first, let's figure out what is needed for this practice to work. Planning poker works well under the conditions of a sorted and high-quality backlog, short tasks and a generalist team .

    These are normal conditions for introducing practice. There are other conditions for the implementation of practices:

    • single office;
    • product owner at hand;
    • fixed plans;
    • rare updates.

    Well, we have a normal backlog, short tasks, all generalists - but why then distract the whole team into planning? You can entrust planning to the team leader, he will scatter all tasks in 2 hours and save 10% of the total team productivity. Why do we spend so much time?

    Let’s try to understand why we really need Planning poker - since not only to create a short-term plan, what are the real goals of the practice? In my opinion, the main goal is to give developers a sense of responsibility for the ratings given to them . Typically, developers rate the complexity of any task below real. But in the case of planning poker, they themselves committed to this assessment, they are uncomfortable not to live up to their promises, and they begin to work at night.

    In general, there are many different hidden goals for popular practices: reducing the cost of labor , increasing the rate of exploitation , reducing dependence on specific people. In general, the whole Agile is about increasing the operating standards of developers, which is why it is in demand by business. Businesses like people working faster and cheaper.

    If programmers had a union, Agile, SCRUM and XP would be banned.

    It must be understood that practitioners have an external goal , for example, to create a short-term plan, and an internal one, for example, to reduce the rate of exploitation. Every time you hear about a practice, think about what its internal real goals are. Will these goals always be fulfilled?

    Homework. There are wonderful standard practices: corporate dining room, pair programming, project time tracking, free coffee. Find their internal goals and think about how else they can be realized?

    Picture of the world

    Suppose we have a great senior at Planning poker who performs the tasks more than anyone else in the team, but at the same time at Planning poker he always puts one:

    - Everything is simple for me, and in general I do not want to deal with this your bullshit, let me program!

    In this case, Planning poker will not work. It only works if the opinion of the team about it is important for each developer . This practice is effective only in such a picture of the world.

    In different methods you can find traces of different pictures of the world of their creators:

    • changes are unexpected and unpredictable;
    • discipline should be;
    • people are responsible for their words.

    Track pictures of the world in the practices you use.

    There is a simple criterion: if you cannot isolate the picture of the world, then you agree with it.

    Developed system practices

    How often do you programmers write in Jira the time they spent on tasks “off the shelf” at the end of the week? How often do they regularly incorrectly fill out some tricky application for something? How often do you forget to answer letters in correspondence?

    So that all the nonsense is not watched by a team leader who has expensive time, hire a project secretary . In fact, this is a junior product manager - a person who does not cost very much money, but who can take on most of the quality monitoring of bureaucratic artifacts , or even create them.

    Sometimes a business asks to keep track of when programmers come and go - let the secretary keep an eye on this. This will save you a lot of money and development efforts. They love being taken care of. If the secretary will serve them a martini - it's fine!

    Review before code. I regularly hear how a person was given responsibility for a big feature, but he did wrong and needs to be redone. Let's review the code before we write it . Before writing code, an employee at Jira describes a plan for solving a problem in two lines or two paragraphs of text. Reviewing these two paragraphs is quick and easy, but global errors are caught early on, especially if you have a team lead or an architect.

    In addition, this practice allows the team leader or architect to be aware of all the changes in a large project. He reads not a crooked code, but two paragraphs about what is generally happening in the system, and quickly catches people by the hand. This is especially true for critical parts of a product, such as payment logic.

    How to change the methodology and not kill the project

    So, in 9 months we changed 3 methods: “We have Agile”, one-day SCRUM and Kanban. How to make sure that you do not lose resources? How to change the methodology at all, and not kill the project at the same time?

    We managed to change the methods so that some developers did not notice the changes at all. Nobody told them about this, they work, and the methodology is different!

    The main thing is to understand when to change.

    If you understand why. Often the methods are changed, because a new technical director has come who wants to redo everything. This is a bad reason. Better take the old one and rename it - everything, the technique is different, it’s better. If you can not answer the question why, it is better not to change. I generally like to ask why.

    If you thought "how." If you understand how you will come from point A to point B, then change. Until you come up with - no need.

    If satisfied "how much." Changing a technique is almost always an expensive procedure.. If you do well, the replacement will cost several man-months of the costs of team leaders, HR, Jira customizers. If it’s bad, a few months of the whole company’s work. I often saw the transition from Kanban to SCRUM, then back, each of which cost a month of work throughout the development. If you are not ready for such costs - do not start.


    We start in advance. For a small team, preparation begins a month before the shift.

    We draw User Stories. The same approach as in application design. You use User Stories when describing requirements, I hope?

    For instance:

    • User Story : as a developer, I want to find my next task and proceed with its implementation.
    • Acceptance Criteria: как разработчик я могу посмотреть все мои актуальные задачи и оценить срочность и приоритет задач.
    • Exceptions: если задач нет, то разработчик знает, кого спросить.
    • Links: сценарии подготовки краткосрочного плана, в которых видно где брать следующую задачу.

    In this way, go through all of your main activities that arise within your methodology and write User Stories.

    How can the manager see the effectiveness of the plan? How does a top manager understand that everything is fine? Write User Stories, then add specifics: make a dashboard for users and for top managers - Acceptance Criteria passes, everything is fine.

    When you already have User Stories, you can start turning them into practices.

    Replace all roles with real people . A real person always knows more than a role. Then you will immediately find the bottleneck. For example, all your User Stories use one specific person, although he is simply in different hats, in different roles. This is bad - figure out how to unload it.

    Reduce artifacts and communications. If there are too many of them - each User Story suggests its own artifacts and communications - something needs to be done with this.

    Look for bottlenecks . When there is such a story map, you can start to do something with it.

    Choosing Tools

    The tool identifies features . There is a popular opinion that tools are not important, or any tool is suitable - this is nonsense.

    If the tool is inconvenient to use, they will not be used.

    Moreover, vendors always lie. If they say that their tool can do “1, 2 and 3”, then most likely they cannot do “1”, “2” sometimes, and “3” it does, but it’s very bad. Be sure to check everything.

    We are actively discussing

    Without an active discussion of the technique, you can forget about some important functionality, important User Stories, and offend someone. The offended person will sabotage the implementation of the methodology : he was initially offended, forgotten, no one spoke to him what he needed.

    At this stage, people may show negative previous experience from the introduction of other techniques.

    - Ah, nonsense! We already had this and nothing came of it.

    To avoid this, collect people's pains, ask what is wrong. Accurately record and demonstrate what you recorded - so the person will understand that they heard him.

    Do not repeat negative experiences . Retrospective did not go? Now this is a “Friday cake”. Standups at 7 am did not go? Now this is “charging."Giving different names to the same practices so that people do not associate their past negative experiences with them often helps.

    Unfortunately, there are no universal solutions. Build on your situation.


    The main value in IT management is respect.

    We save someone else’s time . If you need to transfer tasks from one tracker system to another - write a script, hire Mechanical Turk to do it for you. Solve this problem so that the developer does not transfer all his tasks from one system to another for a week - this is a manifestation of respect.

    We help with the transition . If we introduce a new practice, we sit next to a person and help him understand the new system. We prepare instructions in advance.

    We describe specific actions. We make very specific documentation, just according to our User Stories: “We need to take on a new task. How to do this is written in the documentation - you open such and such a page on the wiki, in it you read so-and-so. ”
    We introduce gradually - not all practices at once. Our developers did not notice a change in methods, because we did not implement all practices at the same time. When we wanted to smoothly switch from a one-day SCRUM to something else, I didn’t do retrospectives every day, the tasks appeared a little longer, the daily morning meetings quietly migrated to a more standard stand-up. It seemed to people that everything was going on gradually. Then the practice just changed quite significantly. About some things, of course, I told them: "Now we will slightly change the process of working with Jira - it will now be like that."

    The paths trample themselves. Do not prescribe a hard workflow right away - let people find the paths themselves. It’s convenient for them to transfer the task in the tracker from state to state, even if they transfer it, and then you will fix it. Immediately to predict what will be convenient is difficult, and to prohibit the requested transition is easy. But then you have to suffer for a long time to get everything back.

    KISS . Make it simple, at least in the beginning. Do not overcomplicate.


    We reserve resources in advance for the transition process, because it is expensive . The transition from one technique to another is a lot of money. Reserve your time and time for people who will edit bugs in your tracker, in your workflow, in calculation procedures. If there are no resources, and at the same time some kind of rush, everything will turn out badly.
    We fix errors as quickly as possible .


    Projects are different, people too - everyone needs completely different techniques ! All happy families are equally happy, all unhappy - in their own way. The same with projects - there are no two identical.

    Creating a technique is an engineering task. Exactly the same as programming and designing system modules. That’s how you approach it. You know how to solve engineering problems well - so use all your knowledge in this new practice.

    Change of methodology is a classic SMART project . Use everything that you know about project management: define success criteria, check at the end of compliance with the tasks set, remember the limited time, etc.

    My personal manifest

    People are more important than processes , because processes have to be done for people. If the company has an average age of 50 years, and they came from the military, and you are trying to quickly implement Kanban right away, most likely it will not take off. People are just used to something else.

    The main advantage of a programmer is his laziness. Build processes so that people spend even less time on them, and developers are the first to run to implement them. If people do not seek to implement processes, then they do not understand why.

    It happens that some practices are difficult to implement, as they are difficult to understand. Sometimes it’s easier to change the practice, perhaps it does not correspond to your tasks or your people. As a last resort - change people, but it's more expensive than changing practice.

    Result is more important than habits. The most terrible habit is the habit of hearing about a new tool, bring it home and immediately use it. Cargo cult is a terrible habit to fight against. But the fear of changing some kind of practice because “we always did that” even if it is already ineffective is also harmful.

    And sometimes in general the tasks are so diverse that habits become dangerous. For example, when communicating with living people.

    Persuasion is more effective than orders . The best motivation is to understand the meaning of your work and share it. Developers like to make life easier for users, save companies money and simplify their lives - so tell them about the goals of their actions. Learn to convince.

    All three principles are my personal picture of the world. If you have other presuppositions, you probably need a different methodology for constructing techniques.

    In the TeamLead Conf program committee, we are also more familiar with the old Lego, so we select cubes into the program from which you yourself can build the processes that suit you. For the autumn conference in St. Petersburg, a set of 15 parts has already been assembled , but we are still accepting applications for reports - write .

    Also popular now: