How to understand that Agile works

Askhat Urazbayev (ScrumTrek)

Before we start talking about how it all looks from the inside, what problems do we face when we train a team, the question is: those who work on Agile, what does it mean for you that the Agile team is an Agile team? How do you define it?



')
My name is Askhat Urazbaye, I am from the ScrumTrek company. We are engaged in helping companies and organizations implement the most flexible methodologies. The problems we face.



There may be several teams inside your organization. Some teams believe that they are working on Agile. Some managers have a question, which team actually works on Agile, and what does this physically mean? Those. How can you determine that you work on Agile?



For example, there are all sorts of formal things, such as sprint, velocity. I don’t know if you have such people in your company who like such terms very much, like to rush them and say: “We hold daily stand-ups. Are we working on Agile or not? ”

And, in general, what is Agile? Predictable results, adaptability to changing requirements, quick response to changes, short iterations. These are ideas. What practices are there? For example, I have on a slide sprint, velocity, story points; some other things that are used to provide all this.

Sometimes you come to an organization or company, where several teams - some work on Agile, some do not. How to judge which team is cooler, based on how they work, whatever practices they use - sprint, velocity or any others? It is very hard to say which team is more efficient, based on the fact that you are simply looking at how it works.

How does it look so often? You come to the office, there are two teams - one has everything, everything that is possible is straight, crammed - from technology to methods, practices, approaches. But they do not divide, they are not in production, there is no result. Or in some production. Bad, slow. It is evident that they do not work effectively. And another team that doesn’t use anything, which has neither sprint, nor velocity, nor all of these fashionable terms, but they divide qualitative results, and customers, end-user, etc. they are satisfied.



It turns out that there is no 100% correlation between what approaches you use and what result you get, no. And this is such a sad fact. It turns out, it is rather difficult to keep track of how effective it is simply in those tzatskam, or badges, or whatever it is that people put on themselves.

We had such a case. In one of the companies with which we interacted, they decided that it would be cool if the guys would use gamification, give out badges. Do you use velocity? You have a badge. What does this lead to? All the badges are up to the fig, all are in badges, but there is no sense from this. It turns out pure cargo cult.

Another common definition of Agile is the Agile manifest:



These are quick reactions to change. Can it be used as an Agile definition?

There is a certain minus in it. The fact is that if your team works according to the “how it is” method, i.e. you do not write documents, you don’t have any processes and tools, you don’t use anything, you don’t have any documentation or contractual relations with the customer either, you have never created a plan - can we assume that you are Agile? Judging by this definition, in principle, yes. It turns out that this thing - Agile Manifesto - not for something, but against something. He is against a waterfall. Against when the requirements are written, the design is long, etc. And it turns out that as a good clear definition it can not be used.

I tried to understand, if all this is thrown out, all these nuances, what is, in fact, Agile? I will try to tell about it.



It turns out that Agile practices for the sake of Agile practices are absolutely meaningless things. Yes, they are needed for something, but you need to understand for what purpose, what task they perform. Agile manifest as a definition also does not work, or does not work in all cases. What is the definition of efficiency?

The question arises: which team can be considered cool? I specifically use the word "cool," not "effective." Which team is cool for you? Which loot earns? But it can be an inhouse, inside your company, it automates business processes, what kind of loot is there? Salvage if you are in a startup, and if not in a startup? Quality, time, result, deliveit, in short. A satisfied customer is also a good definition.

I tried to formulate it, because all these things - they are situational, somewhere there, somewhere not. I tried to come up with a definition that more or less fits any situation. What is a cool team?



From my point of view, a cool team is determined by the ability to cope with the problems encountered. Those. if you, for example, are the head of such a team, they run to you to solve a problem every hour, every day, you are resolving something all the time, then this is not a very cool team.

Another coolness of the team determines the scale of the problems that it can solve. And the ability to respond quickly to ever-changing conditions. Something will change, the team adapts, moves on. This, from my point of view, is efficiency.

If we need the customer to be satisfied ... The customer is not satisfied - this is a problem that the team can solve. If we say “team deliverite” - this is just one of the problems that the team has to solve. It should be able to adapt quickly, to cope effectively with such problems, despite the constantly changing conditions.

Example. Very typical problem.



We all finished it! What else is left? Fix bugs, fix it ... I don’t know if you have this, but this is a very common problem.

How to cope with this problem? Back to Agile. In other words, even if you are working on Agile or on a different product, you are working, working, working, then finished, but still have not completed a whole lot. How does Agile deal with it? One of the things that exists in Agile is called Definition of Done. This is a criterion of readiness, some definite agreement within your company, team, which means that the task is completed to the end. Definition of Done Example:



There is a specially trained fasting man who helps the team ensure that this is done. How is this thing done? You are going to the team and your project-manager, sit down and do it together, write. And then make sure that this is done.

The existence of such agreements helps you a lot, because you have the opportunity to come to a person who does not do something and say: “Yura, why didn't you do this? We have agreed". Yura says: "Well, I will try, yes, yes." In general, it is possible to put pressure on the conscience, so to speak.

These things try to write in not very large quantities, i.e. Exactly about what there is a problem. For example, “code is commited”. It is not necessary to write, it is clear that he will be commited. Those. key things are written.



There is one more interesting thing that you also observe when such things sink and go. After a while, these things start to die off. From the point of view of the person who implements Agile, it looks like this: “Guys, I came up with a cool thing, Definition of Done. You said she was cool, why did you stop doing Definition of Done? ” All such: "Yes, something is somehow not needed already." It's true, this thing is beginning to die off.

The cycle begins with unconscious incompetence - you do not know that you have a problem. Then you have a conscious incompetence - you know that you have a problem. Then you solve it - conscious competence. You know how to solve it, you have an approach, you burn it, you think about it, you spend an insane amount of energy on it, whatever that is. Your focus is on this. After some time you learned. And this thing goes into unconscious competence.

Going back to which team is effective. It was clear who had problems with what, what the focus of attention was on. Someone says: “We cannot release the code in any way - we release it, but the customer is not satisfied with anything”. This focus of attention is key to you. And this is happening now in a state of deliberate incompetence - it seems that we do not know how.

What happens after you learn? For example, you will learn to deliver. You know how to deliver a quality result in production on time and predictably, despite the ever-changing requirements. It turns out often that you used an insane amount of things, in order to learn how to do it - you evaluated there in story points, you used some kind of story mapping, you have some different approaches, etc. It is like scaffolding in a house under construction. You put them, put them, put them, you thought about it, you were sick of it (Agile managers have been ill for an average of three years). When learned, already attention to other things switches. As soon as you learn, all this must be removed. No need to keep it ballast. Just force people to resort: “Why don't you do this? Well, do it! ” If they deliver, and the customer is satisfied with them, we remove it all. We remove all these forests.



There is such a thing - called #NoEstimate approach. This is just about it. You can stop to evaluate, refuse to estimate if the customer is satisfied with you. There are approaches, principles that allow you to abandon it. If you do not know how to do it, of course, you don’t need to do this, we are talking only about those who can, learned to do it, you can go to this phase.

To do this, you need to continuously deliver value to the customer, get rid of external dependencies that inhibit you, because of which the customer is not satisfied with you, and equalize the possibilities and needs. Your possibilities in terms of the result that you divide the customer, and the needs that the end customer, user, etc. have. If it's all the same, and those things are equal, the customer stops coming to you with the question: “When?”. You just do what he needs within a reasonable time for him, that's all.

Those. we remove these forests, then other things can be dragged into your focus of attention, and they themselves will emerge. It's like your circle now, you think about it: “How would we close it up?”, After a while your circle gradually increases and it turns out that there are much more problems. But it looks like if you talk to such people, one in the production will not work out in any way, others think about the strategy of market promotion ... I’m talking about teams. This, you know, someone has a liquid soup, and someone has small pearls - this kind of talk is going on. Those. Yes, we have a lot of problems, it looks like there are more, but the level of these problems is much higher. And such a team is much more effective.

But from the point of view of an outsider, such as myself, such a manager who implements Agile and makes sure that within the team can be done, a cool team and a cool team look the same. Regardless of whether there are any practices, whether they use the same velocity, they look the same. But one deliverit, the other - no.

What is important here? It is important to avoid such a thing as a cargo cult.



The idea of ​​a cargo cult is as follows. During the Second World War, when America fought Japan, they built airfields on islands in the Pacific Ocean to be able to maneuver on their own. They built airfields, flew airplanes, dumped clothes, food, etc. Sometimes they missed the airfields, and the aborigines were happy because it looked that way - as soon as the airfield appeared on the island, food began to fall from the sky. Direct clear communication. And they began to build airfields, about the same as on the slide. After World War II ended, they continued to build "airfields", it turned into a religion. They begin to believe in it.

So, when people come from the side of managers and say: “Guys, you do not divide, here you are such a practice,” sometimes it turns into a cargo cult. At times it really works, but the team does not earn a result. For example, you started Definition of Done on the first day, as soon as you started working with a team, but it didn’t come across a problem that was in the form of a comic book, it just didn’t meet this problem, you know? But you started Definition of Done - it seems, this thing works ... It’s hard enough to give up these forests - they seem to be beneficial, let's do it all. You can give up everything, this is flexibility.



What problem does team A solve? Sprint, Velocity, Story Points. We see that it does not divide, does not deliver, therefore, because it's great and she focuses on that. What team B is doing is not clear yet.

What are the growth zones? Where can we develop?



Basically:

• supply,
• quality in terms of technical exams, not just quality in terms of testing, but technical quality, as a result,
• and product - are we doing what the end user needs?

In each of these areas you can develop.



And each time one single dragon with which we fight. Therefore, defocusing such a team, returning them to the previous positions won, is meaningless.



As a rule, your first dragon is a delivery. If you do not divide, unpredictably divide for the customer, this has to be dealt with first of all, because high-quality delivery means discipline within the team, the ability of the team to divide, including the technical tasks that are needed at the next level to ensure quality.

Following. Quality, product. I conditionally placed them on the ladder, of course, they are with great overlap. But if, for example, the supply is not provided, then it’s impossible to focus on the fact that we can focus on how the team can make a quality product. For example, parallel startup stuff. Within two months you have to fix the feature in order to be able to experiment. Or three weeks - depending on what kind of business you have. And if you do not deliver? If unpredictable deliver? It looks like a constant conflict between product-managers of the team, and the manager comes and says: “Well, where?”. You say: "You know, your requirements are shit, to be honest." And he says: "What is the difference if you still do not deliver?". You are to blame for this situation. Whatever bad demands he gave you, are you guilty, agree? Anyway, you did too long. Maybe the requirements have changed during this time? It is necessary to deliver faster than the requirements have time to change. Then you can move this way.

So, we return to the topic - what does Agile mean in practice?



There is a Deming cycle, he is on the left, do not confuse. Plan, do, check, act. And on the right - this is the “how it is”, just ran. And in principle, the border between them, from my point of view, distinguishes the Agile team from the non-Agile team. If we just fly in a park and everything is bad - it is not very Agile, and this method is more structured, this method leads to a more efficient result faster. Plan, do, check, act.

Plan - planned. And batching (I could not find the right word) - we make a small plan. If we're talking about Scrum, it's two weeks ahead. If we are talking about some technical improvements, it is also a very short time. If we are talking about lean startup, there is also a very short time - days, maybe.

Do - we do it. Here discipline is important, we achieve results. We are not just figachim, so that if then it did not work out, then we transfer the next sprint. Let's determine what we are ready to do, let it be less, but to the end. Small Osprey completed to the end.

Check - feedback and metrics are also very important. It seems to me that this is precisely what distinguishes an effective flexible team. Because in the previous case, you work like this, you do not always have feedback, you can spin endlessly in a cycle, you will not have any achievable results.



Experiment - you have to try new things, just do them as an experiment. And this short cycle of improvements constantly spin. Constantly try some improvements.



This is the typical Scrum: Backlog, Sprint, working in the classic Scrum for 30 days. It turns out about the same cycle.



Sprint, if we talk about sprint planning, task board, stand-ups, Definition of Done provides discipline, we run a demo for feedback in Scrum, we have velocity / cycle time to measure how effective we are.

So, we can conduct experiments and see if they lead to the desired result or not. You can try pair programming, and see whether it brings benefits to you or not. This is an odious example, there are many such examples, things that we can try, see if our performance will improve, just by choosing some metrics for ourselves that we can look at.

This is scrum, this is delivery. If we are not able to divide, Scrum is one of the ways, the second most common is Kanban, which provides you with a constant cycle of improvements.



About the technical part - Red, Green, Refactor, if we talk about Test Driven Development.

If we talk about Agile, about all these principles, short cycles, then the next question. Suppose you are revising the architecture of your product. You have a heavy, tangled piece of code inside (the spaghetti code is called), and you want to redesign it. Where do you start? This is a big cycle, this is not Agile, how do we make a small cycle? How can we do something small to check whether it works or not, and choose for ourselves some kind of understandable, reasonable metric that we can orient on? I leave it to you as a homework, we can then discuss it separately.



Supply. What do we get? The skills we want to bring up.

In principle, from my point of view, the key skill is the ability to decompose into small user stories that incrementally improve your product. This is a huge problem in the industry, we are constantly faced with this. You have TK in you, you do according to TK. How much is this incremental approach? Those guys are not incremental. Then you say: “Damn, the customer is a goat, he is not satisfied with us. Although we did everything exactly according to the TZ. ” , story, , . .

— , . , , — cycle, velocity , User Story, Story Mapping, Estimation, Definition of Done ..



Lean Startup . , , , learn, build, measure.

You have some kind of end-user product, for example, a website, you have a welcome script with a bad conversion, you want to improve the conversion. Welcome script rewrite. You have found the best yuzebilistov, they tell you: "Yura, it will take three months." The team tells you: “Yura, these are three months.” Yura says: “No, this is very important, let's do it. Well, really, there is an urgent welcome script, we rewrite everything. ” They rewrite it for three months, you deploy it into production, and the conversion drops. What to do?Lean startup means that we release Minimum Viable Product, small improvements that incrementally allow you to test whether you understand what is going on in your end user’s head. And just look at the same conversion just in real time. You released a feature, looked at the conversion, looked at how it affects different types, cohorts of users, etc. Those.you can constantly twist such a cycle, if you understand what is happening in your user’s head, and you have feedback, a model of your user appears in your head, and empathy arises with it. To lose is impossible.

If you do not like the feature, you immediately kill it. This is the same Agile cycle inside the product. As soon as we have a normally rebuilt delivery, we can switch here. We can start working on such a cycle, this is our next focus. Learned to deliver, learn to produce a cool product.



The ability to feel empathy with the user, the ability to receive feedback from the market.

Again, these cycles must be very short. In Lean Startup, it's a few days, it's not even Scrum's two weeks. Any metrics exist. And tools Customer Development, Lean Startup, Design Thinking.



Quality is the ability to deliver without bugs, high-quality code, automate routine work. This is quite obvious and understandable things. Again, try to do this in small pieces. Coming back to the same refactoring, you cannot stop business development while you refactor this piece, although I would love to. The key feature of this kind of reengineering, whether we can work in small pieces, this means that your product is Open Running. You write a new piece of the component and gradually switch functionality to it until you rewrite everything. You can have several duplicate functionals working at the same time. Until all you have not completed yet.

, . , , time to market, , , , . , , - , , . , « », , , .

Test Automation, Continuous Integration and Continuous Delivery, DevOps is a separate topic. There, the idea is that you can release everything in production without testing, and testing on end users. If your metrics fall, you can give feedback through monitoring. But this is also a very short cycle, it is possible to drive very short cycles very quickly.

Contacts

» Askhat@scrumtrek.ru
Facebook
» Twitter
» Zibsun » Scrumtrek
Company Blog

— Whalerider .
2017 , :)

, WhaleRider .

ScrumTrek, agile — AgileDays