1. Introduction
This is what I wrote in 2005 when I was asked to join a "Quality Improvement Committee" explaining why I decline the honor. Some minor changes were made remove to direct connections to "where" and "who". I still believe in the main message. Some concluding notes at the end.Almost any fast growing and successful high tech company sooner or later steps on a sure path to software quality crisis. The quality crisis will touch any platform and any site.The question is what could the company’s top management do about this crisis?
A tempting and seemingly natural approach would be to launch a Software Quality Improvement Campaign, to form a number of Committees—testing, software engineering, defect tracking, requirement management, process engineering—and to let them lay out a set of company- wide standard solutions for the software quality problems. Then the most trivial stage starts: everyone will be obligated to apply this set of solutions and to be happy. “What if someone couldn’t apply them, or doesn’t want to?” No problem! Top management will step down and will help to adjust that person’s attitude. Sounds promising and very familiar…
In my personal humble opinion, reflecting almost 30 years of professional software development experience, it will not work nor bring the desired results—certainly not on a large scale. It could, however, easily break the company spirit and to run out the best people.
This short memo highlights some root-cause reasons that condemn “improvement by committee” to failure. In addition, I will suggest some alternative approaches.
2. Why “Improvement by Committee” Doesn’t Work?
Improvement by committee is thwarted by:
- Company culture
- Company structure
- Nature of the business and market
- Nature of the software development process.
2.1 Company Culture
Company culture is the most powerful factor shaping its day-to-day style of work. No one can change it overnight—or even in the course of a whole year—unless at least 30% of the current employees (including the top management!) are fired. One should not illusion himself. This is not to say that company culture never changes—it inevitably does: slowly. I will briefly discuss one aspect of company culture: who makes technical decisions?
At its initial growth stage the company usually has the so-called Variable Culture, where developers do what they think they should do or just what they want to do. This culture is a continuation of its good old “start-up” days, some time ago. Variable Culture is typified by high levels of creativity and dedication, creating an exciting working atmosphere. It is actually the only option at any start-up’s disposal. The problem with the Variable Culture is that it can not guarantee sustainable delivery at large scales. When the number of customers grows, and the work starts to be more boring and repetitious, Variable Culture companies inevitably run into quality crises.
Managers typically respond to Variable Culture quality crises by ‘tightening the screws.’ This in turn, leads to the so-called Routine Culture, where developers do only what their managers tell them to do. This type of culture is typical for established companies where software development is the least interesting kind of activity. At a certain degree the Routine Culture is also very powerful and indeed could guarantee a sustainable mass production and delivery. The biggest problem with it is that it’s boring and runs out the best talents from development. It also is very inflexible and when the market climate changes it stops to deliver and the whole company fails back into the Variable Culture anarchy in its worst form.
The very idea of quality improvement campaigns and committees comes from the Routine Culture. The common belief is that this approach could indeed improve the quality … for repetitive mass production of the same goods, but even this turns to be just a yet another illusion. There is a lot of evidence that this culture is completely incapable of developing new revolutionary products.
The major problem with the two previous kinds of the culture (Variable and Routine) is a lack of competence. In the Variable Culture managers usually behave like techies or simply give up on hope of controlling the process. In the Routine Culture developers turn to be narrowly focused bureaucrats, while defeating the system by means of ‘underground’ activities. Some Don Quixotes are trying to fight, but they are burned out very quickly. Routine Culture managers do not have better control. They cannot provide any reasonable guidance about how to work, while developers cannot decide judiciously what to work on. Everybody lacks the necessary information and competence, and nobody is happy. Steadily growing frustration, endless firefighting, organizational cynicism, and popularity of the Dilbert cartoons are very typical symptoms of these cultures.
Any kind of committee could not help here just because putting any number of people in a room directing them “to do something” could not solve the problem. The problem is too serious and its roots are too deep to be resolved in this way.
Unfortunately the vast majority of high-tech companies that struggle for survival are locked in between the Variable and Routine Cultures. Only few of them are lucky or sophisticated enough to reach the third level—Steering Culture—where developers do whatever they find appropriate to do, while the management supports the process through Motivation, Organization and Information (MOI).
The Steering Culture tries to overcome the Variable and Routine Culture limitations by putting competent managers and competent developers together, while establishing a proper framework for information exchange, analysis, measurement, decision making, and actions. In this culture managers are managers not because they are from a higher caste, but because they do know how to perform this extremely tough job. Developers are developing not because they are the second class of people or are just not clever enough to be managers, but because they do know how to perform this job in the best way and do like it. In this culture people are NOT appraised for working long hours, but are assisted in finding a way to deliver a quality work during a normal 42 hours week.
This is not the case at too many companies today. Just count the number of single sitters in the new building, count the number of people working after 18:00 and on Fridays, listen and look carefully at what’s happening at the PER, staff and management forum meetings. Since anything related to culture is sensitive, it is very tempting to live in self-denial. Even if advantages of the Steering Culture are recognized it’s much easier to say than to do and then the “not here, not now” type of excuse comes into the play. The problem is that any kind of campaigns or committees offers no more than a short-lasting panacea, which could probably supply a temporal relief, but makes the real problem even worse.
Company culture is the most powerful factor shaping its day-to-day style of work. No one can change it overnight—or even in the course of a whole year—unless at least 30% of the current employees (including the top management!) are fired. One should not illusion himself. This is not to say that company culture never changes—it inevitably does: slowly. I will briefly discuss one aspect of company culture: who makes technical decisions?
At its initial growth stage the company usually has the so-called Variable Culture, where developers do what they think they should do or just what they want to do. This culture is a continuation of its good old “start-up” days, some time ago. Variable Culture is typified by high levels of creativity and dedication, creating an exciting working atmosphere. It is actually the only option at any start-up’s disposal. The problem with the Variable Culture is that it can not guarantee sustainable delivery at large scales. When the number of customers grows, and the work starts to be more boring and repetitious, Variable Culture companies inevitably run into quality crises.
Managers typically respond to Variable Culture quality crises by ‘tightening the screws.’ This in turn, leads to the so-called Routine Culture, where developers do only what their managers tell them to do. This type of culture is typical for established companies where software development is the least interesting kind of activity. At a certain degree the Routine Culture is also very powerful and indeed could guarantee a sustainable mass production and delivery. The biggest problem with it is that it’s boring and runs out the best talents from development. It also is very inflexible and when the market climate changes it stops to deliver and the whole company fails back into the Variable Culture anarchy in its worst form.
The very idea of quality improvement campaigns and committees comes from the Routine Culture. The common belief is that this approach could indeed improve the quality … for repetitive mass production of the same goods, but even this turns to be just a yet another illusion. There is a lot of evidence that this culture is completely incapable of developing new revolutionary products.
The major problem with the two previous kinds of the culture (Variable and Routine) is a lack of competence. In the Variable Culture managers usually behave like techies or simply give up on hope of controlling the process. In the Routine Culture developers turn to be narrowly focused bureaucrats, while defeating the system by means of ‘underground’ activities. Some Don Quixotes are trying to fight, but they are burned out very quickly. Routine Culture managers do not have better control. They cannot provide any reasonable guidance about how to work, while developers cannot decide judiciously what to work on. Everybody lacks the necessary information and competence, and nobody is happy. Steadily growing frustration, endless firefighting, organizational cynicism, and popularity of the Dilbert cartoons are very typical symptoms of these cultures.
Any kind of committee could not help here just because putting any number of people in a room directing them “to do something” could not solve the problem. The problem is too serious and its roots are too deep to be resolved in this way.
Unfortunately the vast majority of high-tech companies that struggle for survival are locked in between the Variable and Routine Cultures. Only few of them are lucky or sophisticated enough to reach the third level—Steering Culture—where developers do whatever they find appropriate to do, while the management supports the process through Motivation, Organization and Information (MOI).
The Steering Culture tries to overcome the Variable and Routine Culture limitations by putting competent managers and competent developers together, while establishing a proper framework for information exchange, analysis, measurement, decision making, and actions. In this culture managers are managers not because they are from a higher caste, but because they do know how to perform this extremely tough job. Developers are developing not because they are the second class of people or are just not clever enough to be managers, but because they do know how to perform this job in the best way and do like it. In this culture people are NOT appraised for working long hours, but are assisted in finding a way to deliver a quality work during a normal 42 hours week.
This is not the case at too many companies today. Just count the number of single sitters in the new building, count the number of people working after 18:00 and on Fridays, listen and look carefully at what’s happening at the PER, staff and management forum meetings. Since anything related to culture is sensitive, it is very tempting to live in self-denial. Even if advantages of the Steering Culture are recognized it’s much easier to say than to do and then the “not here, not now” type of excuse comes into the play. The problem is that any kind of campaigns or committees offers no more than a short-lasting panacea, which could probably supply a temporal relief, but makes the real problem even worse.
2.2 Company Structure
Many contemporary high tech companies nowadays are multinational, fast growing and financially successful, for a while. Their tremendous success is the major cause of their problems. When people are faced with a “change or die” choice they typically act and quickly. When the situation is not that bad, they do not have enough incentive to change anything. “If it ain’t broke, don’t fix it” mantra is the only rule.
Most multinationals have silly, ineffective structure, which primarily reflects the historical process of first products development plus merges and acquisitions. This structure has also a very strong impact on the culture, more specifically on its double nature. On the surface a cooperative business culture and “we are ONE company” are declared. Many top managers sincerely believe that this is the best for the company. But in reality it just doesn’t happen. In reality competitive, “multiple companies in one”, and too often Anglo-Saxon dominance cultures are prevailing. It is not something unique, and it doesn’t say if it’s good or bad. It’s just a reality, it just happens.
As evidence, examine carefully what happens at any company (especially strategic) meeting. Probably the most stunning conclusion is that the most talented people would be extremely bored and disappointed if their turned to be a really cooperative culture company. They want competition, and they like it. Not only externally, the company might not have enough competitors, but also internally. And consciously or not, top management encourages it.
The current policy is to perform similar activities in multiple places and to see which would survive. To a degree, it’s a wise approach from the business perspective, but has its price. In particular, it makes any improvement attempts through cross-corporate campaigns and committees virtually hopeless. Territorial considerations are still too prevalent. Unfortunately any local improvements, as a part of fair competition, are also condemned to fail or to be very limited. The reason is that the internal competition is primarily for projects and customers.
Once the whole company is competing internally for customers and projects everybody is trying to be everywhere. As a direct consequence software modules from different departments and sites are interlocked together in an extremely messy fashion. Just look at a build process and version control tree of any typical cross-site product. Interesting enough that the products, which are completely isolated (for example for security reasons), are developed using one cohesive line and normally do not experience this kind of problems (however they are at risk to be too provincial and detached from the main stream).
From the software engineering basics we all know very well that modularization is the only way to keep the system complexity and thus quality under control. As long as the company software product is one monolithic mess created by the job security and territorial defense-driven considerations any serious improvement is impossible. Remember, the biggest challenge to deal with is the software and technology created by THIS company (us!). There are very specific reasons why people write this software in that way.
Modularization of the system and separation of modules do not guarantee cooperation automatically but will move the power game towards responsibility allocation and interface specification (who is the boss). However it would allow quality improvements on the local basis, which is much easier to achieve. A fair competition in this case would even be an additional motivation factor.
Some embedded software products still have severe resource constraints (due to cost), which could seriously impede the modularization process suitable for multi-site. On the other hand I doubt if anybody has ever tried to attack this problem in a serious way. All in all everything is moving towards Linux, which is just a UNIX-like operating system.
Another serious obstacle could be fear of at least some departments that if they are not pushing themselves everywhere they will cease to exist very soon. Again, what top management says doesn’t matter. They key issue is how people feel.
Many contemporary high tech companies nowadays are multinational, fast growing and financially successful, for a while. Their tremendous success is the major cause of their problems. When people are faced with a “change or die” choice they typically act and quickly. When the situation is not that bad, they do not have enough incentive to change anything. “If it ain’t broke, don’t fix it” mantra is the only rule.
Most multinationals have silly, ineffective structure, which primarily reflects the historical process of first products development plus merges and acquisitions. This structure has also a very strong impact on the culture, more specifically on its double nature. On the surface a cooperative business culture and “we are ONE company” are declared. Many top managers sincerely believe that this is the best for the company. But in reality it just doesn’t happen. In reality competitive, “multiple companies in one”, and too often Anglo-Saxon dominance cultures are prevailing. It is not something unique, and it doesn’t say if it’s good or bad. It’s just a reality, it just happens.
As evidence, examine carefully what happens at any company (especially strategic) meeting. Probably the most stunning conclusion is that the most talented people would be extremely bored and disappointed if their turned to be a really cooperative culture company. They want competition, and they like it. Not only externally, the company might not have enough competitors, but also internally. And consciously or not, top management encourages it.
The current policy is to perform similar activities in multiple places and to see which would survive. To a degree, it’s a wise approach from the business perspective, but has its price. In particular, it makes any improvement attempts through cross-corporate campaigns and committees virtually hopeless. Territorial considerations are still too prevalent. Unfortunately any local improvements, as a part of fair competition, are also condemned to fail or to be very limited. The reason is that the internal competition is primarily for projects and customers.
Once the whole company is competing internally for customers and projects everybody is trying to be everywhere. As a direct consequence software modules from different departments and sites are interlocked together in an extremely messy fashion. Just look at a build process and version control tree of any typical cross-site product. Interesting enough that the products, which are completely isolated (for example for security reasons), are developed using one cohesive line and normally do not experience this kind of problems (however they are at risk to be too provincial and detached from the main stream).
From the software engineering basics we all know very well that modularization is the only way to keep the system complexity and thus quality under control. As long as the company software product is one monolithic mess created by the job security and territorial defense-driven considerations any serious improvement is impossible. Remember, the biggest challenge to deal with is the software and technology created by THIS company (us!). There are very specific reasons why people write this software in that way.
Modularization of the system and separation of modules do not guarantee cooperation automatically but will move the power game towards responsibility allocation and interface specification (who is the boss). However it would allow quality improvements on the local basis, which is much easier to achieve. A fair competition in this case would even be an additional motivation factor.
Some embedded software products still have severe resource constraints (due to cost), which could seriously impede the modularization process suitable for multi-site. On the other hand I doubt if anybody has ever tried to attack this problem in a serious way. All in all everything is moving towards Linux, which is just a UNIX-like operating system.
Another serious obstacle could be fear of at least some departments that if they are not pushing themselves everywhere they will cease to exist very soon. Again, what top management says doesn’t matter. They key issue is how people feel.
2.3 Nature of the Business and Market
This is a too big topic to be covered at any extent in such a short memo. It would suffice to say that some companies may be in a quite unique position. For example, from the number of users point of view the company could be on the mass market and inside of beginning Digital revolution tornado. However from the number of customers perspective it could still be in the early/niche market where very small number of major visionary customers dictate about 80% of the development. Under these circumstances the customer intimacy, and NOT the technology excellence, as some of would probably think or hope, turns to be the company major competitive advantage. Relying on so small a number of such influential customers is probably unhealthy from the business perspective, but might be VERY hard to change.
Under such circumstances even efficiency of the very basic matrix structure, and separation between marketing, product delivery and R&D as well as responsibility allocation between sites is questionable. The belief that establishing a Software Quality or any other kind of committee will really solve any serious quality problem in such environment is quite naïve.
This is a too big topic to be covered at any extent in such a short memo. It would suffice to say that some companies may be in a quite unique position. For example, from the number of users point of view the company could be on the mass market and inside of beginning Digital revolution tornado. However from the number of customers perspective it could still be in the early/niche market where very small number of major visionary customers dictate about 80% of the development. Under these circumstances the customer intimacy, and NOT the technology excellence, as some of would probably think or hope, turns to be the company major competitive advantage. Relying on so small a number of such influential customers is probably unhealthy from the business perspective, but might be VERY hard to change.
Under such circumstances even efficiency of the very basic matrix structure, and separation between marketing, product delivery and R&D as well as responsibility allocation between sites is questionable. The belief that establishing a Software Quality or any other kind of committee will really solve any serious quality problem in such environment is quite naïve.
2.4 Nature of the Software Development Process
If I could state in a single word the essence of the software development process I would scream out: “S-I-M-P-L-I-F-Y.” But we’re all doing the opposite. As a consequence we are constantly defeated by the monsters we have typed in with our own fingers. Our software is the main enemy to fight, but since we have lost any control over it our defeat is assured from the very beginning. It would be possible to overcome all other cultural, structural and business obstacles if our own software complexity would have been under control, but it’s not. And it’s running out of control at an accelerating speed. As a simple test, try to count the number of engineers, who have a clear picture of the overall structure of your company software. Chances are there won’t be too many. I also suspect that an unbiased check will prove this number to be negative due to the fact that too many people have a false image of this structure.
This is the REAL problem and it has a direct relation to the issues of campaigns and committees. Engineers, who have at least some understanding of the software structure are very busy and typically do not participate in any committee. Even if they do, they normally cannot contribute too much to its simplification since it will undermine their unique position as an XYZ module guru. Look around and you will find some spectacular examples. Engineers, who are less busy are also less knowledgeable and have not enough power to make a change since the very same gurus will fiercely resist any attempts of simplification. Intentionally or not the same dynamics makes these gurus to be irreplaceable, which in turn creates huge bottlenecks in the whole production chain.
As it stands now, the situation has no simple solution. Any campaign or committee will very soon deteriorate into a sequence of noisy presentations and cosmetic and very shallow fixes. But this process will not aim to make a deep change, which IS required.
If I could state in a single word the essence of the software development process I would scream out: “S-I-M-P-L-I-F-Y.” But we’re all doing the opposite. As a consequence we are constantly defeated by the monsters we have typed in with our own fingers. Our software is the main enemy to fight, but since we have lost any control over it our defeat is assured from the very beginning. It would be possible to overcome all other cultural, structural and business obstacles if our own software complexity would have been under control, but it’s not. And it’s running out of control at an accelerating speed. As a simple test, try to count the number of engineers, who have a clear picture of the overall structure of your company software. Chances are there won’t be too many. I also suspect that an unbiased check will prove this number to be negative due to the fact that too many people have a false image of this structure.
This is the REAL problem and it has a direct relation to the issues of campaigns and committees. Engineers, who have at least some understanding of the software structure are very busy and typically do not participate in any committee. Even if they do, they normally cannot contribute too much to its simplification since it will undermine their unique position as an XYZ module guru. Look around and you will find some spectacular examples. Engineers, who are less busy are also less knowledgeable and have not enough power to make a change since the very same gurus will fiercely resist any attempts of simplification. Intentionally or not the same dynamics makes these gurus to be irreplaceable, which in turn creates huge bottlenecks in the whole production chain.
As it stands now, the situation has no simple solution. Any campaign or committee will very soon deteriorate into a sequence of noisy presentations and cosmetic and very shallow fixes. But this process will not aim to make a deep change, which IS required.
3 So, What To Do?
Drawing a black pessimistic picture is a morbid, masochistic pastime, but is unlikely to be very constructive. Perhaps it would also be a sign of weakness, cowardice and the lack of professional responsibility. So the natural question is: “What should be done in order to improve the software quality?” Although this question has neither easy nor short answer, the answer still does exist. Below is a partial list suggesting what could be done for the software quality improvement:
Drawing a black pessimistic picture is a morbid, masochistic pastime, but is unlikely to be very constructive. Perhaps it would also be a sign of weakness, cowardice and the lack of professional responsibility. So the natural question is: “What should be done in order to improve the software quality?” Although this question has neither easy nor short answer, the answer still does exist. Below is a partial list suggesting what could be done for the software quality improvement:
- Ensure that each team operates as a highly cohesive independent unit loosely coupled with the rest of the company.
- If some unit (line, group) has no business justification to exist, close it. For employees of the rest of the units it should be guaranteed that any quality improvement does not jeopardize continuation of their employment, but perhaps it will not be the same unit.
- Stop flying hundreds of Indian developers around the world. We need them, but not for the reason which every thinks. (AS in the original version I wrote "for the cost saving", which I do not believe anymore). Every site must perform locally and assume the full responsibility for the quality of their work. The same is true for any other foreign manpower exchange.
- Ensure a free information exchange between all units. Any good practice, which works for one unit must be available for cloning in all other units (see my blog on using social networks).
- Avoid knowledge monopoly. If you cannot fire somebody tomorrow because (s)he knows too much, fire him/her today. At any price. Constantly insist on spreading the knowledge about the company unique technology. Package and simplify this knowledge. It will payoff dramatically at the newcomers absorption. Avoid conspiracy and excessive security whenever it’s possible.
- Stop paying bonuses for firefighting. Pay more ONLY for a smart work being done during the normal 8.5 hours working day. Stop pulling out people from their beds to solve yet another crisis. Leave them mobiles, ADSL at home, etc. as a part of their salary conditions, but not in order to be able to disturb them during a weekend lunch. You will need to walk this talk, and it won’t be easy, but the quality does never come the other way.
- Allocate a fixed budget (in men months) for consistent quality improvements. Let’s call it “quality tax” and enforce every line manager to use it for getting real improvements in quality. Do not accept any excuses. “You have no time, because you have no time,” could be only the answer. Any heroic actions of firefighting should not count.
- Establish a simple and practical system of quality metrics. It should be something very simple such that any top-level executive will not only understand it, but will also monitor it constantly and will act accordingly. Do not rely too much on fancy pie charts or any other kind of pyrotechnics. The most critical and reliable parameters could be obtained by a simple observation. Defect tracking and configuration management systems are very important but for another purpose.
- Insist on the full process transparency. Never punish the bad news bringers and never trust too optimistic reports. The situation will always be at certain degree bad. The only question is at which degree.
- If some module, product, component is going to be developed in parallel, that’s life. Do not hide this fact, but find a way to turn the internal competition to be a productive workforce. Conduct this internal competition in a fair way. It could be for instance an internal RFP published by product delivery or marketing departments.
- Insist on providing a fair chance to every unit. If your company is primarily developing, for example, in Java and C++ (Windows, Unix, etc.) ensure that every unit has enough experience in all languages and environments. Try to keep the overall amount of languages to a reasonable minimum. Try to take rid of “C” as soon as possible. It’s an old obsolete language, and all arguments against C++ it in so called embedded systems are merely excuses of people who during the last 15 years have never tired themselves to learn it. Ensure that all units have a reasonable level of skills in object-oriented design and programming and UML.
- Consider applying at least some of Agile practices such as iterations, test-driven development, and continuous integration.
- Insist on well established Configuration Management and Defect Tracking in every unit. This is the company insurance.
Etc., etc. There are many other good practices and advices, and there are many books, which contain them. More important is the overall attitude. I hope I did manage to deliver the message. After all, “we must be very careful when we give advice to vice presidents ("young people" in the original paper): sometimes they follow it!”
4 Concluding Remarks
The paper was intended for some serious managers and thus polished by a technical writer. My personal style is more bumpy. "You have big iron balls, man", he told me, "if you dare to write and submit such stuff to them". I do not think so. If this kind of purely innocent and basically good will paper (mostly a compilation from Jerry Weinberg's and other books) could not be published, there is something wrong. "Run out fear", Edwards Deming says. At least nothing harmful did happen to me.
Almost five years have passed since I wrote the first version, but I do not have too much to add. One additional tip would be with regard to meetings. Use $150 as a rough estimation of the company cost of man-hour (it really doesn't matter very much what is the cost) and multiply by the number of people attending the meeting and its scheduled length. Now ask yourself: if it was your company and your money would you pay for expected outcome out of your pocket. If the answer in NO, cancel the meeting. It's just a waste of time. For multi-nationals I could suggest to have only four types of meetings:
Anything else is a waste of time and should be avoided or at least kept to minimum.
- "Executive committee": people, who execute (for short/mid term results), meet and make decisions
- "Board of directors": people, who are responsible for long term results meet. discuss, and make strategic decisions
- All types of SCRUM meetings: planning, stand up, demo, restrospection, requirements and design workshops, celebrations
- Training session
Anything else is a waste of time and should be avoided or at least kept to minimum.
5 Further Reading
- Gerald M. Weinberg, Quality Software Management, vol.1, Systems Thinking
- Gerald M. Weinberg, Quality Software Management, vol.2, First-Order Measurement
- Gerald M. Weinberg, Quality Software Management, vol.3, Congruent Action
- Gerald M. Weinberg, Quality Software Management, vol.4, Anticipating Change
- Gerald M. Weinberg, Are Your Lights On: How to Figure Out What the Problem REALLY Is”
- William Laureu, Lean Leadership: From Chaos to Carrots, to Commitment
- Mary Popendieck, Tom Popendieck, Lean Software Development: An Agile Toolkit
- Geoffrey A. Moore, Living on the Fault Line
- Edsger W. Dijkstra, The Humble Programmer
- Edsger W. Dijkstra, On Useful Structuring
- Edsger W. Dijkstra, Notes on Structured Programming
- Robert C. Martin, Agile Software Development: Principles, Patterns, and Practices
- Tom DeMarco, T. Lister, Peopleware: Productive People and Teams
- P. Drucker, "Effective Excutive"
- K. Schwaber, "Agile Project Management with SCRUM"
No comments:
Post a Comment