Agile bothers me and I want to talk about it

My name is Ekaterina Shalapanova, I have been working in DataArt since 2008, I am mainly engaged in project management. Sometimes, however, I combine this role with the role of a system analyst. In the industry since 2000, she began her career as a programmer and imperceptibly turned into a manager who is interested in the related fields. Immediately I will clarify that my opinion may not coincide with the position of the company I represent here.

At once I will state that by Agile I mean basically Scrum, although I am aware of the existence of other subspecies. These arguments, according to my feelings, are more or less applicable to all flexible processes, i.e., projects without a fixed scope at the beginning of the work and with confidence that the team will get out later. Speech below will be about why the team does not always taxi.
')
I have quite a lot of experience in the custom development industry, plus I really like to sit on other people's retrospectives.

So: why is Agile not working?

In fact, each project is unhappy in its own way, but if you dig deeper, everything can be reduced to three main reasons:

• This is the wrong command, and it is doing the wrong agile.
• Agile is poorly compatible with the project environment (i.e., company).
• This project is by nature incompatible with Agile.

One reason is often enough for an Agile project to not survive, but when we have a combination of several, the end is a bit predictable.

Next - a few lines about each of these reasons.

This is your agile wrong

“Wrong Agile” sounds, of course, like an oxymoron - how can there be an unequivocally right or wrong approach based on the notion of flexibility?
It's simple - the team does not quite understand the essence of the approach and does not do the things necessary for the success of the project.

Before going further I will clarify that by “team” I mean not only developers with testers and other techies, but everyone who is somehow involved in the project: end users and their representatives, managers of different levels, product owner, project sponsors and t. n.

For a successful project, there are not enough tough programmers (testers, designers, DBA ...), and, first of all, user involvement and a sane product owner; secondly - a clear synchronization of efforts, which is expressed in the application of correct practices (all these here are Berndauns, taskboards, demos, continuity of integration and retrospectives), and in disseminating information about the progress of each user story, and about the meaning of the project as such.

If you say that Agile is a way of thinking, it will sound pathetic, but perhaps not completely wrong. Oddly enough, I don’t remember a single successful Agile project where the participants would not share the ideas of the Agile Manifest (sometimes without even reading the manifesto itself).

Another component that I cannot fail to mention is the mutual respect of all team members. We must respect the customer, the customer must respect us, the team must listen to the opinion of each member and bear in mind his interests.

But all this will be useless if the team does not have an understanding of the common goal and the general criterion of success. Both global goals and short-term goals.
Only by understanding the purpose of the project and the signs of its achievement, the team is able to make the right decisions in their daily activities. Starting with what stories to take in the iteration, ending with what the bugs will have priority (which is more important for the users of our product - appearance or speed), or what history we will finish, if only two days are left until the end of the iteration, and works for three .

Do not forget that the team members also have personal goals, and if you help colleagues achieve them, the pleasure of working together will still increase. Example - when choosing from two approximately equal and equally unfamiliar technologies, choose the one that one of the team members has long wanted to explore.

So, if there is a feeling of “wrong Agile”:

• To start with a high-level goal-setting is to make sure that both we and the users clearly understand the criteria for project success (and no, this is not the time to deliver the entire scoop at the agreed price. It’s rather "users really need this problem to solve. make it possible to use these here ”). At least basic knowledge of developers in the domain domain and their understanding of users will also be very useful.
• Disassemble practices and process technologies with the team. Show how daily fair status updates help in achieving global project goals.
• Make sure, just in case, that we have not forgotten such key things as acceptance criteria, early demos, retrospectives and feedback.

Agile is not compatible with the environment of the project (the company of the customer)

People and interaction are more important than processes and tools.
A working product is more important than comprehensive documentation.
Cooperation with the customer is more important than agreeing the terms of the contract.
Readiness for change is more important than following the original plan.
(Agile manifesto)

If a company has been working for some time, it can be difficult and often impossible to change the established process (for example, if by law an enterprise is obliged to announce a competition and fix requirements and money, then ...). Fixed requirements and price are clear signs of a V-model , and when working, for example, with Russian state-owned companies, you will not have any pure Agile.

Just because if you act as if “readiness for changes is more important than following the original plan” and “cooperation with the customer is more important than agreeing the terms of the contract,” at the end of the project you will be rolled out of the penalty for the undelivered functionality.

Sometimes things are not so hard, and you have to butt not with external forces, but with some internal restrictions, such as the requirement to follow the templates when writing specifications (incompatible with the concept of user story) or to issue a monthly report on the project in a certain form. With such procedures, the declaration “a working product is more important than comprehensive documentation” may cause confusion among the top management.

On the other hand, absolutely here to take and throw out the old rules, because they are “not Agile”, are also not worth it. There are all sorts of useful, albeit boring and paper-intensive procedures such as sending a code in support, or some kind of internal or external audit of product safety ...

So, if there is an awareness that the environment is not very friendly to Agile:

• We divide the processes around into three groups: useful (which are necessary for the code to then survive in the already established infrastructure: security testing, configuration guides, etc.), those with which you can get along (some kind of reporting, templates, design requirements code according to GOST or corporate standards inherited from procedural languages), and those that are not compatible with Agile at all.
• We turn the first one into a task, add it to the backlog, evaluate it, sigh, that the scoop has suddenly grown a bit, and we are glad that we pulled it out into the light, and now it’s pretty clear what to do.
• As for the second, we enter into negotiations with those responsible for them in the company. You can try to find a compromise: agree on a template that is more convenient for us or agree on more suitable KPIs.
• The biggest problem, of course, with the third. If it so happens that you got involved in the Agile project, fixing some rigid frameworks on paper, as soon as you realized the scale of the disaster, you need to collect interested parties, including customers, to figure out how to minimize the damage and get out with minimal losses. In the end, a miracle can happen, and you will be able to write such an additional agreement, which will change the scopes and deadlines for those that turned out in the end.

This project is not compatible with Agile by nature.

No matter how hard Agile evangelists realize, but there are many problems in the world in which no Agile will work.

The most striking, of course, would be an example of writing software that manages spacecraft — well, it’s difficult once two weeks to demonstrate to a customer a probe landing on a comet, receiving in response comments that it would be different from the point of view of physicists.

Another prime example is some kind of telecom. When you are writing the firmware for the phone, you absolutely do not need the demo implementation of each of the next class of GSM protocol messages to potential users of the new phone.

Another good example of the inapplicability of Scrum is all kinds of support teams, when a ticket from a zero priority user suddenly arrives, and everyone throws everything and fix it. No predictability and rhythm will be gone.

On the other hand, even if we develop spacecraft, mobile phones, or program home appliances, there are tasks that can and should be done by Agile, showing intermediate results to potential users.

So, we started to do in Agile mode a project that is not compatible with the idea:

• Stop trying to do Agile and start building a more suitable process. In this case, it is not necessary to abandon any elements of the process that are associated with Agile, but work everywhere.
• The V-model, with its, at first glance, monstrous trace of requirements to the code and from the code to the test case, works as it should in the cases for which it is intended. If something is not suitable for a start-up iPhone developer, this does not mean that it is bad.
• It may make sense to read about the concept of ITIL, they are already 20 years old, and many work in them. In some cases, the Service Desk can be crossed with Kanban, and you can get an actually working true Agile process.
• There are still all sorts of industrial practices and own development of large companies that may be suitable, especially if you solve a problem similar to what they were created for.

Finally, I really want to add that a silver bullet, of course, does not exist. And surely in your particular case, everything may be a little bit wrong.

Thanks for attention.