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 you come, for example, from a conference and as a manager say: “So guys, everybody Kanban from Monday!” Or “Everyone to Scrum!”. And the guys are looking at you - well, what is their choice? They said Scrum, it means Scrum ... They go, they do something, they try to do Scrum, they do some rituals, they dance around the board in the morning, they go, they do something else. But something is not working.

My report is dedicated to this. Let's take a look at the mechanics of Agile processes — how to make it all the same bring value.

This is how it was intended:
')


Well, it turns out at the output:






A couple of introductory words. About myself. My name is Dima Lobasev. For the last 5 years I have been engaged in helping companies make their 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 there is, of course, process adafat ...

See how interesting the industry has developed, a couple of key points:

In 1970, came up with a cascade model. It looked like this:



Those. the customer comes to us and says: "Guys, we washed down the product." We: “Well, now we will collect requirements, we will design, we will develop, we will test, we will roll out, and there will be to you happiness”. Right?

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



Winston Royce said that in fact it is impossible to make a good, high-quality product in one pass. You need to make at least two passes.

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

Well, it turns out at the output:



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

The process looks like this. Some people more than half of the project time generate some kind of insane documentation. The developers at this all then look, if they look. They are a bit shocked. Testers cry. In my practice, testers are always very sad, because not only did the guys not quite do what was written, they still did it for a very long time - we didn’t build the buffers between the stages, but development takes longer than we wanted. And the most interesting thing is that they are testing about what? .. There is even such a term “testing about requirements”, although the customer already understands that there must be something different.



Next was this:



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

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

And there were people who said: “It’s never going to work, because whatever the universal process we’ve come up with, the contexts of the 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, products themselves are different, etc. How can one process fit all at once? ”

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

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

The idea is this: in the industry, since 2005, not a single methodology has emerged that describes consistently what and how we should do, which would become an industry standard. Everything that appeared - XP, Scrum, etc. - these are all toolboxes. These are all process frameworks that you can use as a basis and around which you can build your own process in your project team - the way you need it 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 are working. Someone is sitting on the side. You look in your teams, if you have distributed teams, do you have this, is it manifested or not? The guys are from Moscow, and this one came from Yekaterinburg on a business trip. Therefore, he feels as if he does not feel very close with them, although they are working on one project.

So, there is a project team that somehow works, there are some problems, some packers, we work on weekends, the customer is not always happy with us, we process something. And at a certain moment someone says: "How long?". Or a business comes, for example, and says: “Guys, it’s no longer possible to work like this, let's start changing something.”

There are, in principle, several possible options for how to proceed. See, as usually happens in practice:

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

And what happens at the output?

See, it happens or was it with you? Scrum example:



Developers meet at the blackboard and one says to the other: “Yesterday I hunted wild hairy mammoths. Today I will hunt wild hairy mammoths. However, there are no problems. ” Another developer repeats the same thing, because this is a ritual about which Scrum tells us that we have to answer three questions on these morning stand-ups. They talked and went their separate ways.

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

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



Retrospective. The iteration is over, we met, one says: "Damn, it sucked." And others: "Yeah." They looked at each other and went their separate ways.

Or there is still an evolution of retrospectives. At first they just went their separate ways, then, if they met again, they looked at each other: “It was not cool, a lot of bugs. What do we do?". And everyone is stupid, not understanding, and what can they do with a lot of bugs? And someone says: "And let's write better code?" And all are: "It's hard to argue, let's." And again they ran away - to write better code.

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

Is there some more. I have observed the option “Declaring values ​​from above” in some companies.



Imagine that a manager, a functional manager, for example, the head of an IT department, listened to a special report that was cool, the frameworks were there in the company, everything was in ... Comes to the office and says: “Guys, you have to share Agile values , you should be like this, innovative, etc. " Here is something from this series:



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

The problem is that it is not enough to say what needs to be done, it is also necessary to help people do it.



And the idea is this: our task is with you, as people who, one way or another, are involved in the implementation of Scrum, Kanban, anything, so that the people - our project team - understand why and why they go to stand-ups, to 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 you to point out three main, key skills of the team, which 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 this,” and we ask him: “Why did you remain silent, did you not say before?”. This is the situation.

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



Agile offers us ready-made and clear tools. Take the same Scrum - short iterations. Let us, instead of 3-month, semi-annual, annual cycles, learn how B2B, complex, super-enterprise or B2G whatever our application is ... Let's learn every two weeks to deliver some kind of assembly, collect feedback from it, do a demonstration in end of each iteration.

Business comes to us and says: "Do me well." We ask him: "What does this mean?". He: "Well, how would that all mean." It is difficult to deliver a result every two weeks, so we need to learn how to slice it.

Well, there are still a lot of different tools, you know them well.

What is the background? What, in fact, these tools allow you to do in order to solve the problem with the fact that we do not give it to the customer.

• Find a bug early.
• Monitor the processes.
• Time to adjust goals.
• Get the customer to formulate the task in detail and correctly.
• Become a team.

And the very essence ... Actually, that very first skill, one of which I want to show you today, the essence of frequent demonstrations of short iterations of the decomposition of applications is to learn as soon as possible to find out what we still do not know. You can call it risk management, built into the process of our team.



It may seem to someone that this formulation sounds silly, but, in fact, this is the basis of the mechanics of flexible processes. The fastest possible feedback loop.

What usually happens in a waterfall project? We, for example, saw the product, after a year, at best, release a release, and then the most interesting begins. It's not that. Change requests begin, so people from the classical management have invented special change request management procedures, which still beat out money from customers, etc.

Our task is to make sure that we move in small steps and constantly learn something new about technical risks, infrastructural things, business, in general, customers, their needs, etc. Anything. The more information we have, the better solution we can come up with. And the movement with short iterations allows us to slightly turn in the right direction at each subsequent iteration.

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

And I have a question for you to backfill. Most of you probably have complex projects. But what if a bid cannot be completed in two weeks, a business requirement? It is not decomposed so that there is any value at the output. How to be in this situation? This is just your homework - think ...

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



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

What is the problem here? Very important and interesting problem. In the way we think. If you watch any video, or read a book about how the brain thinks, then 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 patterned solutions. He just takes it, looks for patterns, and your mouth spits them out. Those. you have a problem, and what are we going to do? Once, and instantly there is a solution, in a nanosecond. Instant ready solution. Well, Agile doesn't suit us, ok. It’s clear, 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, we do, and we have process crutches.



The idea is as follows. The development industry has come to this point. Let us try to make our brain think how unpleasant it may be. And by the way, a little water helps, helps him not to dry up, helps him to think.

There is a good practice, called “A3 Thinking”, or a simple example of a tree of cause-and-effect relationships. There are five "why?"

If we ran into some kind of problem, for example, a lot of bugs in production, or, for example, something caught, half the users had something to fall off, and we lost money. The first thing that comes to mind is what should be done? It is necessary to dismiss someone, from someone to take away the rights to deploi, to punish someone else, etc. And any more formal procedures come up with. In fact, you can not rush to solve this problem, and the whole team to sit down and think, why did this happen?

An example of one of the projects. Long passed acceptance tests. Those. we do business, we do, we do, and at the acceptance stage they all hang, nothing goes further. Damn, why so, we tried so hard, like the business came, said: “Urgent!”, Etc. Begin to analyze why long PSI? Because the business does not have the resources to carry out this acceptance. OK, why don't they have the resources? Because they have more important tasks. Good. Why do they have more important tasks? Because for these tasks that we did, priority was lost while we were doing them. For example, because we did them for a month or half a year, or for some other reason have been doing it for too long. Or initially there was no priority for these tasks. I wonder why this happened? And because business, as it were, said to do, and we started to do. And why did they say to do? Because they didn’t have other tasks at hand to give us. We are suddenly free, and the business says: "Well, guys, you can't stand idle, figure this one out." And in the end, we did, did, spent time, and then it all goes into production, because no one needs it. Problem? Problem.

Interesting thing. Instead of swearing at the business and saying that they are scoundrels, and their fault that nothing comes into production, because they are not doing pies or something else. We got to the bottom of the root cause of the problem of our entire team. And we saw that in fact, for some reason we are doing unimportant tasks. And then what should we do? Not doing unimportant tasks is a routine answer. And the correct answer is to look at us as a team with the customer at each other, i.e. we dug out the cause, let's look at each other, understand what we will do about it? Right today, what better to do with this new information that we have learned?

There is still an interesting feature - are you ready to do such a cause-and-effect analysis alone, are you ready to watch the process, do something alone? Most likely no. The vast majority of people, 99.9% are not ready. Therefore, they came up with a group of people.



OK, you're a Java developer, you have your own piece of code, and you have your own piece of code ... But let's learn how to work all together. Not just everyone will do his tasks, we will learn as quickly as possible and better deliver some business value. And then we will see these problems, then we will analyze them together and we will figure out how to fix them.



And an example with a retrospective. This is Scrum's built-in tool for continuous analysis, detection, in-depth analysis and problem solving. There are no retrospectives in Kanban, but there’s probably something to do with problems.



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



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



The reason for this lies in the way we, in general, built our relationship with the customer. No matter what kind of customer it is, an outsourcing project or an in-house development, we do it for our own business. When they are customers, and we are performers, they come to us and speak.

Remember the joke: the customer runs to the room (and his priority is always the highest) and says: “Guys, immediately shoot me in the leg.” They take and shoot him: “Bach!”. He has a hole in his knee, he cries, bleeds, jumps on one leg. When he strained a little, they asked him: “What happened?”. He says: "Yes, I itch something under my knee." All bloodied, with a hole in the knee. They: "So, maybe you had to scratch?". And he responded to this: “And what could have been so? I did not know, I thought, just shoot. "

This is a rough illustration of the approach when we do what we are asked. Analysts, by the way, have such a concept - “we remove requirements from the customer”, i.e. we come to the customer with a dictaphone, sit down and start to get out of him what he wants. Damn, well, cool! And he wants to solve his business need. He has no idea how it should be implemented in the product, or it 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. We, as a team or as an internal development department that solves business needs of clients, should help them to think about how to implement what they need in the best possible way.



Example. In one of the banks. We have already analyzed, then wrote. When zapakapilis, business came and said: "Guys, in all systems there is a Dashboard, let's write down the Dashboard." Analysts: “Come on! What do you mean by Dashboard? ” Customer: "Well, this is when the numbers are here, the graphics are here, it can be here, it is there." Analysts: "Yes, no question!". Good analysts sat down, wrote 200 pages of documentation, coordinated with all departments for two months, the developers went, did, rolled out, and what did it turn out? And it was a B2B product. And it turned out that a 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 as it is. Some, in general, do not need any Dashboard. Why? Because customers are all different. There is IP "Dima", for example, which has some needs in the Dashboard. And, for example, there is HeadHunter LLC, which has other needs, and there is a retailer who has different needs for the Dashboard from the first two, completely different information and should be displayed differently. Therefore, the feature turned out to be unnecessary.

We thought: “Damn, how is it done in other systems? Maybe it was better to look, to determine who the characters are, why the client needs the Dashboard? ” And there was one architect in the team, he was like a real architect, very good, he was silent, he wouldn’t say a word too much, but when he does, he directly bombed. The guys discussed, the whole team is on the way for half an hour, and he says: “Guys, why is the Dashboard anyway? Why, in general, had to do 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, asking, for example, such questions, or 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 say to him: "Not a question, we will." And tell me, please, why the Dashboard? ”. And the customer is: “Well, how? Because there are other systems. ” And we tell him: “Some rather weak argument. Let's think about who it is needed for, etc. ” And we begin to discuss these issues.



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

And the second step:



When we have deeply understood the problem, then we can already design a solution. And not one solution is better, several is better. And these solutions 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 why they will use it.

Sounds reasonable?



The third skill can be formulated as follows: helping a business to 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 which we asked for.



Returning to the question of how to make Agile work? If everyone in the team, or at least the majority, will have an understanding of the underlying mechanisms of how it works, that we should constantly seek feedback, as soon as possible, find out what we don’t know yet, that we must continuously identify problems, analyze them in depth and decide that we must help the customer achieve better results, help him think. That's when you can pick up contextual practices, not unified some things, namely, those that work for us today.

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

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

All processes in the Agile world are empirical, based on previous experience, i.e. we did something, we didn’t succeed, somewhere we quickly and cheaply stuffed ourselves, since we figured out how to fix it.



Well, can you check if you have Agile, Scrum, Kanban, do these two things work for you? At least these two. Are you focused on business, on helping him, and not just on doing what he asks, on not just doing features, but on solving his problems? Do you have mechanisms in any of their forms - even at stand-ups you identify problems, analyze, solve, even at retrospectives - 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

— Whalerider .
2017 , :)

, WhaleRider .