March 15, 2019 at 15:50Are we agile or agile us?
What is the main problem in software development (or maybe in any job)? When I asked my colleagues a question, I received different answers: changes in requirements, expectations mismatch, code quality, interaction with other teams ... summing up for myself - communication is one of the most important problems.
During communication, everyone understands everything in their own way, interprets it differently than what was said. The customer keeps in his head a certain image that he is trying to convert into words and pictures, the developer, hearing these words, converts them in his head into some kind of his own image. And in this chain there can be many links.
Trying to solve this problem, people write a detailed ToR. But does this solve the problem? The same questions, as I see it, were asked by Bob Martin and Martin Fowler together with his colleagues when they wrote the Agile Manifest in February 2001. Let's try to figure it out together on this issue, and in the Agile manifest itself.
In the winter of 2000 there was a meeting of the leaders of the so-called Extreme Programming, they discussed development methodologies and as a result began to offer some Light methodologies. Few people were interested (I do not want to offend anyone), most likely they made more jokes on this topic. However, several outsiders of that meeting organized their own a year later. It all started with the fact that Bob Martin (he wrote the famous book about the quality of the code), made a newsletter to the leaders of the last meeting - let's get together and talk. Actually nothing concrete. For some time they bickered about the place and time. As a result, they gathered on February 11, 2001, in Utah, at a ski resort. 17 people from the development sector, including Bob Martin, Martin Fowler, and others. We drank, Fowler went skiing, and after discussions, he was bornAgile Manifest .
In principle, all the most important can be conveyed literally by a page of text, which can be read here .
But like everything short and meticulously thought out, to understand this simply by reading it was not easy for me personally. Therefore, let us consider in detail what those people who signed the Agile manifest had in mind.
At first glance, this may seem like a call to throw away all Jira projects, bug trackers, time loggers and other tools and all configured processes. What could be easier is to verbally discuss with colleagues what someone is doing. If only everyone was happy. But it looks a little utopian, right?
This principle suggests that when building the development process of anything, it is important to remember why it is done, for whom and for what purpose. It makes little sense to create a process for the sake of the process itself. Because the work will ultimately be done by people, you and I. What will happen if all the spark, all the interest in our eyes is replaced by task in the yutrek or bugs in the jir? It is worthless to a well-organized process that provides complete security before the customer, but does not solve real development problems. Bureaucratic (formal) details can easily lead to the loss of people on a project. I tend to think the same goes for planning. When was the last time you did the planning, which in the end at least 60-70 percent turned out to be accurate?
In my opinion, this principle of the manifest could sound like this:
What does the team develop in general? Product for the customer.
If interpreted as is, on the forehead, I think many will agree. But what else do you see here? Personally, I see here that a product that works, and works on time , is more important than perfectly written code. These are cruel and scary words in many respects, so I shouldn’t say that. But all my career I, learning from different people, became more and more convinced of the thought - if I choose between a project that is ideal in terms of code and architecture, and a project that is not very beautiful inside, but which benefits the world, I will choose the second one. And yes, I will improve it to the best of my ability and ability.
And here you should think for a moment. But what can be done to make these problems less common? So that we do not have to choose between refactoring a module and developing a new feature?
Pay attention to the point about technical excellence. Maintaining the code in good (necessary) and sufficient quality, we much easier to tolerate changes in requirements and, accordingly, changes in the code.
All principles, I remind you, are not negatives. One does not exclude the other. This is about prioritization. Everything is important - the product, the quality of the code, and the documentation. But what to choose, when to choose? Working in a certain balance between quality and product, the product is easier to put in priority, without denying quality.
As an example from my life, I recall the work on a banking project for a Russian customer. The work was carried out with the participation of analysts and strictly on volumetric TK. Once every six months, the manager went to the head office of the customer and showed the results of the work. It is easy to guess that, as a rule, the results were significantly different from the expectations of the customer. The customer’s accountant, who first saw the new system, and generally knew that it was being created, was in a state of horror - there was nothing like his usual work process in the new system. Which brings us to the next topic.
You must be very careful with this statement. And again, remember that the right side of the statement is not denied. On the contrary, we say that the contract is important. Just when we weigh the terms of the contract and cooperation, the right long-term partnerships, then the relationship will be more important. Without denying the second. I draw such attention to this because we live in the real world and sometimes we have to work with very different customers. There are cases when the customer for his own selfish purposes can take advantage of naivety and, at the expense of the contract, beat out conditions that are unacceptable to developers.
Nevertheless, if we talk about a certain abstract good customerin a vacuum , then maintaining a long-term relationship that will lead to new projects is more important.
How to achieve understanding and compliance with expectations throughout the project?
At the same time, one should certainly not forget about confirming the agreements for their own safety. There are by the way (fortunately rarely) customers who generally refuse to pay after the agreements.
Whatever the customer, activity from the developer is always useful.
I would also add on my own that this should work both ways.
This leads us to a logical continuation - changes in work and plans. Few people like to make changes, it’s in the nature of man, if you think about it. Any system strives for a certain point of equilibrium and immutability. But it is development that is always associated with movement and change.
The existence of a plan as such is not denied. On the contrary, the plan is important. But it’s even more important to be prepared to change it, if at some point we realized that this plan no longer works in the current environment.
An example from the practice of my colleagues is a project for a tax inspection of one of the CIS countries. The state project, in essence, TK, legislation, there was no talk about any agile. But the team had to show flexibility at the moment when the state in the customer’s country changed its tax legislation so that the project would not make sense at all in the form in which it was planned. I had to change the technical specifications and redo the almost finished project so that the customer could use it. Otherwise, there would be no point in the work, well, except perhaps for earnings as such.
Perhaps this is not the most revealing example, since the changes were provoked by external factors. And on the other hand, the customer can, again due to external factors, just come to the necessity of changing requirements. Otherwise, he will not get a competitive advantage.
This all touches on a slightly painful topic for me. But what if we are doing a project for a whole year, and then a year later the customer says - okay, you are great, and now we will put all this in the archive, we will not use it and we will start a new project. I am rather painful towards this, I had a similar experience. But really - what happened? The work done helped the customer to understand that the chosen path is incorrect. Or ineffective. To get a competitive advantage, you need to work differently, do another project. And he received this knowledge with our help.
What aspects of our work will help smooth these corners and make the flexibility less frightening?
At the same time, we live in the real world, with real people, where no judgment, including this, should be raised to the absolute. Yes, changes are welcome when they lead to added value to the final product. But it is important to maintain balance. If we make changes endlessly, we will never release a product in production. Therefore, at some point you should say - stop, we release the product, check everything in practice, and begin to make version two, which will contain these changes. Each time clarifying with the customer - what value he sees in this or that change.
I recently read the phrase on Facebook,
The creators of the Agile manifesto do not prescribe any rules, and even vice versa. But they raise important issues in our work - the interaction of people, developers and customers, readiness for change. These principles are important in nature. With the undeniable importance of documentation, contracts, processes and planning, human interaction, readiness for valuable changes and bringing something useful to the world are all the more important.
During communication, everyone understands everything in their own way, interprets it differently than what was said. The customer keeps in his head a certain image that he is trying to convert into words and pictures, the developer, hearing these words, converts them in his head into some kind of his own image. And in this chain there can be many links.
Trying to solve this problem, people write a detailed ToR. But does this solve the problem? The same questions, as I see it, were asked by Bob Martin and Martin Fowler together with his colleagues when they wrote the Agile Manifest in February 2001. Let's try to figure it out together on this issue, and in the Agile manifest itself.
History
In the winter of 2000 there was a meeting of the leaders of the so-called Extreme Programming, they discussed development methodologies and as a result began to offer some Light methodologies. Few people were interested (I do not want to offend anyone), most likely they made more jokes on this topic. However, several outsiders of that meeting organized their own a year later. It all started with the fact that Bob Martin (he wrote the famous book about the quality of the code), made a newsletter to the leaders of the last meeting - let's get together and talk. Actually nothing concrete. For some time they bickered about the place and time. As a result, they gathered on February 11, 2001, in Utah, at a ski resort. 17 people from the development sector, including Bob Martin, Martin Fowler, and others. We drank, Fowler went skiing, and after discussions, he was bornAgile Manifest .
In principle, all the most important can be conveyed literally by a page of text, which can be read here .
But like everything short and meticulously thought out, to understand this simply by reading it was not easy for me personally. Therefore, let us consider in detail what those people who signed the Agile manifest had in mind.
Agile Principles
That is, without denying the importance of what's on the right,This is a very important aspect that must always be kept in mind when reading a manifesto, and indeed every day in work. Let's discuss the main manifest statements.
we still value more on what's on the left.
People and interaction are more important than processes and tools
At first glance, this may seem like a call to throw away all Jira projects, bug trackers, time loggers and other tools and all configured processes. What could be easier is to verbally discuss with colleagues what someone is doing. If only everyone was happy. But it looks a little utopian, right?This principle suggests that when building the development process of anything, it is important to remember why it is done, for whom and for what purpose. It makes little sense to create a process for the sake of the process itself. Because the work will ultimately be done by people, you and I. What will happen if all the spark, all the interest in our eyes is replaced by task in the yutrek or bugs in the jir? It is worthless to a well-organized process that provides complete security before the customer, but does not solve real development problems. Bureaucratic (formal) details can easily lead to the loss of people on a project. I tend to think the same goes for planning. When was the last time you did the planning, which in the end at least 60-70 percent turned out to be accurate?
In my opinion, this principle of the manifest could sound like this:
Processes for people, not people for processesHow does the manifesto suggest that we get closer to implementing this principle?
- Motivated professionals should work on the project.
- Direct communication is the most practical and effective.
- The best requirements and architectural solutions come from self-organizing teams.
- The team must constantly analyze their work and optimize the process.
What does the team develop in general? Product for the customer.
A working product is more important than comprehensive documentation
If interpreted as is, on the forehead, I think many will agree. But what else do you see here? Personally, I see here that a product that works, and works on time , is more important than perfectly written code. These are cruel and scary words in many respects, so I shouldn’t say that. But all my career I, learning from different people, became more and more convinced of the thought - if I choose between a project that is ideal in terms of code and architecture, and a project that is not very beautiful inside, but which benefits the world, I will choose the second one. And yes, I will improve it to the best of my ability and ability. And here you should think for a moment. But what can be done to make these problems less common? So that we do not have to choose between refactoring a module and developing a new feature?
- A working product should be released as often as possible.
- A working product is a key indicator of progress.
- Continuous attention to technical excellence and quality enhances project flexibility.
- Simplicity and minimization are necessary.
Pay attention to the point about technical excellence. Maintaining the code in good (necessary) and sufficient quality, we much easier to tolerate changes in requirements and, accordingly, changes in the code.
All principles, I remind you, are not negatives. One does not exclude the other. This is about prioritization. Everything is important - the product, the quality of the code, and the documentation. But what to choose, when to choose? Working in a certain balance between quality and product, the product is easier to put in priority, without denying quality.
As an example from my life, I recall the work on a banking project for a Russian customer. The work was carried out with the participation of analysts and strictly on volumetric TK. Once every six months, the manager went to the head office of the customer and showed the results of the work. It is easy to guess that, as a rule, the results were significantly different from the expectations of the customer. The customer’s accountant, who first saw the new system, and generally knew that it was being created, was in a state of horror - there was nothing like his usual work process in the new system. Which brings us to the next topic.
Collaboration with the customer is more important than negotiating the terms of the contract
You must be very careful with this statement. And again, remember that the right side of the statement is not denied. On the contrary, we say that the contract is important. Just when we weigh the terms of the contract and cooperation, the right long-term partnerships, then the relationship will be more important. Without denying the second. I draw such attention to this because we live in the real world and sometimes we have to work with very different customers. There are cases when the customer for his own selfish purposes can take advantage of naivety and, at the expense of the contract, beat out conditions that are unacceptable to developers. Nevertheless, if we talk about a certain abstract good customer
How to achieve understanding and compliance with expectations throughout the project?
- Throughout the project, developers and representatives of the custom business must work together daily.
- Direct communication is the most practical and effective.
At the same time, one should certainly not forget about confirming the agreements for their own safety. There are by the way (fortunately rarely) customers who generally refuse to pay after the agreements.
Whatever the customer, activity from the developer is always useful.
I would also add on my own that this should work both ways.
This leads us to a logical continuation - changes in work and plans. Few people like to make changes, it’s in the nature of man, if you think about it. Any system strives for a certain point of equilibrium and immutability. But it is development that is always associated with movement and change.
Preparedness for change is more important than following the original plan.
The existence of a plan as such is not denied. On the contrary, the plan is important. But it’s even more important to be prepared to change it, if at some point we realized that this plan no longer works in the current environment. An example from the practice of my colleagues is a project for a tax inspection of one of the CIS countries. The state project, in essence, TK, legislation, there was no talk about any agile. But the team had to show flexibility at the moment when the state in the customer’s country changed its tax legislation so that the project would not make sense at all in the form in which it was planned. I had to change the technical specifications and redo the almost finished project so that the customer could use it. Otherwise, there would be no point in the work, well, except perhaps for earnings as such.
Perhaps this is not the most revealing example, since the changes were provoked by external factors. And on the other hand, the customer can, again due to external factors, just come to the necessity of changing requirements. Otherwise, he will not get a competitive advantage.
This all touches on a slightly painful topic for me. But what if we are doing a project for a whole year, and then a year later the customer says - okay, you are great, and now we will put all this in the archive, we will not use it and we will start a new project. I am rather painful towards this, I had a similar experience. But really - what happened? The work done helped the customer to understand that the chosen path is incorrect. Or ineffective. To get a competitive advantage, you need to work differently, do another project. And he received this knowledge with our help.
What aspects of our work will help smooth these corners and make the flexibility less frightening?
- Regular and early software delivery.
- Changes are welcome even in the later stages.
- Changes help provide the customer with a competitive edge.
At the same time, we live in the real world, with real people, where no judgment, including this, should be raised to the absolute. Yes, changes are welcome when they lead to added value to the final product. But it is important to maintain balance. If we make changes endlessly, we will never release a product in production. Therefore, at some point you should say - stop, we release the product, check everything in practice, and begin to make version two, which will contain these changes. Each time clarifying with the customer - what value he sees in this or that change.
I recently read the phrase on Facebook,
if you are not ashamed of your product, then you entered the market too lateQuite accurately reflects the essence of the above. We need to look for a certain point of balance, in which the product will be ready enough for the next release in terms of changes, and in which we have not yet begun to spend too much effort on minor changes.
Instead of summing up
The creators of the Agile manifesto do not prescribe any rules, and even vice versa. But they raise important issues in our work - the interaction of people, developers and customers, readiness for change. These principles are important in nature. With the undeniable importance of documentation, contracts, processes and planning, human interaction, readiness for valuable changes and bringing something useful to the world are all the more important.