December 3, 2014 at 15:39Agile in workflow
“Agitating developers for agile is like saying that the Earth is round. Yes, there are still 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 true goal is not to create a really working system, but to properly spend budget funds .
Agile in the software industry has become the norm. For there is no other methodology today that allows managing projects in conditions of high uncertainty and variability of requirements. ”
An article by journalist-analyst Stanislav Makarov.
Imagine if you had to manage a project to develop a software product using traditional workflows - inbound and outbound, memos, meeting minutes, and other bureaucracy. What are the chances to meet the deadline and budget? That's right, zero. Even the toughest control of performance will not help. And it’s not at all because your programmers are loafers and slovens who cannot even come to work on time, dress weirdly and do something incomprehensibly.
The problems are in the methodology itself: it is supposed 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, more often than not, we have many deviations from the plan, which no, even the wisest boss could have foreseen.
This is where the system begins to fail, since each change needs to be coordinated along a hierarchical chain. All participants in the process prefer to merge responsibility so as not to be ultimately extreme - the initiative is punishable! A bunch of small questions fall on the boss, which he needs to resolve personally. The decision-making cycle is stretched, the deadlines are floating, and there are no guilty parties, unless they specifically appoint someone later. The command and administrative system does not have sufficient flexibility to manage to respond 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 it’s not right, then see point one. Everyone is sitting and waiting for guidance, horizontal communications do not work.
Workflow is not at all as harmless a thing as it seems. In fact, this is the embodiment of a managerial concept, which is based on a strict hierarchy, the prevention of initiative and the lack of teamwork.
In general, it comes down to the classic principle of “divide and conquer.”
As the organization grows a little, it begins to dream of introducing workflow so that everything is “like big ones”. Nobody argues, the order in the documents is needed, otherwise, not even an hour, all sorts of controlling authorities will appear or an important document from the client will be lost in the stream. All this is correct, just do not start copying the state bureaucracy in its worst manifestations.
If we take it large, the EDMS covers two functional areas:
This happened historically and now there is no point in breaking the spears, is it right or not. Take it as a fact.
EDMS 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 based on Soviet institutions with their senseless and merciless bureaucracy. More than half of the organizations in the IDC study call EDMS a means of automating business processes. (In second place is ERP, and the actual BPM systems are at the very end.)
So, you need to document the activity. Otherwise, you can easily lose your license, certification, save up a contract, lose, God forbid, personal data or something else important. But it’s not at all necessary to equate documentation and processes.
Think of processes separately. Do not fall into the trap of obsolete traditions. After all, the main skill of an “effective manager” is to blame responsibility on others, most often on subordinates. The concept of "team" in the ideology of the EDMS is completely absent, there are only "performers", 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 software development fundamentally different from other types of collective activity? So why not apply agile outside the development team to all the organization’s business processes? Alas, here we are faced with an almost insurmountable wall of misunderstanding ...
Management is taught in business schools. That's it, period. IT people can not know anything about process management, their job is to program. If the MBA course does not talk about agile methodologies (and this is so!), Then there is nothing to fence in the garden. Very similar to the story of the Turkish astronomer from the Little Prince.
In our case, I'm afraid that even a jacket and tie will not help. Customers insist on implementing obsolete management methods using the latest IT systems and are not ready to accept new methodologies from the hands of IT.
The inefficiency of traditional management in relation to program development has been discovered long ago. The book “Mythical Man-Month” by Frederick Brooks about the difficulties of managing a project to create an IBM OS / 360 and unsuccessful attempts to accelerate it 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 by “replacing a performer,” as they like to say.
Project lead time is not inversely proportional to the number of programmers, for at least two reasons.
If there are N programmers, then the number of pairs of programmers is N (N-1) / 2, that is, as the number of programmers increases, the time spent on interaction grows quadratically. Therefore, starting from some N, an increase in the number of programmers slows down the execution of the project.
If the deadlines are missed, hiring new programmers slows down the project for another reason: newcomers need time to learn. In the book, Brooks Law is formulated:
If the project does not meet the deadlines, then the addition of labor will delay it even more.
With a very large number of programmers, the project may never be completed at all: due to the general confusion, attempts to fix existing errors in the software give rise to new errors, so the system does not improve (chapter 2). (quoted on Wikipedia)
Replace programmers with engineers, technologists, B2B sales managers, business development specialists, translators, lawyers, designers - you will get the same picture. Wherever the end result depends on the interaction of people in the team and the built relationships with the customer, Brooks law works. In other words, wherever there is an intellectual component in the work, mechanical scaling of resources does not help. And menacing orders do not help to do everything on time, otherwise we’ll fire everyone - unique specialists are not cotton pickers for you.
This is the essence of the conflict: current management practices have grown out of the tasks of managing production and the armed forces, where mechanical scaling works, and the result depends little on the personality of the performer. You don’t care what kind of worker is at the machine, right? And with those categories of employees who are referred to as 'knowledge workers' such a trick does not work. You cannot assign half a book to be translated by one translator and half by another. Lawyers cannot attend hearings of one case in turn, it takes time to get involved in the process. Therefore, management methods that take into account the creative and collective nature of the work are needed - agile in all its manifestations - Scrum, Kanban, LEAN, etc.
To consider the EDMS and the entire “workflow” management paradigm as an absolute evil would be a strong exaggeration. Of course, there are areas where this works quite successfully. But there are those where the use of bureaucratic procedures is strictly contraindicated. (As most readers know from their own experience, software development is one of those.)
But what is the difference?
The applicability of the methodology is determined by the nature of the control object, the processes that we are going to automate. The Cynefin framework (pronounced 'kinevin' is a Welsh word invented by Prof. Dave Snowden) defines four domains: simple, complicated, complex, chaotic. Each domain has its own laws and regulations.
It is easy to assume that the EDMS will work quite well in the Simple domain, automating various routine procedures. The main property of this domain is clear and understandable causal relationships. That is, you can write the regulations, set the 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 at first glance it is not clear, but if you look, then everything is logical and predictable, small variations are also possible, to which the system adapts. From the practice of document management, we can cite the process of managing contracts as an example - theoretically, you can very carefully describe the approval and approval process, only everyone understands that in real life any decisions can be made contrary to the regulations, if it is in the interests of business.
In this domain, EDMSs still work fine until they encounter some kind of exceptional situation. If there are too many exceptional situations, then the organization goes into the “manual control” mode when the leader tries to steer everything personally, and we, de facto, find ourselves in the Complex domain, in the realm of complex systems, where best practices do not work, where past experience if it is repeated, then each time in some kind of altered form. Remember the saying “you cannot enter the same river twice”? Just such a case.
Most organizational systems are just that. Everything related to strategic management, business development, innovation, product launch, marketing, etc. etc. - in general, all processes that are poorly formalized, where there is potentially 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 solve the issue requiring joint efforts, is quite common.
In the Complex domain, an EDMS-based management approach 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 framework of the bureaucratic paradigm, the most important thing is to shove off responsibility to someone else, and not come to a common understanding and find the optimal solution.
The Agile methodology is perhaps the most valuable business gift from IT. Only business is not ready to take this from our hands, so we will have to implement agile in partisan methods, adding new features to our products that are focused on supporting new work methodologies. These innovations penetrate companies under the banner of flexibility and adaptability of business processes, which management looks favorably at - it must be in line with the spirit of the times!
In fact, this is a real disruptive innovation, a time bomb, laid down under the previous methods of organizing work. Because the new ECM and BPM systems are aimed at supporting horizontal interaction in teams, without denying the usual "power vertical", at quickly creating applications for specific business tasks with a focus on the end result and measurable KPIs, have built-in means of messaging and other information - almost like a social network, just (shh!) don't tell anyone!
In total, you can rephrase the Agile manifest of software developers a little, and you get the following Agile manifest of EDMS:
By the way, the terms Agile ECM and Agile BPM are already widely used, many companies released their products, positioning them in the Agile class. So the ice has broken!
Agile in the software industry has become the norm. For there is no other methodology today that allows managing projects in conditions of high uncertainty and variability of requirements. ”
An article by journalist-analyst Stanislav Makarov.
And here is the workflow?
Imagine if you had to manage a project to develop a software product using traditional workflows - inbound and outbound, memos, meeting minutes, and other bureaucracy. What are the chances to meet the deadline and budget? That's right, zero. Even the toughest control of performance will not help. And it’s not at all because your programmers are loafers and slovens who cannot even come to work on time, dress weirdly and do something incomprehensibly.
The problems are in the methodology itself: it is supposed 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, more often than not, we have many deviations from the plan, which no, even the wisest boss could have foreseen.
This is where the system begins to fail, since each change needs to be coordinated along a hierarchical chain. All participants in the process prefer to merge responsibility so as not to be ultimately extreme - the initiative is punishable! A bunch of small questions fall on the boss, which he needs to resolve personally. The decision-making cycle is stretched, the deadlines are floating, and there are no guilty parties, unless they specifically appoint someone later. The command and administrative system does not have sufficient flexibility to manage to respond 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 it’s not right, then see point one. Everyone is sitting and waiting for guidance, horizontal communications do not work.
Workflow is not at all as harmless a thing as it seems. In fact, this is the embodiment of a managerial concept, which is based on a strict hierarchy, the prevention of initiative and the lack of teamwork.
In general, it comes down to the classic principle of “divide and conquer.”
Workflow Trap: Dual Purpose SED
As the organization grows a little, it begins to dream of introducing workflow so that everything is “like big ones”. Nobody argues, the order in the documents is needed, otherwise, not even an hour, all sorts of controlling authorities will appear or an important document from the client will be lost in the stream. All this is correct, just do not start copying the state bureaucracy in its worst manifestations.
If we take it large, the EDMS covers two functional areas:
- Documentation of the organization;
- Business process management.
This happened historically and now there is no point in breaking the spears, is it right or not. Take it as a fact.
EDMS 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 based on Soviet institutions with their senseless and merciless bureaucracy. More than half of the organizations in the IDC study call EDMS a means of automating business processes. (In second place is ERP, and the actual BPM systems are at the very end.)
So, you need to document the activity. Otherwise, you can easily lose your license, certification, save up a contract, lose, God forbid, personal data or something else important. But it’s not at all necessary to equate documentation and processes.
Think of processes separately. Do not fall into the trap of obsolete traditions. After all, the main skill of an “effective manager” is to blame responsibility on others, most often on subordinates. The concept of "team" in the ideology of the EDMS is completely absent, there are only "performers", 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 software development fundamentally different from other types of collective activity? So why not apply agile outside the development team to all the organization’s business processes? Alas, here we are faced with an almost insurmountable wall of misunderstanding ...
The story of the Turkish astronomer
Management is taught in business schools. That's it, period. IT people can not know anything about process management, their job is to program. If the MBA course does not talk about agile methodologies (and this is so!), Then there is nothing to fence in the garden. Very similar to the story of the Turkish astronomer from the Little Prince.
In our case, I'm afraid that even a jacket and tie will not help. Customers insist on implementing obsolete management methods using the latest IT systems and are not ready to accept new methodologies from the hands of IT.
The inefficiency of traditional management in relation to program development has been discovered long ago. The book “Mythical Man-Month” by Frederick Brooks about the difficulties of managing a project to create an IBM OS / 360 and unsuccessful attempts to accelerate it 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 by “replacing a performer,” as they like to say.
Mythical man-month
Project lead time is not inversely proportional to the number of programmers, for at least two reasons.
- In programming, unlike, for example, picking cotton, work cannot be arbitrarily divided into several independent parts. Parts of the project depend on each other, and some tasks can only be started after others are finished;
- Programmers must spend some time interacting with each other.
If there are N programmers, then the number of pairs of programmers is N (N-1) / 2, that is, as the number of programmers increases, the time spent on interaction grows quadratically. Therefore, starting from some N, an increase in the number of programmers slows down the execution of the project.
If the deadlines are missed, hiring new programmers slows down the project for another reason: newcomers need time to learn. In the book, Brooks Law is formulated:
If the project does not meet the deadlines, then the addition of labor will delay it even more.
With a very large number of programmers, the project may never be completed at all: due to the general confusion, attempts to fix existing errors in the software give rise to new errors, so the system does not improve (chapter 2). (quoted on Wikipedia)
Replace programmers with engineers, technologists, B2B sales managers, business development specialists, translators, lawyers, designers - you will get the same picture. Wherever the end result depends on the interaction of people in the team and the built relationships with the customer, Brooks law works. In other words, wherever there is an intellectual component in the work, mechanical scaling of resources does not help. And menacing orders do not help to do everything on time, otherwise we’ll fire everyone - unique specialists are not cotton pickers for you.
This is the essence of the conflict: current management practices have grown out of the tasks of managing production and the armed forces, where mechanical scaling works, and the result depends little on the personality of the performer. You don’t care what kind of worker is at the machine, right? And with those categories of employees who are referred to as 'knowledge workers' such a trick does not work. You cannot assign half a book to be translated by one translator and half by another. Lawyers cannot attend hearings of one case in turn, it takes time to get involved in the process. Therefore, management methods that take into account the creative and collective nature of the work are needed - agile in all its manifestations - Scrum, Kanban, LEAN, etc.
Why best practices are not always better
To consider the EDMS and the entire “workflow” management paradigm as an absolute evil would be a strong exaggeration. Of course, there are areas where this works quite successfully. But there are those where the use of bureaucratic procedures is strictly contraindicated. (As most readers know from their own experience, software development is one of those.)
But what is the difference?
The applicability of the methodology is determined by the nature of the control object, the processes that we are going to automate. The Cynefin framework (pronounced 'kinevin' is a Welsh word invented by Prof. Dave Snowden) defines four domains: simple, complicated, complex, chaotic. Each domain has its own laws and regulations.
It is easy to assume that the EDMS will work quite well in the Simple domain, automating various routine procedures. The main property of this domain is clear and understandable causal relationships. That is, you can write the regulations, set the 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 at first glance it is not clear, but if you look, then everything is logical and predictable, small variations are also possible, to which the system adapts. From the practice of document management, we can cite the process of managing contracts as an example - theoretically, you can very carefully describe the approval and approval process, only everyone understands that in real life any decisions can be made contrary to the regulations, if it is in the interests of business.
In this domain, EDMSs still work fine until they encounter some kind of exceptional situation. If there are too many exceptional situations, then the organization goes into the “manual control” mode when the leader tries to steer everything personally, and we, de facto, find ourselves in the Complex domain, in the realm of complex systems, where best practices do not work, where past experience if it is repeated, then each time in some kind of altered form. Remember the saying “you cannot enter the same river twice”? Just such a case.
Most organizational systems are just that. Everything related to strategic management, business development, innovation, product launch, marketing, etc. etc. - in general, all processes that are poorly formalized, where there is potentially 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 solve the issue requiring joint efforts, is quite common.
In the Complex domain, an EDMS-based management approach 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 framework of the bureaucratic paradigm, the most important thing is to shove off responsibility to someone else, and not come to a common understanding and find the optimal 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 this from our hands, so we will have to implement agile in partisan methods, adding new features to our products that are focused on supporting new work methodologies. These innovations penetrate companies under the banner of flexibility and adaptability of business processes, which management looks favorably at - it must be in line with the spirit of the times!
In fact, this is a real disruptive innovation, a time bomb, laid down under the previous methods of organizing work. Because the new ECM and BPM systems are aimed at supporting horizontal interaction in teams, without denying the usual "power vertical", at quickly creating applications for specific business tasks with a focus on the end result and measurable KPIs, have built-in means of messaging and other information - almost like a social network, just (shh!) don't tell anyone!
In total, you can rephrase the Agile manifest of software developers a little, and you get the following Agile manifest of EDMS:
By the way, the terms Agile ECM and Agile BPM are already widely used, many companies released their products, positioning them in the Agile class. So the ice has broken!