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 involved in project management. Sometimes, however, I combine this role with the role of a systems analyst. In the industry since 2000, she began her career as a programmer and quietly degenerated into a manager who is interested in dealing with related fields. I’ll clarify right away that my opinion may not coincide with the position of the company that I represent here.

    I must say right away that by Agile I mean basically Scrum, although I am aware of the existence of other subspecies. These considerations, in my opinion, are more or less applicable to all flexible processes, that is, projects without a fixed scope at the beginning of work and with the confidence that the team will taxi out later. We will discuss below why the team does not always taxi out.

    I have a lot of experience in the industry of custom development, 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. the company).
    • This project is not compatible with Agile by nature.

    One reason is often enough to prevent the Agile project from surviving, 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

    The “Wrong Agile” sounds, of course, like an oxymoron - how can there be a clearly 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’ll clarify that by “team” I mean not only developers with testers and other techies, but everyone who is involved in the project in one way or another: end users and their representatives, managers of different levels, product owner, project sponsors and etc.

    For a successful project, not enough cool programmers (testers, designers, DBA ...), but still need, firstly, user involvement and a sane product owner; secondly, a clear synchronization of efforts, which is expressed in the application of the right practices (all of these birddowns, taskboards, demos, continuum integrations and retrospectives), and in the dissemination of 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 sounds pathetic, but perhaps not entirely wrong. Oddly enough, I do not remember a single successful Agile project where participants would not share the ideas of the Agile manifest (sometimes without even reading the manifest itself).

    Another component that I cannot but 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 keep in mind his interests.

    But all this will be useless if the team does not have an understanding of a common goal and a common criterion for success. And the global goal, 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 daily activities. Starting from which stories to take in the iteration, ending with what the priority of the bugs will be (which is more important to the users of our product - appearance or speed), or what story we will finish if there are only two days to the end of the iteration, and work - for three .

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

    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 understand the project’s success criteria unambiguously (and no, it’s not timely to deliver the entire project at the agreed price. It’s rather “users really need to solve this problem, for which we want to make these use case possible ”). At least basic knowledge of domain developers and their understanding of users will also be very useful.
    • Disassemble with the team the practice and process technology. Show how daily honest status updates help achieve global project goals.
    • Just in case, make sure that we have not forgotten such key things as acceptance criteria, early demos, retrospectives and feedback.

    Agile is poorly compatible with the project environment (customer company)

    People and interaction are more important than processes and tools.
    A working product is more important than comprehensive documentation.
    Collaboration with the customer is more important than negotiating the terms of the contract.
    Willingness to change is more important than following the original plan.
    (Agile manifesto)

    If a company has been working somehow for a long time, changing the existing process can be difficult and often impossible (for example, if by law the company is obliged to announce a tender and fix requirements and money, then ...). Fixed requirements and price are obvious signs of the V-model , and when working, for example, with Russian state-owned companies, you will not get any pure Agile.

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

    Sometimes it’s not so tough, and you have to fight not with external forces, but with some internal restrictions, such as the requirement to follow the templates when writing specifications (incompatible with the user story concept) or to issue a monthly report on the progress of the project in a certain way. With such procedures, the declaration “a working product is more important than exhaustive documentation” may cause bewilderment among top management.

    On the other hand, it’s not worth taking and throwing out the old rules, because they are “not Agile”. There are all sorts of useful, albeit boring and costly procedures, such as transferring code to support, or some kind of internal or external audit on the security of the product ...

    Total, if there is a realization that the environment is not quite friendly to Agile:
    • We divide the processes around into three groups: useful ones (which are needed so that the code later survives in the already existing infrastructure: security testing, configuration guides, etc.), those that you can get along with (some reports, 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 tasks, add it to the backlog, evaluate, sigh that the scope has suddenly grown slightly, and we are glad that we pulled it into the light, and now it’s approximately clear what to do.
    • As for the second, we enter into negotiations with those who are responsible for them in the company. You can try to find a compromise: agree on a more convenient template for us or agree on more suitable KPIs.
    • The biggest problem, of course, is with the third. If it so happened that you got involved in an Agile project, fixing some rigid framework on paper, as soon as you realized the scale of the disaster, you need to gather interested parties, including customers, to figure out how to minimize 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 that will change the scope and terms for those that turned out in the end.

    This project is not compatible with Agile by nature.

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

    The most striking, of course, will be an example of writing software that manages spacecraft - well, it’s hard to show customers landing a probe on a comet once every two weeks, receiving in response comments that it would be worthwhile to do differently from the point of view of physicists.

    Another striking example is some kind of telecom. When you write firmware for a phone, you absolutely do not need demo implementations of each next class of GSM protocol messages to potential users of a new phone.

    Another good example of the inapplicability of Scrum specifically is all sorts of support commands, when a ticket suddenly arrives from a user with zero priority, and everyone drops everything and fixes it. No predictability and rhythm will be gone.

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

    So, we started to do a project in Agile mode that is not compatible with the idea:
    • Stop trying to do Agile and start building a more appropriate process. At the same time, it is not necessary to abandon any process elements that are associated with Agile, but work everywhere.
    • The V-model with its seemingly 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 an iPhone startup, it does not mean that it is bad.
    • It may make sense to read about ITIL concepts, they are already 20 years old, and many work in them. In some cases, Service Desk can be crossed with Kanban, and get a really working true Agile process.
    • There are still all sorts of industrial practices and the own developments of large companies that may be suitable, especially if you solve a problem similar to what they were created for.

    In the end, I really want to add that the silver bullet, of course, does not exist. And for sure in your particular case, everything may be a little wrong.

    Thanks for attention.

    Also popular now: