29 years of trampling in place. Why are approaches to software development not evolving? / Hebrew

29 years of trampling in place. Why are approaches to software development not evolving? / Hebrew

Scrum appeared in the fall of 1995 and is still the most popular Agile software development framework. The first Scrum guide back in 2001 included everything most of us have encountered: roles, artifacts, and ceremonies (sprint planning, stand-ups, demos, and retrospectives). The concept was refined, but it was the same Scrum with which almost everyone in IT worked at least a little in one form or another.

At the same time, a giant leap was made in terms of technology: dozens of front-end and back-end frameworks that determined the appearance of the modern Internet appeared and became an integral part of our lives, mobile phones and applications for them, cloud technologies, blockchain, AI and IoT . Technologies have developed so much that they allow billions of people to access almost any information and services anywhere in the world.

However, in the field of project approaches and Scrum in particular, there is not even a hundredth part of this progress, they have remained practically unchanged, although there is a clear dissatisfaction with the final results, both from the business and from the direct executors. How did this happen and what to do about it?

Second player in development approaches

In addition to light approaches such as Scrum and Kanban, there are also difficult project approaches, they mostly appeared before agile:

  • 1975 – PMI (Project Management Institute) was organized in the USA. They are the ones who publish PMBoK (since 1996) – a guide for project managers. This is the most popular standard for project management around the world, I will talk about it later in the text.

  • 1989 – the PRINCE2 standard from Great Britain was organized.

  • 1996 – Microsoft and IBM formed RUP approaches.

All these standards represent a description of the successive processes of development and implementation of the project, aimed at keeping it in the triangle “terms – budget – content”. They were born from the personal experience and practice of the progenitors of the standards, who tried to systematize those approaches and solutions that worked well in their projects and transfer knowledge to other managers.

They are called hard design approaches because they are more formalized and detailed, and focus more on practical methods and processes than on general approach and philosophy. It is enough to compare the volumes of publications in English: the Scrum guide on 14 pages and the PMBoK of the 7th edition on 370 pages. I will not dwell on their fundamental differences, but one cannot fail to note that the Agile family of frameworks and hard approaches have been in close contact for many years and have influenced each other and how projects and products in the field of software are developed.

The concept reflected in PMI’s PMBoK has not stood still, as has Scrum, currently available in its 7th edition. However, little has changed in essence, but, for example, PMBoK first described the agile development methodologies of Scrum and Kanban in the 5th edition in 2013 as a possible option, and fully included the practices already in the 6th edition with extended recommendations for use.

A few words about project management software

Progress in this area is tangible and visible, but there are not many gold standards that everyone uses, such as the Git version control system in software development. Git appeared in 2005, by the way, and its predecessor SVN in 2000, I even found working projects on SVN, although I’m not that old anymore.

Tasks are kept in task trackers instead of physical boards, documentation is stored in a wiki and managed jointly in real time. To simplify the construction of plans and resource planning, software is used to build a Gantt chart, it allows you to conveniently monitor the progress of the project, noting deviations.

There is high competition among software: the best UI/UX experts fight for every pixel of interfaces, and developers for every millisecond of performance (or not, but I use cloud Jira, maybe this is the problem). The latest trend is the use of AI for the utilitarian needs of the project manager: recording the meeting and summarizing in writing, generating and sketching ideas, sketching risk planning document templates, etc.

We’re all a bit retrograde when it comes to processes

The need to complete business tasks to earn money is huge, large services choose to increase the conversion of 0.001%, which is in the millions of profits. There is a demand to increase the efficiency of products and projects, but neither Scrum/Kanban nor classical project approaches offer over the years drastic and radical changes in themselves to ensure this. What is the reason?

Because Agile and classic project approaches are the embodiment of basic principles for solving problems. The human brain is one of the most complex things in the universe, and in project management, we deal with dozens of other people’s unique brains, interactions between them, and crippling uncertainty.

These factors form two key approaches:

  1. Hard methodologies are good when we have a rough idea of ​​what we want to get. For example, we need a site, we have already made sites, but we need to decide what it should be. In this case, we collect requirements, write documentation, determine the scope of work, budget and estimate deadlines. Development can be carried out using Scrum sprints or Kanban boards, the essence of the approach is: the desire to take into account the maximum number of details before the start of development with the help of design tools and methods.

  2. Flexible methodologies are based on the premise that it is impossible to predict everything and it makes no sense to design and plan for a long time, and the truth is better to be sought in the process. In particular, Scrum is good when we have a vague goal and we don’t know in what form it can be solved. Let’s imagine that we are developing a program for fitness. We know that users want to track their progress, but we don’t understand exactly how they would like to do it – through graphs, texts or prompts. Instead of spending months building the final version of the app, we start with a simple prototype, get feedback from users, test different approaches, and gradually improve it.

Note that neither approach has ultimate advantages over the other, and each has its own set of drawbacks and limitations. I think that every experienced IT person can remember an example of a couple of failed projects using each methodology, or even not a couple, but a dozen or so.

Although development approaches have not changed significantly for many years, I hope that a new methodology will emerge in the next 20 years. How this will work is still not fully understood, but the key challenge is to look at uncertainty in a new way, move in several directions at once to reduce it, consider multiple options, and make quick decisions about solving problems. Yes, I know, more like fantasy, but everyone should have their dreams 🙂

Don’t forget the people

Any software development involves dealing with basic things: content, deadlines, budget, people and relationships between them. And it is people who are humanity’s main enemy in post-uncertainty design approaches.

These are the people themselves: we are imperfect, complex, completely unrecognizable even by ourselves, we think differently, we overcome conflicts and problems, we can have personal interests that conflict with the interests of other people and the team. Sometimes we show not our best features: stupidity, greed, indecision, incompetence, laziness. All of the above without the slightest judgment is simply a given that we live and interact with every day.

We meet many people during our IT life, the classic conflict “bad project – bad developer” has already filled the oscum and can never be completely eradicated. But I want to give you a hint: appreciate the colleagues who fight uncertainty side by side with you and especially those who warm your soulnot an ass. The next time you’re at a face-to-face meeting, hug a project or developer you appreciate and tell them, “I want to spend the next thousands of meetings with you!” 🙂

Related posts