Key skills of a successful Agile team or how to make Agile work?

    Dmitry Lobasev (lobasev.ru)


    Let's dive into the mechanics of flexible processes and think together how to make sure that, for example, you come from the conference and as a manager say: “So guys, everyone Kanban from Monday!” Or “Everyone Scrum!”. And the guys are looking at you - well, what is their choice? They said Scrum, then Scrum ... They go, do something, try to do Scrum, do some rituals, dance near the blackboard in the morning, go around, do something else. But something is not working.

    My report is dedicated to this. Let's look at the mechanics of Agile processes - how to make sure that it still brings value.

    Here's how it was intended:



    Well, and it turns out at the output:




    Dmitry Lobasev

    A couple of opening words. About myself. My name is Dima Lobasev. For the past 5 years, I have been helping companies make processes better than they are now.

    We have to work with two types of companies:

    1. which have a cascade model, i.e. waterfall,
    2. they have no process. They say that they already have Agile, for example, or they have a waterfall, although in fact, of course, there is a process adafat ...

    Look how interesting the industry was developing, a couple of key points:

    In 1970, a cascade model was invented. It looked something like this:



    i.e. the customer comes to us and says: "Guys, gash the product." We: "Well, now we will collect the requirements, design, develop, test, roll out, and you will be happy." Right?

    But in fact, the waterfall looked like this (this is the original pdf, you can download it on Google):



    Winston Royce said that it is actually impossible to make a good, high-quality product in one pass. It is necessary to make such, at least, two passes.

    Those of you with a waterfall, do you do the same thing twice, starting from analysis and ending with testing before laying out? Few do.

    Well, it turns out on the output:



    There is such a Max Dorofeev video on YouTube, this is a screenshot from there.

    The process looks something like this. For some half of the time some people generate some kind of crazy documentation. Developers then look at it all if they look. They are a little shocked. Testers are crying. In my practice, it is always very sad for testers, because not only did the guys do not quite what was written, they also did it for a very long time - we did not lay down what buffers between stages, anyway, our development takes longer than we wanted. And the most interesting thing is that they are testing about what? .. There is even such a term as “testing about requirements”, although the customer already understands that there must be something different.



    The following was this:



    RUP (Rational Unified Process), based on the cascade model, appeared in 1995, and Scrum appeared. In the same year, the industry split into two parts.

    There were people who believed in RUP and a cascade model, tightly regulated processes: “Let's make 33 roles, describe all the processes, procedures, follow them, and then we believe that then our project will be highly likely to be made on time, within budget, with the right quality, etc. ”

    And there were people who said: “Damn it, it will never work, because no matter what universal process we come up with, the contexts of projects are always different. Even within the same company, different projects have completely different contexts, because people are different, technologies are different, customers are different, the products themselves are different, etc. How can one process suit everyone at once? ”

    And since 2015 is now, and here we are talking about Agile, it looks like the second guys won. A sprig of flexible processes. Why? Because in 2005 RUP successfully rested. Not that it couldn’t be used or anything else. It just stopped developing, its last fourth version was released, and in 2012-13. one of its authors, Ivar Jacobson, wrote on his blog that “Guys, sorry, was wrong. In the modern world, RUP does not work, it is too unified, and this ruined it. ”

    In 2006, Kanban appeared, in 2009 - DevOps. These are all the nuances.

    The idea is this: since 2005, there has not been a single methodology in the industry that describes consistently what and how we should do, which would become the industry standard. All that appeared - XP, Scrum, etc. - these are all toolkits. These are all process frameworks that you can take as a basis and around which in your project team you can build your own process - the one that you need at this particular moment in time.

    Let's look at an example command.



    What is wrong with them? Everyone is smiling. Well, people at the bank work. Someone is sitting on the side. You look in your teams, if you have distributed teams, do you have it, does it appear or not? Guys from Moscow, and this one came from Yekaterinburg on a business trip. Therefore, he, as it were, feels himself with them in not very close relations, although they are working on the same project.

    So, there is a project team that somehow works, there are some problems, some fakapchiki, we work on weekends, the customer is not always happy with us, we are processing something. And at some point, someone says, “How long?” Or a business comes, for example, and says: “Guys, you can’t work like that anymore, let's start changing something.”

    There are, in principle, several possible options for what to do. See, as is usually the case in practice:



    1. we introduce a ready-made approach, i.e. we come and say: “Now you are doing this, this and that.” This is the first option.
    2. the second option is to try "something fashionable." Well, everyone says Agile, Scrum, Kanban, etc. It’s necessary, like, to take and do.

    And what is the output?

    See, does it happen or was it with you? Scrum example:



    Developers meet at the blackboard and say to one another: “Yesterday I hunted wild hairy mammoths. Today I will hunt wild hairy mammoths. As if, there are no problems. ” Another developer repeats the same thing, because this is the ritual that Scrum tells us that we have to answer three questions on these morning stand-ups. They talked and parted.

    Is there any benefit from this? “I did the Jira 125 task. Today I will continue to do this task. And I have no problems. That's it, well done. " This is an example. Is there even a name for this - probably they heard a cargo cult? When we perform rituals without understanding why they are needed.

    One more example. In Scrum, there is such a thing that everyone usually hammer on, because "it is clear that this, of course, is very good, but we do not really need it." But for those who don’t score, there is such a thing:



    Retrospective. The iteration ended, we met, one says: “Damn, it sucked.” And others: "Yeah." They looked at each other and parted.

    Or there is still an evolution of retrospectives. At first they just parted, then, if they met again, they looked at each other: “It wasn’t cool, there were a lot of bugs. What do we do?". And everyone is dumb, not understanding, but what can they do with a lot of bugs? And someone says: “And let's write better code?” And all of them: “It's hard to argue, let's.” And again they ran away - to write better code.

    Did such a retrospective help? Probably not very. Because it is not clear what this means - a “better code”? “Let's work better” - from the same series.

    Is there some more. In some companies, I observed the option “Declaring values“ from above ”.



    Imagine that some manager, a functional leader, for example, the head of the IT department, listened to a special report in which everything was cool, the frameworks were in the company, everything was going to the office and said: “Guys, you have to share Agile values , you have to be like that, innovative, etc. ” Here is something from this series:



    The guys are looking at him ... And this does not work ... He does not understand: "But how so? We are for Agile, we are for these values, people and their interactions ... We go all the time ... Guys, you should be responsible, you should think for the business, help it, etc. ”

    The problem is that it’s not enough to say what needs to be done, you also need to help people do it.



    And the idea is this: our task is with you, as people who, one way or another, participate in the implementation of Scrum, Kanban, anything so that people - our project team - understand why and why they should go to stand-ups, retrospectives, why they are forced to move in short iterations, why is it important to arrange weekly demonstrations to the customer of the results?

    And then it will work.

    Today, just, I want to point out to you three basic, key skills of a team that could be considered a cool team.



    Let's imagine the situation. Remember the smiling guys in the photo above? They rolled out something, and the customer told them: “This is complete crap, not that”, and we ask him: “Why were you silent, didn’t say it before?”. This is the situation.

    What can we do about it? In principle, there are such options:



    Agile offers us ready-made and understandable tools. Take the same Scrum - short iterations. Instead of 3-month, half-year, annual cycles, let’s learn how our B2B’s, complex, super-enterprise or B2G would be ... Let’s learn how to deliver some kind of assembly every two weeks, collect feedback from it, make a demonstration in end of each iteration.

    Business comes to us and says: “Do me good.” We ask him: "What does this mean?" He: "Well, as if all this means." It is difficult to deliver a result every two weeks, so we must learn to slice it.

    Well, there are still a bunch of different tools, you know them perfectly.

    What is the reason for this? What, in essence, these tools allow us to do in order to solve the problem with the fact that we are not giving it to the customer.

    • Find an error at an early stage.
    • Control processes.
    • Correct goals in time.
    • To force the customer to formulate the task in detail and correctly.
    • Become one team.

    But the essence ... Actually, the very first skill, one of which I want to show you today, the essence of the frequent demonstrations of short iterations of the decomposition of applications - to learn to learn as quickly as possible what we do not yet know. It can also be called risk management, built into the process of our team.



    It may seem to some that this formulation sounds silly, but, in fact, this underlies the mechanics of flexible processes. As fast as possible feedback loop.

    What usually happens in a waterfall project? For example, we are sawing a product, in a year, at best, we release a release, and then the fun begins. All wrong. Change requests begin, so people from the classical management came up with special change request management procedures, which still knock money out of customers, etc.

    Our task is to make us move in small steps and constantly learn something new about technical risks, about some infrastructure things, about business, in general, about clients, their needs, etc. Anything. The more information we have, the more high-quality solution we can come up with. And the movement in short iterations allows us to turn a little in the right direction at each subsequent iteration.

    With this it is clear - to find out as early as possible what we did not know before.

    And I have a question for you to backfill. You most likely have complex projects. But what if an application cannot be realized in two weeks, a business requirement? It is not decomposed so that there is some value in the output. What to do in this situation? It's just like homework for you to think about ...

    Let's complicate the example. We made conclusions from the fact that the customer was shown not quite what he needed. And they decided to make demonstrations often. We show him again, the output again is not quite right.



    “Bad customer” is the first thing that comes to mind. And the second thing that comes to mind is also a standard theme - "Agile does not suit us." Like, we tried it, everything in startups will work well, but in our enterprise environment it doesn’t work at all.

    What is the problem here? A very important and interesting problem. In the way we think. If you watch any video, or read a book about how the brain thinks, you will be told that the brain, in general, does not like to think. To think for him is difficult, painful, unpleasant, etc. Therefore, the brain always generates boilerplate solutions. He just picks up, looks for patterns, and your mouth spits them out. Those. You have a problem, and what will we do? Once, and instantly there is a solution, in a nanosecond. Instant turnkey solution. Well, Agile doesn't suit us, ok. Okay, come on, let's do something else. Or there: "Oh, I know exactly how to fix it, let's do it like this." And we run, do, and we get process “crutches”.



    The idea is as follows. The development industry has come to this. Let us try to make our brain think, no matter how unpleasant. And by the way, water helps, helps him not to dry out, helps him think.

    There is good practice, “A3 Thinking” is called, or a simple example of a causal tree. There are five “why?”.

    If we are faced with some kind of problem, for example, a lot of bugs in production, or, for example, something stuck, half of the users fell off something, and we lost money. The first thing that comes to mind is what needs to be done? You need to fire someone, take away the rights to deploy from someone, punish someone else, etc. And come up with some other formal procedures. In fact, you can not rush to solve this problem, and the whole team sit down and think, why did this happen?

    An example of one of the projects. The acceptance tests took a long time. Those. we figachit figachim business requirements, we do, we do, and at the acceptance stage they all freeze at us, nothing goes further. Damn, why so, we tried so hard, it seemed that the business was coming, saying: “Urgent!”, Etc. We begin to analyze why PSI takes so long? Because the business does not have the resources to carry out this acceptance. OK, why do they have no resources? Because they have more important tasks. Good. Why do they have more important tasks? Because on these tasks that we have done, priority has been lost while we were doing them. For example, because we did them for a month or six months, or for some other reason did too long. Or initially there was no priority for these tasks. I wonder why this happened? But because the business, as it were, said to do, and we started to do. And why did they say to do? Because they now had no other tasks at hand to give us. We suddenly got free, and the business says: “Well, guys, you can’t stand idle, fuck this.” And in the end, we did, did, spent time, and then all this doesn’t go into production, because nobody needs it. Problem? Problem.

    Interesting thing. Instead of cursing at the business and saying that they are rascals and their fault that nothing goes into production because they do not do PSI or anything else. We got to the bottom of the root cause of the problems of our entire team. And they saw that in fact, for some reason, we are doing unimportant tasks. And then what should we do? Doing unimportant tasks is a template answer. And the correct answer is to look at us as a team together with the customer at each other, i.e. we unearthed the reason, let's look at each other, understand what we will do with it? Right today, what is better to do with this new information that we learned?

    There is still an interesting feature - are you ready to do such a causal analysis alone, are you ready to watch the process, do something alone? Probably not. The vast majority of people, 99.9% are not ready. Therefore, they came up with the idea of ​​uniting people in teams.



    OK, you are a Java developer, you have your own piece of code, and he has his own piece of code ... But let's learn how to work together. Not just everyone will do their tasks, we will learn to share some business value as quickly and as efficiently as possible. And then we will already see these problems, then we will analyze them together and will come up with how to fix them.



    And a retrospective example. This is a Scrum built-in tool for continuous analysis, identification, in-depth analysis and problem solving. There is no retrospective in Kanban, but there is probably something related to the problems.



    So, I would formulate the second skill: to learn how, as a team, to see in time, not to hide under the table, but to pull out, on the contrary, out, be sure to analyze, not solve the symptoms of the problem, and dig the root cause, and then solve this a problem.



    OK, well, let's learn how to do it. And we do everything, but again the customer is dissatisfied, i.e. at the reception it turned out that we did again not what he needed at the exit. How can this be? What else have we not taken into account? The customer was not taught to watch properly. Those. fault at the customer? Or in us? In us.



    The reason here is how we, in general, built our relations with the customer. It doesn’t matter what kind of customer it is, our outsourcing project or internal house-development — we do this for our own business. When they are customers, and we are performers, they come to us and speak.

    Remember the joke: the customer runs into the room (and he always has the highest priority) and says: “Guys, shoot me in the foot urgently.” They take and shoot him: “Bach!”. He has a hole in his knee, he is crying, bleeding, jumping on one leg. When the strain went a bit, they asked him: “What happened?” He says: "Yes, something was scratching under my knee." All bloodied, with a hole in his knee. They: "So, maybe you should have scratched?" And he responded to this: “But what, was that possible? I didn’t know, I thought only to shoot. ”

    This is an example illustration of the approach when we do what we are asked. By the way, analysts have such a concept - “we remove the requirements from the customer”, i.e. we come to the customer with a dictaphone, sit down and begin to fish out from him what he wants. Damn, well, cool! But he wants to solve his business need. He has no idea how this should be implemented in the product, or he has, but this concept is template for him. And in this sense, let's try to learn how to help the customer think. Regardless of who we are in the team - a single developer, analyst, tester, manager or anyone else. We, as a team or as an internal development department that solves the business needs of customers, should help them think how to implement what they need in the best possible way.



    Example. In one of the banks. We already analyzed, then wrote. When they got in the way, the business came and said: “Guys, all systems have a Dashboard, let's get the Dashboard down.” Analysts: “Come on! What do you mean by dashboard? ” Customer: "Well, this is when the numbers are here, the graphs are here, it is possible here, this is there." Analysts: "Yes, no question!". Good analysts sat down, wrote 200 pages of documentation, agreed with all departments for two months, the developers went, did, rolled out, and what happened? And it was a B2B product. And it turned out that strange, surprising thing, but the customers of our product, even though they are the whole company jur. Russian faces, it turned out that most of them do not need such a Dashboard in the form in which it is. Some, in general, do not need any Dashboard. Why? Because the customers are all different. There is FE Dima, for example, who has the same needs for a dashboard. And, for example, there is “HeadHunter” LLC, which has different needs, and there is a retailer, which has completely different information and needs to be displayed differently from the first two requirements for Dashboard. Therefore, the feature was not needed by anyone.

    We thought: “Damn, how is this done in other systems? Maybe it was better to look, to determine who the characters are, why the client needs Dashboard? ” And there was one architect in the team, he, like a real architect, very good, was silent, he won’t say too much, but when he does, he bombed me straight. The guys were discussing, the whole team was about to about half an hour old, and he said this: “Guys, why the Dashboard at all? Why, in general, did you need to make a dashboard? What problem did we want to solve? ”

    And the third skill of us as a good, cool, cool team is that we help the customer by asking, for example, such questions, or with our experience, our knowledge of the subject area. Asking questions for which there is no quick answer. The customer resorts: “Guys, make a Dashboard”, and we tell him: “No question, we’ll do it. Please tell me why Dashboard? ” And the customer is: “Well, how? Because there are other systems. ” And we told him: “Some kind of rather weak argument. Let's think, for whom is it needed, etc. ” And we begin to discuss these issues.



    Let's see who our end user is, what segments of the target audience there are, what needs they have, problems, how can we solve these problems? And for the guys from the bank in this B2B project that I talked about, it was impossible for analysts to even think that you can come to the company and talk with future users - with a financial director, for example, or with accountants. For them, it was a “faceless Yurik” of some kind, about which they knew nothing. And, it turns out, through client managers, if you try, then even in a large bank you can reach end users. When they understood this, their mouths were open and could not believe it. And after that they started to do.

    And the second step:



    When we deeply understood the problem, then we can already design a solution. And not one solution is better, but several is better. And these decisions are no longer just because the customer came and said “Guys, make a Dashboard”, but because we understand who needs this Dashboard and why, and how it will be used.

    Sounds reasonable?



    The third skill can be formulated as follows: help the business achieve the best results possible. By possible, I mean the best of those that we, as IT and business, could come up with, working together. And for the money that they gave us, or that we asked.



    Returning to the question, how to make Agile work? If everyone on the team, or at least the majority, will have an understanding of the underlying mechanisms of how this works, that we should constantly look for feedback, find out what we don’t know as soon as possible, that we should continuously identify problems, analyze them deeply and decide that we must help the customer achieve better results, help him think. Then you can select contextual practices, not unified some things, namely those that today will work with us.

    The irony is that we even take some trivial auto-test, for example. For your teams, is autotesting good, bad, or incomprehensible? There is no team for which it can be bad. Such a timeline appears, and the whole question is, is the team ready or not today? Today, for a team, automatic testing can be bad, but after a month, for example, this is an ideal practice for it.

    Our task is not to follow unified processes, but having, for example, Scrum or Kanban as the basic frameworks, every day choose new tools, new practices, or even come up with ones that will make our process even better.

    All processes in the Agile world are empirical, based on previous experience, i.e. we did something, something didn’t work out for us, somewhere we started fast and cheap, since we figured out how to fix it.



    Well, and can you check if you have Agile, Scrum, Kanban, are these two things being done? At least these two. Are you focused on business, on helping him, and not just doing what he asks for, not just doing features, but solving his problems? Do you have any mechanisms in place - at least at stand-ups you identify problems, analyze, solve, at least in retrospects - anywhere. Do you do it on a regular basis or not? And this is precisely the success of modern teams.

    Contacts


    " Dlobasev@gmail.com
    " lobasev.ru
    » ldmitry

    This report is a transcript of one of the best speeches at the Whalerider Management and Entrepreneurship Conference .
    We have already begun preparations for 2017, by the way :)

    You can get additional materials from past years by subscribing to the WhaleRider conference mailing list .

    Also popular now: