Why Agile is a mistake. Project Manager's opinion

I want to start with the fact that I am not against Agile. But I am very surprised that they are trying to implement Agile not only where it is possible, but also where it is possible. It also confuses me that I see Agile doing more often than Agile being, but these are small things.

And of course, I am annoyed by the wording "this is your waterfull PMBOK" from people who are not so much even Agile doing, and sometimes even just HZing.

At the same time, I see how Agile tries to justify the problems and incompetence of various levels, which in general is the fault of the company/department/team leaders.

Before discussing the bugs, we'll take a quick look at where Agile is convenient and cool to use.

After that, I want to divide the theses of "errors" into two main groups.

1. Using Agile is a choice error
2. Using Agile is a cure for managers (mistakes in their work, to be more precise)

And it's a little different, in my opinion

I do not want to discuss now that some of the tools and techniques of Agile are older than Agile itself, but at the same time they have become popular right now. But the possible reasons-yes, we will discuss.

When Agile is great (in my opinion)

1. Creating IT products for the general public

That's what this very Agile was invented for, if you think about it. And why do I focus on the broad masses?

There are two messages:
a) it is easier to negotiate with a small number, it requires fewer iterations;
b) a small quantity, not seeing the result in an adequate time frame, is more likely to be disappointed in the product.

And a good example of this kind of product can be Notion( or its analogues), various high-load services such as Yandex or Avito services, or an application for your phone (insert your name).

P.S. In addition to iterations, sometimes increments can help you. And these are still two big differences.

2. Testing hypotheses or creating an MVP

Hypothesis testing is generally fun, useful, and interesting. For some, it is also extremely informative. Agile in this case helps to do it quickly and cheaply (and this, by the way, is something that people rarely hear from me: that Agile is cheap).

Creating an MVP – with the caveat that there is no clear task and a clear understanding of the final product type. Actually, that's why I combined hypotheses and MVP (yes, you can throw different things at me for this).

There are thousands of examples. And even the very landing pages on the Tilde that our entrepreneurs make before trying to sell something (two in one-both the hypothesis was tested, and the MVP of the site).

Suddenly, if you already have a contract for all the work – it's hardly worth calling an MVP. Well, just because the Go/No go solution no longer depends on it.

3. Creating products or implementing projects in an ever-changing environment

Important! This is rarely the case when creating information systems in the presence of technical specifications and regulations.

Why? Not even because of the reduction in planning costs (unexpectedly, but in classic Project management there are such tools as Rolling wave planning, and even short rescheduling cycles), but because of the perception of this rescheduling by people. There is some magic in this, but changing the backlog is easier than changing the plan, even a very short one.

In general, this is almost like the first point, but not for the masses. Well, for example, you made an application that was planned to work with 1C and "suddenly" the customer left for SAP (very suddenly, for a year or two, sarcasm).

No, actually, this is when you have a lot of integrations and the client can be very tied to them. Here it is difficult to plan what will invent the product with which your system or product interacts, because sometimes it is a product from point 1 and they just included a new feature in the sprint. And you have all fallen. By the way, this includes many sites that work with the site of public procurement. Sometimes updates bring a lot of fun.

4. Implementation of R & D projects

Perhaps this is debatable. I thought for a long time whether to highlight this point (after all, it can be considered as a hypothesis or an MVP), but I decided that after all, R & D is broader, and it's worth it.

No, they're planning a research project, too. But for some reason I see that when people have a PLAN (just like that), they rarely stop, if suddenly, in the early stages they achieve success. They see it as their goal to check everything that is in the plan, and this leads to a loss of time and money if there is no person who adequately sees the task (and many of them are enthusiastic natures). Or maybe not so much enthusiastic as worried about their jobs?

I will have a not entirely scientific example, but it will subtly hint where the legs grow from. The client was looking for a suitable piece of hardware. The first one came up. And both in terms of price and parameters (redundant, by the way). BUT ... the employees went to check 2 more and lost more than a month on this. Because they were told to watch "three pieces".

So, in the absence of a formal plan, quick win is perceived easier. And did I mention that, in my opinion, this is some kind of magic?

Probably everyone can offer at least 300 more unique scenarios that I have not listed, but I do not claim to be the only correct and absolutely complete opinion.

And now-mistakes.

When Agile is a choice error

1. Widespread adoption of Agile

You will look infinitely cool by putting a Kanban board in the sales department, but, however, it is worth stopping here. The client does not wait for 200 impressions (THIS IS SPARTA) to rent an office or choose a car. He waits for 3, maximum 5 cool options, then he gets tired.

And goes to another. Perhaps to your former employee.

2. Explain the wrong understanding or the same questions 5 times by implementing Agile. Agile analytics.

"I'm asking you the same question again, because we implemented Agile."

Does that sound cool? No. Just keep meeting records – it will look even more Agile.

Meet 30 times to discuss the section of the TOR or the statement-it happens, but it does not add any advantages to you.
I think any good product will tell you that if you come too often and without results, you will be sent sooner or later. Doing 3-4 iterations is fine.

No, really, I wouldn't have put it in here if I hadn't met it.

P.S. It is possible that the realtors are from this sect. "Are you sure you don't want an office of 300m2, even though you asked for 100m2?".

3. Implementation of "standard" Agile software products

I was surprised to see the introduction of boxed Agile solutions on the websites of many vendors or integrators. On websites, in conversations.

And, to be honest, I'm in a stupor. You are cruelly deceived or do not want to spend time on analysis and elaboration of productions.

If you need to correct 2-3 fields in the final form before acceptance – this is NOT Agile.

I am horrified to imagine the implementation of 1C for Agile:
Iteration 1: We put you a box, you can enter the data.

Iteration 2: We updated the forms to meet your requirements, but now we need to fill in the data for the missing fields again.

Iteration 3: We added analytics, but we need to recheck all the documents.

Iteration 4: You gave us feedback that there was an error in the form from iteration 2, we redid it and rolled back a month ago.

Two questions:

1. When will you be sent?
2. How much will you spend on adapting employees?

And I'm not talking about training and labor costs. Or should I shout?

Question – which of you saw in this picture the customer "ATM"?

And by the way, preliminary acquaintance of the client with the result of the work is also NOT Agile. This is common sense.

4. Agile processes

Perhaps this overlaps with past points. But have you already heard about internal Agile reporting? Or in general, it is desirable that it was reporting to the tax (any regulatory authority).

No? Why not, because it's fun to hand over some of the information, then send the updated one, then fix it (no, well, many people work like this, even without knowing about Agile).

And I already got a call from a familiar accountant and asked what kind of animal it was. It seems to have been rejected.

The processes must be. Perhaps not as strict as some managers see. But without them, there is anarchy of data and interaction.

When Agile is the Cure for Managers

To be honest, it was this section that made me write the entire note. I was sitting here, "smoking" in Agile with a fresh (almost) eye, and I was notably shot. It struck me that this way people want to be less dependent on m... confident managers.

In what sense? And how many of you have not faced problems at work because of the head? So, in a sense, Agile is the cure for such a manager.

I have always said that Agile tools are not new, but they have become so popular right now:
● Kanban-board – 1960 years
● Planning strategy-1940, Delphi method
● Theory X and Y - 1960 again

Why? That's what got me shot. No, this is not because everyone could read about them (although this also affects). Rather, this is due to the fact that people have the opportunity to see the experience of not only their own, their neighbor, brother and former classmate.

Thanks to the development of the Internet, we can see what is there in this Australia (Africa, America, insert the country of your dreams). And this does not apply only to the types, it also applies to the organization of work. And this is important. We spend most of our lives at work, and everyone wants it to be fun.

1. Employees do not want to work with managers, or self-organizing teams

Here I have two thoughts:
a) a very large number of supporters of the theory of X among managers,
b) non-acceptance of informal leaders.

Well, who among you has not experienced this to some extent?

When the boss is constantly trying to catch you for "doing nothing"? And he doesn't care that you have run out of "mysletoplivo" (thank you, Maxim Dorofeev).

And how many good specialists left simply because the manager does not consider the opinion of the leaders, and even more so just the team members... I have witnessed this repeatedly.

And this is really a big mistake of many managers. Forget about the opinion of a team member, because he is in the company for 3 months? OK, the countdown has started. Wait, the Agile troopers have already moved out.

2. And today let's make another # # of tasks, or WIP (Work-in-Progress) limits

And again, I have two thoughts:
a) the desire to do the work efficiently,
b) Work-life balance.

It happens that the work on the" dump " is done by the employee himself. The truth happens. But the more people are passionate about their work (and this is most of the engineers and developers, by the way), the less often this situation occurs. And, all the more often, it is the manager who accelerates and "kicks" employees with the words:" it works like this, do the following"," urgent plug " and so on.

Regarding the work-life balance, in general, this is about "cram in the non-cram". Or do not set the deadline "yesterday". Picture how the manager came from a meeting to discuss a small problem, and now you have a lot of work to redo the entire UI... until the end of this week, have you ever been there?

How many of you, after a couple of visits from the head with the words "and also this" sat up until night? I was sitting. And it's very ... demotivating, to say the least. Especially when you sit there and say, " where do I start, huh?"

WIP resolves this issue. Yes, you can try to speed up the execution of tasks, but definitely not take three hundred tasks at once.

3. Servant leader (aka servant, leadership-service, servant as a leader or leader as a servant)

And again, two points:
a) people are tired of "bosses",
b) it is necessary.

Why are you tired? So every second article on the Internet, where the boss is mentioned, somehow hints at the inability of the parties to agree and discuss. And, suddenly, I agree that it's the boss ' fault. His responsibility for solving the problem is higher than the fault of the performer.

Well, you really should. Maybe not always, but often. Having assembled a team, you need to believe in it and support it, help it, not lead it. And sometimes it is useful to be this very Servant. This can help in many ways, and not just for work. But not everyone is up to the challenge. And at this point, your employees begin to quietly chant the 12 principles. For now – just for lulz. And what will happen next?..

4. Limit sprints by volume

I would say that these are almost the same wips, in the context of this dialog. But there's a cool message here. WIP-it is still about the amount of work in the moment, but the sprint limit – it is no less useful.

At least because the tasks from the "limited" sprint will be done well with a higher probability than the "shaft" of tasks from the "mega" plan (P.S. here the office almost corrected me to the name of the software-so, the software is not to blame, believe me).

5. Inability to plan

This has nothing to do with Agile, it's just a problem.
And here it is worth adding a little humor:

I also see the problem in two parts:
a) unwillingness to reschedule,
b) unwillingness to plan.

The first is an essential attribute of adequate management. You are not in a vacuum, it is normal to refine and adjust the plan. But I often see how the plan lives on its own, and the work lives on its own.

The second sometimes comes out of the first. If everything is still not according to plan, then why plan, they say.
As sad as it is, they think so too.

The result is bad – and what else did you want when there is no goal and no deadline... and no, deadlines are not necessarily nailed down. But clear goals without a plan rarely appear. Or they remain top-level and obscure to employees.

In conclusion

I want to finish positively. Agile is not a bad thing. You just need to cook it properly.

It is not necessary to use it everywhere, sometimes it is necessary to select good managers so that the team is not so lonely in this war.

Do you think that the title is not suitable? We'll fix it in the next iteration.