Agile everyone has his own: how to go with the flow, manage projects and not to suffer
Agile is a fashion, a trend, a word that flashes everywhere and everywhere (yielding, it seems, only to coaching).
Of course, you know that this is a flexible software development method. Some learn: they go to courses, listen to lectures, then with hellish pain they introduce these principles into the process of the team’s work, while others simply work conscientiously, without trying to call it fashionable “Agile”. There is not and cannot be any ideal solution, because all people are different, with different rhythms, ideas about work and characters. And not all teams can work on the same principles.
We talk about the fact that Agile is not a set of rules, carved in stone, but tips that teams can apply. Or not. We learn to wisely approach the organization of the workflow. And to use in practice only those principles that are close to you (well, the customer!).
')
Our idea is simple: you cannot blindly follow the trends and start working on the new system on Monday. Trying to do it = fill up the workflow. INP, Agile - expectations from the current methodology may not coincide with reality. If your work after trying to implement Agile looks like this, do not be alarmed. You are on the right track (probably):
// Your mailbox is full of comments, and Jira has a lot of new tasks. But you desperately systematize them and try to even look at the analytics.
// Your clients try to perceive the process of your work adequately and sometimes even realize how the software is created and launched.
// Your code is not perfect, you change everything until the last moment, you screw something, and this is normal. You do not write comments to each new symbol, and sometimes development troubles happen to you.
// You are rolling out new versions, endlessly testing something, but this is not always the key to perfect work. Even if everything goes according to schedule.
// The customer is always in touch with you. Around the clock, from each printer looks at your work.
// Sometimes a full Scrum happens on your team, then everyone really runs like sprinters, and also tries to be flexible and see colleagues in general!
// “A working product is the main indicator of progress,” says the Agile Manifesto. Bicycle rides, and then fasten the pedals.
But seriously, you should not take the Agile Manifesto as a Bible.
Or categorical statements about what is good and what is bad. The point is to adjust and optimize work, reduce time costs, roll out the product wisely, please the customer. So read between the lines and know that even in the 4 basic principles of Agile, you need to see not categorical rules, but the ability to prioritize:
People and interaction (communication) is more important than processes and tools.
And this does NOT mean that the processes and tools are not important. Well-established processes are what allow companies to learn and improve over time, and following established procedures leads to results. Tools can fundamentally change the attitude of a team to problems and the ability to solve them. There is such a famous saying: if you have only a hammer, then every problem looks like a nail. Do not be fooled by this and continue to introduce new tools, streamline processes within the company and at the same time pay attention to people.
A working product is more important than comprehensive documentation.
And this certainly does not mean that documentation is overvalued and conservative nonsense.
Not every detail of every line of code needs to be commented and documented, as not every requirement should be described at the micro level. But without proper documentation, you risk losing a lot of time with any changes in your product, and also breaking everything that has been done for a long time and with difficulty. If you do not know where you are, you will not be able to get where you want. Well, do not forget that people sometimes get sick, quit, well, retire - collect as much information as possible so that the change of team members never leads to a slowdown.
Cooperation with the customer is more important than agreeing the terms of the contract.
And this certainly does not mean that the terms of the contract is nonsense. This is not true. For example, it may well be that the conditions are broad and the specific result you have not registered before starting the work on the product). And if both parties cooperate, help each other, then in the end all participants must be satisfied. The only question is whether you have not contacted people who do not rummage at all in the creation of software. Then the work will not go smoothly, and the requirements for the result may be insane.
Readiness for change is more important than following the original plan.
And this certainly does not mean that nothing needs to be planned. Plan - this is important, it is generally the miraculous basis of Agile. But the point is that the plan does not need to be knocked out in the stone immediately. You need to work and improve on it. A plan for the near future should be. Thanks to him, you can assign responsibilities, delegate tasks and monitor the solution to each problem. The short-term plan can be changed if necessary, at the request of your customer.
Of course, you know that this is a flexible software development method. Some learn: they go to courses, listen to lectures, then with hellish pain they introduce these principles into the process of the team’s work, while others simply work conscientiously, without trying to call it fashionable “Agile”. There is not and cannot be any ideal solution, because all people are different, with different rhythms, ideas about work and characters. And not all teams can work on the same principles.
We talk about the fact that Agile is not a set of rules, carved in stone, but tips that teams can apply. Or not. We learn to wisely approach the organization of the workflow. And to use in practice only those principles that are close to you (well, the customer!).
')
Our idea is simple: you cannot blindly follow the trends and start working on the new system on Monday. Trying to do it = fill up the workflow. INP, Agile - expectations from the current methodology may not coincide with reality. If your work after trying to implement Agile looks like this, do not be alarmed. You are on the right track (probably):
// Your mailbox is full of comments, and Jira has a lot of new tasks. But you desperately systematize them and try to even look at the analytics.
// Your clients try to perceive the process of your work adequately and sometimes even realize how the software is created and launched.
// Your code is not perfect, you change everything until the last moment, you screw something, and this is normal. You do not write comments to each new symbol, and sometimes development troubles happen to you.
// You are rolling out new versions, endlessly testing something, but this is not always the key to perfect work. Even if everything goes according to schedule.
// The customer is always in touch with you. Around the clock, from each printer looks at your work.
// Sometimes a full Scrum happens on your team, then everyone really runs like sprinters, and also tries to be flexible and see colleagues in general!
// “A working product is the main indicator of progress,” says the Agile Manifesto. Bicycle rides, and then fasten the pedals.
But seriously, you should not take the Agile Manifesto as a Bible.
Or categorical statements about what is good and what is bad. The point is to adjust and optimize work, reduce time costs, roll out the product wisely, please the customer. So read between the lines and know that even in the 4 basic principles of Agile, you need to see not categorical rules, but the ability to prioritize:
People and interaction (communication) is more important than processes and tools.
And this does NOT mean that the processes and tools are not important. Well-established processes are what allow companies to learn and improve over time, and following established procedures leads to results. Tools can fundamentally change the attitude of a team to problems and the ability to solve them. There is such a famous saying: if you have only a hammer, then every problem looks like a nail. Do not be fooled by this and continue to introduce new tools, streamline processes within the company and at the same time pay attention to people.
A working product is more important than comprehensive documentation.
And this certainly does not mean that documentation is overvalued and conservative nonsense.
Not every detail of every line of code needs to be commented and documented, as not every requirement should be described at the micro level. But without proper documentation, you risk losing a lot of time with any changes in your product, and also breaking everything that has been done for a long time and with difficulty. If you do not know where you are, you will not be able to get where you want. Well, do not forget that people sometimes get sick, quit, well, retire - collect as much information as possible so that the change of team members never leads to a slowdown.
Cooperation with the customer is more important than agreeing the terms of the contract.
And this certainly does not mean that the terms of the contract is nonsense. This is not true. For example, it may well be that the conditions are broad and the specific result you have not registered before starting the work on the product). And if both parties cooperate, help each other, then in the end all participants must be satisfied. The only question is whether you have not contacted people who do not rummage at all in the creation of software. Then the work will not go smoothly, and the requirements for the result may be insane.
Readiness for change is more important than following the original plan.
And this certainly does not mean that nothing needs to be planned. Plan - this is important, it is generally the miraculous basis of Agile. But the point is that the plan does not need to be knocked out in the stone immediately. You need to work and improve on it. A plan for the near future should be. Thanks to him, you can assign responsibilities, delegate tasks and monitor the solution to each problem. The short-term plan can be changed if necessary, at the request of your customer.
Source: https://habr.com/ru/post/326130/
All Articles