How to mimic Agile correctly?

A similar article should have appeared earlier, about ten or fifthteen years ago, when Agile was just starting to be implemented in companies. How many mistakes, problems, conflicts could be avoided if managers immediately approached the issue correctly …

But during this time, the experience of "implementations" Agile in different conditions, in different companies has accumulated, which should be generalized and widely disseminated.

Why Agile?

In fact, the question is not before us, and I am not going to discuss it here. Whether the tops said 'it's necessary', or 'is a market decison', or just because programmers - scarce people, have been spoiled, and the first thing they ask at interviews is - " do you work by Agile? no?! oops ... ". You did not choosed this path, but you are responsible for leading the unit entrusted to you along it. And I will share the tricks how you can do it better, without reducing your annual budget and staffing along the way, but, on the other hand, taking advantage of the opportunity that has turned up, earn reputation points, increase your influence in the company and salary.

Why is imitation better than implementation?

Honestly, why do you need Agile? To increase the efficiency of your development teams, or what? You don't mean to say that you're not an effective manager right now, do you? That's it.

As business coaches keep telling us, having the right goals is the key to success. Therefore, we admit to ourselves (not publicly, of course) that your true goal is not "increase in development efficiency", which no one needs, but "introduction of Agile, which will allow in the future..." and then substitute the notorious phrases "increase development efficiency", "respond faster to market needs", "fit into the modern world", "implement innovative solutions", "achieve amazing success", etc. By the way, write down the words - useful for presentations.

On the other hand, one does not simply say now has Agile. It is necessary to make some efforts so that a person who is not directly involved in the process cannot understand that here do not smell of Agile. It is also very good if your employees are also convinced that they work in an Agile company. The coolest - when your employees praise your vision of Agile in articles on the Habr.

Where to begin?

Naturally, from learning. By no means I do not encourage you to read abstruse books and, moreover, not to learn on your own in the process of implementation. You should not even hope to understand this topic yourself or one of your employees. The theme is very complex, and we never have enough time. But there are companies specializing in Agile training, can make courses for you and your employees. Just don’t do it at the expense of your budget, let it be organized by top management - the courses is not cheap, but it’s not worth saving on training, any manager confirm that.

The courses will give you terminology, tell you how to draw up graphs - its can be used to show to management.

By the way, on the first day of the course you will definitely be told how the fundamental document named Agile manifesto was appeared in the ski resort. Apparently, there is something in this idea. Therefore, it makes sense to combine Agile training with a trip to nature - if not to a ski resort, then at least to a decent hotel with a vast territory, landscape views and a sauna in the evenings. All staff attendance is mandatory.

In training, they will tell you that the Agile manifesto consists of 4 values ​​and 12 principles. This is true, of course, but you need to know for sure that in the manifesto, in addition to those mentioned, there is also the Basic Rule for Values, which says that the right side of values ​​is also very important. Armed with the Basic Rule, let's look at the values.

"Individuals and interactions over processes and tools"

If asked, immediately confirm that people are more important, nothing is more important. It is important that people see what a caring leader they have. But you can’t allow a mess either - if someone doesn’t like the order, the door is open. And when some developer or team wants to clarify, correct the process, or, excuse me, not go according to the established process at all - say that this is an interesting proposal, you should definitely discuss it, let them write it down and pass it through their process manager to the next process committee. But do not call the developers for a committee, it’s unwanted, they have their own work.

"Working software over comprehensive documentation"

The value is good, but it must be properly understood. Remember the Basic Rule? It doesn't mean not to do documentation. On the contrary, until there is documentation, disable to release a product. What, not clear? Never mind, I'll explain.

Just imagine - the team hard worked, quickly, on deadline issued a working product, unique for market, with a good potential for profit. You are already going to make a hole for a new star. And then a client appears, dissatisfied with the fact that he could not understand your product and there is no documentation. And, bad luck, he is a good friend of a top manager - the one who likes to shout more than listen. Here is how you will explain to the top that "documentation has not been done yet"? Do you need the troubles? You may not lose your place, but your reputation will be stained.

So don't let a product out until it's fully documented.

And no, there is no value violation here. See the word "comprehensive"? Never, I emphasize, never does the documentation become comprehensive. Something is always said not clearly, not exactly, users can understand differently. Therefore, the documentation should be, and as detailed as possible, it will simply not be considered "comprehensive".

"Customer collaboration over contract negotiation"

It's even funny. The one who wrote this, apparently, never closed the acts of work performed. And if the customer is also the state, then how can explain why something was not done that was written in the terms of the contract?

Although that's just with the state budget options are possible. It is only necessary to correctly understand that the left part of the value means "collaboration with a representative of customer." The representative of the customer is an important, responsible person, loaded with urgent matters and ... individual. If your account cooperates with him correctly, understands his needs as an individual, then the act will be signed, regardless of the original terms of the contract, therefore the value is fulfilled. Here, as you understand, it is also necessary for you to create the right motivation for the account.

"Responding to change over following a plan"

My favorite for dessert. The value directly says that you can throw a new wish into the development team at any time, the team loves and appreciates such things. Especially if this wish is expressed by an almost top manager in a private conversation, and not to you. Such wishes should not be forgotten to mark "urgently to the room!". It is clear that the team will not be ready for such a turn, so it is necessary to strengthen the team with developers from other teams. Temporarily, of course. A month or two, well, half a year the neighbors will survive without development. Let them write user documentation for a product that has not yet been created, this is useful for clarify requirements.

But then, imagine, you release a product, and there is already this wish! Yes, not completely in the form as expected, but the deadlines were set tight, and there was no communication with the customer, as it was done almost clandestinely, by surprise. But there is! An almost top manager is pleased, and when he is pleased, then, as Frunzik Mkrtchyan said, you are pleased too. And you can insert a new achievement in your resume when you look for the next job.

I almost forgot to say about the second part - the value also says that the original plan exists only for one day - on the day it is presented to the management. And then you don’t need to monitor it, you don’t need to update it, you don’t need to manage resources - perfect! See, there is something useful in the Agile.

Getting Started

So, a month has passed, all your employees have learned all basic of Agile, rested, sunbathed. Behind noisy competitions, rewarding winners with pens with your company logo, distribution of certificates… It's time to get to work! But not to product development, of course, but to the formation of teams.

According to Scrum (this is one of the Agile options, there are actually a lot of them, but this is the most popular, which means it is easiest to sell it to top management), the team should be small, around 7-9 people. Do you currently have 25 people on your team? It's too much, need to cut. Do not be afraid, I am not going to reduce your staff, quite the contrary. As one well-known effective manager said, cadres decide everything, and I will add that the position, salary and influence of the leader especially depend on their number.

The issue of team separation is not easy, so we use the golden rule for solving complex issues - Delegate It! That is, you need to find someone who will do it professionally, instead of you. You can choose from a team, but it's much better to hire your future Product Owners. Product Owners, or PO are those who will be responsible to the management (you) for the result of the team’s work and everything else (but besides money, of course, money is only your).

For clarifity - before was customers and project managers, and now in Agile age these people are called product owners and scrum masters, or PO and SM. In principle, everything is the same, only smaller. If earlier the customer was an important person who has a lot of money, a lot of big projects, and he can chose a contractor who will make his custom online store, but now the PO is a narrow specialist in business, his responsibility is "show the amount of goods in the basket" . Accordingly, the demand from such a person is less.

In any case, when you select PO, keep in mind that these are people with whom you will then communicate a lot, go to parties together, so choose those with whom you are pleased and interested. Musicians - buzzing, outstanding representatives of the fair sex - excellent, experts in philosophical matters - wonderful. Do not take former PM - they are people of the old formation, they have too high an opinion about their "knowledge" and "expertise" that you cannot compensate for with your budget. It is better to take people with less experience, almost any, but sufficiently motivated, that is, ambitious and ready to go over heads.

Scrum Masters are selected in a similar way. Like PO, do not require deep technical skills, because their main activity is to follow the formal order in the team. To ensure that issues are opened and closed on time, to quickly transfer issues to other teams instead of fixing them, to find work for team members when there is no work, to coordinate vacations, that's all. Therefore, the role of SM should be taken by an executive person with pronounced administrative and commanding qualities. That is, tamed.

So, you recruited PO and SM, gave them a list of people, they got specialists into their teams. Someone didn't have enough. What need to do? That's right, expand the staffing and fill vacancies. I promised you that in Agile you will have more staff. And if you create teams by the minimum possible number, then much more, so use your imagination. And it's time to put the question before the management about moving to a more spacious office.

Nothing can go wrong in this process - Agile teams are self-organizing, so don't worry if you split them up wrong and they can't work, they should still self-organize. And if this does not help, you can blame the PO or SM and quickly change them.

Development process

Coaches will tell you (I will mention them more than once) that in Scrum, all work is done in sprints - two-week, give or take, cycles. Like, at the beginning of the sprint, they took the amount of work, at the end of the sprint, all the improvements have been made, implemented, and are already working. And we are not returning to these tasks anymore, in the next sprint there will be new tasks and new implementations.

Optimistic, but this is just a beautiful theory that we are not interested in. If you follow it, then the team actually commitment every two weeks to the introduction of new improvements within two weeks. And each commitment is a headache for a higher manager, that is, yours. But our goal is not to increase your pain, but to reduce it.

Therefore, we throw out the obligations, but leave the general principle. The practical application to our realities looks like this - at the beginning of the sprint , we define the amount of work, do it, and, when the sprint is closing, transfer the remaining tasks to the next sprint. If an implementation happens during the sprint, good. No, that's ok too.

How should a sprint be structured? It's simple. In addition to the actual work, there should be mandatory rituals in the sprint . Yes, yes, I said rituals. Apparently, I forgot to say that Scrum is a well-known religion, and, as any decent religion should, it has its own saints, priests, commandments and rituals. In fact, there are other denominations of Agile, but they are marginal, except perhaps for one, but that’s later, don’t mind yet. The main thing is that you need to correctly understand your attitude to religion - you do not need to believe, but the rules and rituals are required.

Rituals in Scrum, also called ceremonies, are just rallies, you need to have several of them in each team:

• daily

• retro

• grooming

Well, enough for now, other are optional.

Daily (aka daily scrum meeting or just scrum) - a daily morning meeting for 15 minutes. Naturally, it almost never ends in 15 minutes, it stretches for at least an hour, so if you decide to come to the daily, do not plan anything important for yourself immediately after it.

The daily meeting is a usable time to discuss all the questions for the day with all details, because the whole team is present at the daily, so no one needs to be called additionally, and any question that arose along the way can be immediately discussed with the right person. The meeting is informal, everyone is allowed to throw in their questions as soon as they come to mind.

After the end of the daily, the whole team will have a plan for today, the most important questions have been discussed, decisions have been made, everyone has received additional motivation and can to work. Minutes of the daily meeting are never make. If some important decision was made, but then forgotten - it's okay, on the next daily will be remembered. If team will not remember, then it was not important.

At the end of the sprint, there is a retro - the most important meeting in Scrum, as coaches like to say. The team jointly analyzes its work for the sprint, draws conclusions and makes decisions on how to improve it. Democracy, yes it is.

In general, you don’t need to do anything special with retro, PO or SM can lead it any way. You can stick stickers, you can exchange memes and draw caricatureы on each other, you can pull papers out of a hat. It’s easier to say what you don’t need to do on retro. No need to make decisions that violate the established processes in the company. That is, the Scrum Master has an important role here - not to allow any discussion of issues that threaten to change the process. He must chop off the shoulder, instantly shut up the questioner with a phrase like "We have no right to discuss this, not our level."

You don't have to look for someone to blame. It's nobody's fault that the deadlines are broken, this is the problem of deadlines.

Sometimes you can call a coach for retro. A point for him, entertainment for the team - the coach will show some new graphics from Jira, say in clever words how the team does everything wrong, but will be able to say it without being offending. Also, the coach, if he is good, has experiments in game form, which he will be happy make with a grateful team.

It’s good if after the retro the team has some recorded decisions that it really, really intends to implement. Good, but not necessary, because In Agile, decisions made yesterday are worthless today. It's Agile.

Grooming meeting should be done sometimes - this is the least important meeting in the sprint. Something like planning for future sprints, which in itself is clearly far-fetched, since everyone understands that in the next sprint we are going to do exactly the same as in this one. Since no one really knows what to do at this meeting, and what should be result, grooming usually turns into a discussion of current issues, it becomes like an extended daily.

But you should not completely abandon grooming, it is useful, for example, to discuss who goes on vacation when and where. Grooming can be called a meeting to congratulate the boss.

So, we figured out the rituals, let's start (yippee!) Development. Since Agile is still being implemented, and the teams have just formed, it is necessary to determine what, in fact, each team is going to do. Another friendly religion known as microservices will help us here , the unofficial motto of which can be considered the words "Maybe we have to break ourselves to make something better out of ourselves". We take our entire system, which the company has been developing for a long time, and cut it into as many parts as we have teams. We call each part a microservice and a Product, and give it to the next team. That is, now this team is responsible for part of the system, and no one is responsible for the whole. See how beautiful it is? No wonder the Agile is so popular.

The team has received its piece of work and the first step is to determine the MVP. MVP is the first version of the product. So simple, yes. Although there is someone on the team, there are always those who will not fail to clarify that this is a Minimum Viable Product and should contain only minimal features. Do not argue with him, formally he is right, but does not take into account the realities of life. And the realities of life are such that there is no second first impression for management, so the first version of the product should have all the best and potentially wow and killer features that you can imagine. It's better to delay a product launch by a year than to launch a product that doesn't show your worth as a manager to top management.

Especially it should be emphasized that there should be no bugs in the MVP, for the same reason. Zero tolerance for bugs in MVP! - that's your motto. A button shifted by a pixel, decimal comma instead of decimal point or vice versa - and that's it, you have a reputation as a temporary worker, driving hack instead of the Product. Therefore, it is impossible to release a product without the most thorough comprehensive testing. Deadlines are important, but mistakes are unacceptable.

However, I digress. So, MVP = first version. What will be included in this first version will somehow be determined by itself in the course of the play, but for now let's start a User Story - this is a ticket in the Jira. You can just call him "MVP". That's all, now the team has a task that it work deal with for the next sprints.

In general, the Jira annoys with a strange restriction that only one person can be setted as assignee for every story, and not the whole team. There is confusion about who does what. You have to create tasks and subtasks of the "Development", "Testing" type and assign its to different employees.

What, not enough tasks in the sprint? It's not a trouble, you can create tasks (but not story) like "Prepare the board in the office", "Vasya's moving to a new place", "Set up the stand", "Assemble the assembly", "Deploy the assembly deployment pipeline", "Reply to the customer's letter" etc. You can create and close dozens of tasks every day. The more tasks, the more reasons for bosses why the first version has not yet been released. The main thing is that the employees do not forget to close tasks. You can close with any resolution - "Cancelled", "Submitted to the customer for clarification of requirements", "Another task was created", "Does not match". If the customer still asks why his task was closed, then it is not worth reopening it, it is better to create a new one.

When the first version is about to start developing, and there are already questions about it, you can start a second story, say "Extension of the MVP functionality" or "MVP 2.0" or something else, and drop everything that the team does not want to do now. Then, at any moment when it becomes clear that the deadline for the release of the first version has been completely disrupted, it will be possible to switch to the second version, and tell everyone "we thought about it and decided that it would be better to develop the target product architecture instead of legacy". And so on, to the third version, fourth ...

By and large, that's all - the imitation of the implementation of Agile is completed. Agile teams are formed, people are busy, sprints are snapping, rituals are going well.

Troubleshooting

The process is ongoing, but small problems may arise over time, so it is worth mentioning some well-known tricks for solving them.

Sprint goals not met

Coaches may have told you that every sprint should have a goal. Maybe they even mentioned that the sprint goal is thought up in the Sprint Planning ritual (aka grooming), and its achievement is then checked in the Sprint Review ritual (almost retro). And maybe your inexperienced product owner (or was it a Scrum Master?) remembered this and even decided to apply it.

It was a mistake. There is not and cannot be such a formal thing as a sprint goal in the Agile imitation, because teams are working on much more tangible things, like releasing the first version, that is, MVP, at the end of next year, and they have a closure tasks, problem solving, etc. for the short term prospect.

And when the team has sprint goals, it is necessary to come up with new goals every two weeks, and after two weeks somehow need explain why they are not being achieved. Well, at least these explanations occur only within the team and no one else needs them.

There are two ways to solve this problem - simple and radical. The first is to simply stop setting goals. In the end, your team of professionals already knows what to do, the necessary story is created and always stands in the sprint, as it stood in the last sprint, and will stand in the next one, and beyond. And PO has a daily, where he keeps his finger on the pulse of the team and can always direct it in the right direction. Every day in a new right direction.

The second way is a little more radical, but also quite simple - switch to Kanban. I mentioned above that there are several denominations of Agile, so Kanban is another one. It is much, much simpler than Scrum - it reduces the whole process to one board, on which the tasks go through the stages. The board is divided into columns, each column is a stage. A new task appears on the left, goes through the columns from left to right, then is removed from the board. It's all! This is the whole process. No rituals, no sprints, no goals. We move tasks and enjoy Agile. Thank to the developers of Atlassian, in the jira the transition from Scrum to Kanban is done with a wave of the hand.

But I will not recommend implementing Kanban instead of Scrum from the very beginning. It is precisely because of its simplicity that it will be difficult to sell just one board to top management as a modern, perfect, brilliant methodology. There, training is only for a day, well, two, and not for a month, and there are practically no rituals. It is better to "implement" Scrum, then quietly crawl to Kanban. Both this and that Agile, so no one will notice the substitution.

Life according to KPI

It is likely that at some point your top management will want to find out how you are progressing with the implementation of Agile, and in terms of efficiency improvements. Then you have the task of coming up with a metric that is easy enough to manage so that it shows the right numbers.

If you ask the coaches again, they will offer to measure the speed of closing tasks in response. By speed, they mean the number of tasks completed per sprint. In principle, not such a bad metric if you start a lot of tasks and then close them quickly.

If it didn’t work, and for some reason top management needs a metric that is closer to their business, they will probably remember the Time-To-Market indicator, that is, the time from the birth of an idea to its launch on the market. This is dangerous, a purely mechanical calculation can lead to disappointment in you, so you need to work carefully here.

The correct technique relies on the correct definition of the beginning of work and the end. For example, if we take the assembly of the finished release as the start of work, and the transfer for final testing as the end of work, then we can achieve an excellent result.

On the contrary, if the first presentation to the management is taken as the beginning, and the first feedback from customers is taken as the end, then the result of the T2M calculation will not be so good. I think you have already understood what needs to be done - to determine the start of work as late as possible, and the end as early as possible. And let the whole world wait.