Agile in document flow
“Agitating developers for agile is like telling that the Earth is round. Yes, there are also customers who prefer a long and tedious process according to GOST (aka waterfall) with the production of tons of documentation that no one will ever read, but usually in such projects, the real goal is not to create a really working system, but to properly use budget spending .
Agile in the software industry has become the norm. For today there is no other methodology that allows you to manage projects in conditions of high uncertainty and variability of requirements. ”
')
Article journalist-analyst Stanislav Makarov.
Imagine if you had to manage a project to develop a software product using traditional workflow - incoming-outgoing, office memos, meeting minutes, and other bureaucracies. What are the chances to meet the deadline and budget? That's right, zero. Not even the toughest control of performance will help. And not at all because your programmers, slackers and slobs, who cannot even come to work on time, dress strangely and do not understand what.
Problems in the methodology itself: it is assumed that everything can be foreseen in advance and give the performers clear instructions on what to do. In an ideal system, this could work, but, alas, most often we have a lot of deviations from the plan that no even the wisest boss could foresee.
This is where the system begins to fail, since each change must be coordinated along a hierarchical chain. All participants in the process prefer to merge responsibility so as not to be the last thing in the end - the initiative is punishable! A bunch of small questions are being dumped on the boss, which he needs to resolve personally. The decision-making cycle is stretched out, the terms are floated - and there are no guilty ones, unless they specifically appoint someone later. The command-administrative system does not have sufficient flexibility to respond in time to changes in the situation, whether it is difficulties encountered in the implementation of the project, or new customer requirements.
In short, the boss is always right. And if not right, then see point one. Everyone is sitting and waiting for guidance, horizontal connections do not work.
Document management is not at all such a harmless thing as it seems. In fact, this is the embodiment of the management concept, which is based on a strict hierarchy, prevention of initiative and lack of teamwork.
In general, it all comes down to the classical principle of "divide and conquer."
It is necessary for the organization to grow a little, as she begins to dream of introducing a document flow, so that everything is “like the big ones”. Nobody argues, the order in the documents is needed, and then, it's not even an hour, any monitoring authorities will descend or an important document from the client will get lost in the stream. All this is correct, just do not start copying the state bureaucracy at its worst.
If you take it on a large scale, EDS covers two functional areas:
It happened so historically and now it makes no sense to break spears, whether it is right or not. Accept as a fact.
SED is both a document repository (Document & Records Management System) and an organization management system (Workflow & BPM, Collaboration, etc.) Moreover, there is a practice of using systems mainly modeled on Soviet institutions with their meaningless and merciless bureaucracy. More than half of the organizations in the IDC study call EDS a means of automating business processes. (ERP is in second place, and the BPM system itself is at the very end.)
So, you need to document activities. Otherwise, you can easily lose your license, certification, professional contract, lose, God forbid, personal data or something else important. But it is not at all necessary to equate documentation and processes.
Think about the processes separately. Do not fall into the trap of obsolete traditions. After all, the main skill of an “effective manager” is to shift responsibility onto others, most often to subordinates. The concept of "team" in the ideology of the SED is completely absent, there are only "performers", the wheels and cogs of a corporate or state machine.
Now, attention, question: Can you name at least one really cool product that would be developed in such a bureaucratic environment?
And question number 2: Is the development of software something fundamentally different from other types of collective activity? So why not apply agile outside of the development team, in all business processes of the organization? Alas, here we are faced with an almost irresistible wall of misunderstanding ...
Management is taught in business schools. Everything, point. IT specialists cannot know anything about process management, their business is to program. If the MBA course does not speak about agile-methodologies (and this is so!), Then there is nothing to make a garden. Very similar to the story of the Turkish astronomer from the Little Prince.
In our case, I'm afraid, even a jacket and tie will not help. Customers insist on implementing using the latest IT systems of obsolete management methods and are not ready to accept new methodologies from the hands of IT.
The ineffectiveness of traditional management in relation to the development of programs was discovered long ago. The book “The Mythical Man-Month” by Frederick Brooks about the difficulties of managing a project to create IBM OS / 360 and unsuccessful attempts to speed it up by attracting more programmers was published in 1975. Since then, little has changed - managers still mistakenly believe that problems can be solved by increasing the number of people or “replacing an artist,” as they like to say.
Project execution time is not inversely proportional to the number of programmers for at least two reasons.
If there are N programmers, then the number of programmer pairs is N (N-1) / 2, that is, as the number of programmers increases, the time spent on interaction increases quadratically. Therefore, starting with some N, the growth of the number of programmers slows down the implementation of the project.
If deadlines are broken, hiring new programmers slows down the implementation of the project for another reason: beginners take time to learn. The book formulated the Brooks Act:
If the project does not fit the deadlines, then adding labor will delay it even more.
With a very large number of programmers, a project can never be completed at all: due to the general confusion, attempts to correct existing errors in software generate new errors, so the system does not improve (chapter 2). (I quote on Wikipedia)
Replace programmers with engineers, technologists, B2B sales managers, business development specialists, translators, lawyers, designers — you get the same picture. Wherever the final result depends on the interaction of people in the team and the relationship with the customer, the Brooks law works. In other words, wherever there is an intellectual component in the work, mechanical scaling of resources does not help. And terrible orders do not help to do everything on time, or else we will dismiss everyone - unique specialists are not cotton pickers to you.
This is the essence of the conflict: the current management practices have grown out of the tasks of production management and the armed forces, where mechanical scaling works, and the result depends little on the person of the contractor. You do not care what kind of worker is at the machine, right? And with those categories of employees who are classified as knowledge workers, this focus does not work. You cannot assign half a book to one translator, and half to another. Lawyers cannot go to hearings of one case in turn, it takes time to get involved in the process. Therefore, we need management methods that take into account the creative and collective nature of the work - agile in all its manifestations - Scrum, Kanban, LEAN, etc.
To consider the EDS and the entire management paradigm “of workflow” as an absolute evil would be a great exaggeration. Of course, there are areas where it works quite well. But there are those where the use of bureaucratic procedures is strictly contraindicated. (As most readers know from personal experience, these include software development.)
But what is the difference?
The applicability of the methodology is determined by the nature of the control object, the processes we are going to automate. The Cynefin framework (pronounced 'cinema', this word is Welsh, coined by prof. Dave Snowden), defines four domains: simple, complicated, complex, chaotic. Each domain has its own laws and rules.
It is easy to assume that EDS will work quite well in the Simple domain, automating various routine procedures. The main feature of this domain is clear and understandable causal relationships. That is, you can write regulations, set standards - and more! People here are interchangeable, you can put any minimally trained operator and the quality of the process will not change.
The next domain, Complicated (complicated), is characterized by mechanical complexity - when it is not clear at first glance, but if you look at it, everything is logical and predictable, small variations are also possible, to which the system adapts. From the practice of document management, you can cite as an example the process of managing contracts - theoretically, it is possible to describe the approval and approval process in great detail, only everyone understands that in real life any decisions can be made contrary to the regulations if it is in the interests of the business.
In this domain, the SED is still working fine until they encounter any exceptional situation. If there are too many exceptional situations, then the organization switches to the “manual control” mode, when the manager tries to steer everything personally, and we de facto find ourselves in the Complex domain, in the realm of complex systems, where the best practices do not work, where past experience if it repeats, then each time in some altered form. Remember the saying “you cannot enter the same river twice”? Just such a case.
Most of the organizational systems are exactly that. Everything related to strategic management, business development, innovation, product launches, marketing, etc. etc. - in general, all processes that are poorly amenable to formalization, where potentially there is a conflict of interests of different participants, can be considered complex systems. Therefore, the situation of “swan, cancer and pike”, when departments or departments cannot resolve an issue requiring joint efforts, is quite ordinary.
In the Complex domain, a management approach based on the SED becomes categorically harmful. "In response to your incoming - our outgoing" - and so at least a hundred times in a row, only the case does not move. Because within the bureaucratic paradigm, the most important thing is to push responsibility onto someone else, and not come to a common understanding and find the best solution.
The Agile methodology is perhaps the most valuable business gift from IT. Only business is not ready to take it out of our hands, so we will have to implement agile guerrilla methods, adding new features to the products, aimed at supporting new work methodologies. These innovations penetrate into the company under the banner of flexibility and adaptability of business processes, to which management looks favorably - it is necessary to comply with the spirit of the times!
In fact, this is a true disruptive innovation, a time bomb laid down under the previous methods of work organization. Because new ECM and BPM systems are aimed at supporting horizontal interaction in teams, without denying the usual “vertical of power”, to quickly create applications for specific business tasks with a focus on the final result and measurable KPIs, they have built-in messaging and other information. almost like a social network, only (hush!) don't tell anyone!
So, you can paraphrase the Agile-manifest of software developers a little, and you’ll get the following Agile-manifest EDS:
By the way, the terms Agile ECM and Agile BPM themselves are already quite widely used, many companies have released their products, positioning them in the Agile class. So, the ice is broken!
Agile in the software industry has become the norm. For today there is no other methodology that allows you to manage projects in conditions of high uncertainty and variability of requirements. ”
')
Article journalist-analyst Stanislav Makarov.
And here is the document flow?
Imagine if you had to manage a project to develop a software product using traditional workflow - incoming-outgoing, office memos, meeting minutes, and other bureaucracies. What are the chances to meet the deadline and budget? That's right, zero. Not even the toughest control of performance will help. And not at all because your programmers, slackers and slobs, who cannot even come to work on time, dress strangely and do not understand what.
Problems in the methodology itself: it is assumed that everything can be foreseen in advance and give the performers clear instructions on what to do. In an ideal system, this could work, but, alas, most often we have a lot of deviations from the plan that no even the wisest boss could foresee.
This is where the system begins to fail, since each change must be coordinated along a hierarchical chain. All participants in the process prefer to merge responsibility so as not to be the last thing in the end - the initiative is punishable! A bunch of small questions are being dumped on the boss, which he needs to resolve personally. The decision-making cycle is stretched out, the terms are floated - and there are no guilty ones, unless they specifically appoint someone later. The command-administrative system does not have sufficient flexibility to respond in time to changes in the situation, whether it is difficulties encountered in the implementation of the project, or new customer requirements.
In short, the boss is always right. And if not right, then see point one. Everyone is sitting and waiting for guidance, horizontal connections do not work.
Document management is not at all such a harmless thing as it seems. In fact, this is the embodiment of the management concept, which is based on a strict hierarchy, prevention of initiative and lack of teamwork.
In general, it all comes down to the classical principle of "divide and conquer."
Document Trap: Dual Purpose
It is necessary for the organization to grow a little, as she begins to dream of introducing a document flow, so that everything is “like the big ones”. Nobody argues, the order in the documents is needed, and then, it's not even an hour, any monitoring authorities will descend or an important document from the client will get lost in the stream. All this is correct, just do not start copying the state bureaucracy at its worst.
If you take it on a large scale, EDS covers two functional areas:
- Documenting the activities of the organization;
- Business Process Management.
It happened so historically and now it makes no sense to break spears, whether it is right or not. Accept as a fact.
SED is both a document repository (Document & Records Management System) and an organization management system (Workflow & BPM, Collaboration, etc.) Moreover, there is a practice of using systems mainly modeled on Soviet institutions with their meaningless and merciless bureaucracy. More than half of the organizations in the IDC study call EDS a means of automating business processes. (ERP is in second place, and the BPM system itself is at the very end.)
So, you need to document activities. Otherwise, you can easily lose your license, certification, professional contract, lose, God forbid, personal data or something else important. But it is not at all necessary to equate documentation and processes.
Think about the processes separately. Do not fall into the trap of obsolete traditions. After all, the main skill of an “effective manager” is to shift responsibility onto others, most often to subordinates. The concept of "team" in the ideology of the SED is completely absent, there are only "performers", the wheels and cogs of a corporate or state machine.
Now, attention, question: Can you name at least one really cool product that would be developed in such a bureaucratic environment?
And question number 2: Is the development of software something fundamentally different from other types of collective activity? So why not apply agile outside of the development team, in all business processes of the organization? Alas, here we are faced with an almost irresistible wall of misunderstanding ...
The story of the Turkish astronomer
Management is taught in business schools. Everything, point. IT specialists cannot know anything about process management, their business is to program. If the MBA course does not speak about agile-methodologies (and this is so!), Then there is nothing to make a garden. Very similar to the story of the Turkish astronomer from the Little Prince.
In our case, I'm afraid, even a jacket and tie will not help. Customers insist on implementing using the latest IT systems of obsolete management methods and are not ready to accept new methodologies from the hands of IT.
The ineffectiveness of traditional management in relation to the development of programs was discovered long ago. The book “The Mythical Man-Month” by Frederick Brooks about the difficulties of managing a project to create IBM OS / 360 and unsuccessful attempts to speed it up by attracting more programmers was published in 1975. Since then, little has changed - managers still mistakenly believe that problems can be solved by increasing the number of people or “replacing an artist,” as they like to say.
Mythical man-month
Project execution time is not inversely proportional to the number of programmers for at least two reasons.
- In programming, unlike, for example, cotton picking, work cannot be arbitrarily divided into several independent parts. Parts of the project are dependent on each other, and some tasks can only be started after others have been completed;
- Programmers need to spend some time interacting with each other.
If there are N programmers, then the number of programmer pairs is N (N-1) / 2, that is, as the number of programmers increases, the time spent on interaction increases quadratically. Therefore, starting with some N, the growth of the number of programmers slows down the implementation of the project.
If deadlines are broken, hiring new programmers slows down the implementation of the project for another reason: beginners take time to learn. The book formulated the Brooks Act:
If the project does not fit the deadlines, then adding labor will delay it even more.
With a very large number of programmers, a project can never be completed at all: due to the general confusion, attempts to correct existing errors in software generate new errors, so the system does not improve (chapter 2). (I quote on Wikipedia)
Replace programmers with engineers, technologists, B2B sales managers, business development specialists, translators, lawyers, designers — you get the same picture. Wherever the final result depends on the interaction of people in the team and the relationship with the customer, the Brooks law works. In other words, wherever there is an intellectual component in the work, mechanical scaling of resources does not help. And terrible orders do not help to do everything on time, or else we will dismiss everyone - unique specialists are not cotton pickers to you.
This is the essence of the conflict: the current management practices have grown out of the tasks of production management and the armed forces, where mechanical scaling works, and the result depends little on the person of the contractor. You do not care what kind of worker is at the machine, right? And with those categories of employees who are classified as knowledge workers, this focus does not work. You cannot assign half a book to one translator, and half to another. Lawyers cannot go to hearings of one case in turn, it takes time to get involved in the process. Therefore, we need management methods that take into account the creative and collective nature of the work - agile in all its manifestations - Scrum, Kanban, LEAN, etc.
Why best practices are not always better
To consider the EDS and the entire management paradigm “of workflow” as an absolute evil would be a great exaggeration. Of course, there are areas where it works quite well. But there are those where the use of bureaucratic procedures is strictly contraindicated. (As most readers know from personal experience, these include software development.)
But what is the difference?
The applicability of the methodology is determined by the nature of the control object, the processes we are going to automate. The Cynefin framework (pronounced 'cinema', this word is Welsh, coined by prof. Dave Snowden), defines four domains: simple, complicated, complex, chaotic. Each domain has its own laws and rules.
It is easy to assume that EDS will work quite well in the Simple domain, automating various routine procedures. The main feature of this domain is clear and understandable causal relationships. That is, you can write regulations, set standards - and more! People here are interchangeable, you can put any minimally trained operator and the quality of the process will not change.
The next domain, Complicated (complicated), is characterized by mechanical complexity - when it is not clear at first glance, but if you look at it, everything is logical and predictable, small variations are also possible, to which the system adapts. From the practice of document management, you can cite as an example the process of managing contracts - theoretically, it is possible to describe the approval and approval process in great detail, only everyone understands that in real life any decisions can be made contrary to the regulations if it is in the interests of the business.
In this domain, the SED is still working fine until they encounter any exceptional situation. If there are too many exceptional situations, then the organization switches to the “manual control” mode, when the manager tries to steer everything personally, and we de facto find ourselves in the Complex domain, in the realm of complex systems, where the best practices do not work, where past experience if it repeats, then each time in some altered form. Remember the saying “you cannot enter the same river twice”? Just such a case.
Most of the organizational systems are exactly that. Everything related to strategic management, business development, innovation, product launches, marketing, etc. etc. - in general, all processes that are poorly amenable to formalization, where potentially there is a conflict of interests of different participants, can be considered complex systems. Therefore, the situation of “swan, cancer and pike”, when departments or departments cannot resolve an issue requiring joint efforts, is quite ordinary.
In the Complex domain, a management approach based on the SED becomes categorically harmful. "In response to your incoming - our outgoing" - and so at least a hundred times in a row, only the case does not move. Because within the bureaucratic paradigm, the most important thing is to push responsibility onto someone else, and not come to a common understanding and find the best solution.
Agile ECM and Agile BPM
The Agile methodology is perhaps the most valuable business gift from IT. Only business is not ready to take it out of our hands, so we will have to implement agile guerrilla methods, adding new features to the products, aimed at supporting new work methodologies. These innovations penetrate into the company under the banner of flexibility and adaptability of business processes, to which management looks favorably - it is necessary to comply with the spirit of the times!
In fact, this is a true disruptive innovation, a time bomb laid down under the previous methods of work organization. Because new ECM and BPM systems are aimed at supporting horizontal interaction in teams, without denying the usual “vertical of power”, to quickly create applications for specific business tasks with a focus on the final result and measurable KPIs, they have built-in messaging and other information. almost like a social network, only (hush!) don't tell anyone!
So, you can paraphrase the Agile-manifest of software developers a little, and you’ll get the following Agile-manifest EDS:
By the way, the terms Agile ECM and Agile BPM themselves are already quite widely used, many companies have released their products, positioning them in the Agile class. So, the ice is broken!
Source: https://habr.com/ru/post/244431/
All Articles