Agile is not a development process, but an approach to creating a product.

    At Promsvyazbank, we are actively moving from waterfall-channel teams to ejail products. Somewhere there were a couple of lumps, somewhere you can already change a rake ... but as a result we have gained a lot of experience related to the Edzheel transformation. In this post we want to share the experience - suddenly you will discover something new.

    How does the idea of ​​transition to edgyla

    Usually an ideologue appears in the company who infects everyone with the Ejile virus, telling about the values ​​of teamwork. Everything will be simple and fast, the result will amaze the imagination, the money will flow into our pockets, and all the staff will be happy to roll on the ottomans with a cup of coffee in hand and an endless bowl of cookies, he promises.

    In order to reinforce the thoughts on edzheyl, they invite experts who predict a couple of hundred days of work on the product, and, as a result, the “swelling” of the product, its demise. And after, perhaps, the demise of the company. HTC and Blackberry are examples. How not to repeat their fate? Consultants offer a recipe that has been used by such giants as Google, Amazon, Apple - namely, flexible ejail.

    What usually happens during transformation

    And now you have learned all the necessary phrases and phrases to have the right to bear the proud name of PMI Agile Certified Practitioner: “stand-up, grooming, demo, team, board, stickers, went all forest with their approvals.” You are professionals in your field, you know what works and how, you know all the new necessary concepts, activities and processes. It remains to conduct an agile transformation. We give a list of typical errors.

    • There were development departments, and did ejyle teams.
    • With a flick of the wrist, the endless queue of tasks for change requests in Jira was turned into backlog from the RFC.
    • If earlier resources were allocated centrally to the task, now they have done the distribution of tasks to the developers.
    • “What will this developer do?” And let's take this task in backlog, he will be able to do it. ”
    • You set a goal to leave the evaluation of tasks in one month of work. In response, the developer says: “OK, let's start doing this sprint, and next we will finish.”
    • The task is not coordinated with the security service and lawyers? Let's introduce regulatory holidays and ignore this point.
    • Tasks distributes the boss? Then we make an ejail, a flat structure, but “I will still be the boss.”

    What we get in the end?

    The structure has not changed. Chiefs assign tasks to subordinates. People have an explosion of the brain, many leaders, these leaders simultaneously set different tasks with dead points. Tasks were simply measured by sprints, not months.

    What to do - it is not clear how to do - it is not clear. No documentation! The whole team sits at meetings all the time, where old seasoned technologists and programmers come. They look at the staff in the team as if they came to the zoo to observe the behavior of gibbons in the flock.
    Scrum Master talks about Definition of Ready and Definition of Done. Everyone understands that this is important and necessary, why do developers resist?

    At that moment, as luck would have it, an important task arrives with dead leadership deadlines, and the young, still weakly standing Ejile perishes under the onslaught of enemies and zombies.

    So how should it be?

    You can not blindly follow the patterns of successful companies. It is easier to explain through an analogy - for example, through football. Imagine that you are a coach, your team loses, five minutes before the end of the match. There is an example of a flawless plan that is used by the famous trainer Ernesto Valverde. According to him, striker Luis Alberto Suarez bursts into the penalty area, he is demolished, the judge appoints a penalty. Lionel Messi comes up to the ball and punches the upper corner exactly to the farthest from the goalkeeper. Impeccable plan. But you are not Valverde, and you have no Suarez and Messi in your team. Everything. You lose.

    In addition, we begin to cling to processes, forgetting why we implement them in our work. Therefore, I would advise you to formulate a goal and hang it in a prominent place. How to set goals, you all know. The goal must be concrete, measurable, achievable, meaningful and with a time frame. What does all this mean in practice?

    In practice, this means that the most important in this whole process is the Client. So be sure to take the time and figure out who your real customer is, who brings you money. Describe his person. Not all companies answer to this question is obvious.

    For the client, you make the Product, moreover, such that after using it the client remains happy. The product must be:

    • useful, that is, to solve a significant customer problem;
    • quality, that is, meet customer expectations or exceed them;
    • made and offered on time, not in a year.

    The product in turn creates a team. In fact, the Product and Team are closely related. As the team of drowned men on the sunken ship in Pirates of the Caribbean said: “Part of the crew is part of the ship.” A good product without a good team can not exist, as well as vice versa. And this is the main reason why most of the attempts of the Ajile transformation are falling apart. In order to avoid this situation, we in Promsvyazbank started the launch of each team by choosing the product line and the owner of the product.

    Much has already been said and written about how a product owner should be. All this is true, the main difficulty is to find the person you need. This is what the product owner does:

    • sets a goal;
    • describes high level backlog;
    • thinks over KPIs, by which it would be possible to constantly monitor the approach to the goal; including we do not forget about the happy client;
    • calculates how backlog tasks affect KPIs.

    The product owner is not the person who is able to efficiently broadcast the priorities of other people, but the person who wants it. He wants to make the best product for the client, make it the way he sees it every future day.

    A development team is responsible people who can independently and independently develop a product. The team must have all the competencies that are necessary to achieve the result. External dependencies need not be managed, they need to get rid of the inclusion or training of the right people in the team. Definitely not need to do a team with redundant roles. To agree, the team must be as small as possible. Mentally remove the role from the team, will it become worse without her?

    The best question to the team at the start: “Do you have enough of all to reach the goal?” And the most effective practice of forming the composition of participants is self-design, when the employees themselves determine who they should work with and with whom. We tried to do so at the start - when we offered to do the rotation ourselves, it turned out well.

    Now that the team is there, it must strive to ensure that at the end of the sprint there is an increase in the “goodness” of the product with a clear business profit.

    A good allegory of team work in Scrum is competition on dragonbots. The drummer sets the pace for synchronization of collective rowing, and at the beginning of the boat there is a helmsman who sets the direction. Our product owner manages the vision of the business direction, and the scrum master helps the team to keep up the pace for simultaneous work on all fronts. A drum is a scrum board, a common meeting place for team events.

    The main mistake here is an attempt to assign a scrum master or even combine several roles in one person. Perhaps in the mature teams it will turn out, but this is definitely not your case. And even in mature teams, the product owner can never be a scram master at the same time. You should find a scrum master, and not appoint someone from the people who came to hand. Such a person will help the team become more cohesive and effective from sprint to sprint.

    For the development of engineering practices, you need to create not a department that will impose the right things like unit-tests, but a community of developers interested in this. If such initiatives are born from below, they will be supported at all levels.

    Team work should be transparent to all interested parties. This is the duty of the team, and its significant advantage. The team builds its work process independently, and all issues that may arise will also be resolved independently in the process of its maturation.

    And the last tip: use simple tools. Any fields and processes in Jira easily replace the physical board with a set of magnets.

    What have we come to?

    We regularly have new product teams. They do not discuss Edzhil, and make new functionality. Thanks to the people in the teams create products that are useful and convenient to customers, and the bank - profitable.

    Also popular now: