![\"KiE:](\"https:\/\/www.k-i-e.com\/wp-content\/uploads\/2020\/06\/228-en-01-Standish-Group-Report-2019-KiE-Labs-Inc..jpg\")
The reasons for the failed projects are clear to most and involve the lack\nof quality in the requirements. So far, DecisionMaking processes are missing to\ncompensate for this lack safely and permanently. The success criteria from the\nStandish Group Report read as follows: user participation and management\ncommitment are also safely integrated into DecisionMaking processes. <\/p>\n\n\n\n
There is no shortage of competent agile teams, employees, managers,\nconsultants, coaches and trainers.<\/p>\n\n\n\n
Evading reality<\/h2>\n\n\n\n
In my projects, keynotes and seminars, the uncomfortable confrontation\nwith these dramatic figures is avoided: “You would have to define what it\nmeans to fail or to be successful” or “With agile methods, we don\u2019t\nhave this problems”. <\/p>\n\n\n\n
The answers to these evasive statements are clear and straightforward:<\/p>\n\n\n\n
No<\/strong>, further definition is not necessary because it is sufficiently clear what “in time, in budget and in specification” means. <\/p>\n\n\n\n No<\/strong>, because the people involved are usually aware of and have experienced these pitfalls of failed projects themselves. <\/p>\n\n\n\n No<\/strong>, because with the Resource Question, which has already been presented in this series of articles, the problem talk would immediately turn into a solution talk and all resources would become visible that would be necessary to give everyone a chance to do well: “The Resource Question<\/a> opens up a new dimension of cooperation”<\/p>\n\n\n\n No<\/strong>, because the publications of the Standish Group (2019), IBM and McKinsey (2019) and many others speak a clear language and provide similar figures and causes. <\/p>\n\n\n\n No<\/strong>, because the over-differentiation in specialized books, articles, posts and further training usually obscures the situation and introduces a level of complexity that is not helpful. <\/p>\n\n\n\n It is true<\/strong> that agile methods have a higher success rate, but this is countered by the fact that agile transformations have also been observed to fail by 70% (McKinsey 2019). Even well-rehearsed teams have been seen to suffer from the lack of quality of the stories. More in this series of articles: “With the WeQuality Process, agile as well as classic projects succeed<\/a>“.<\/p>\n\n\n\n No<\/strong>, the agile way of working has improved collaboration and limited the excesses of documentation, but often at the expense of quality. The call in the “Manifesto for Agile Software Development” (Beck et. al., 2001) to value working software more highly than comprehensive documentation has often been misinterpreted. The trick is not to lose oneself in polarities between functioning software and the quality of the stories, but to give the agile teams a chance so that they can do the work well in a self-organized way. More in this series of articles: Survey Code Days 2019 shows the lack of quality as a top factor in failed projects by means, for example, of cases of success when the WeQuality Process was in place<\/a>.<\/a><\/p>\n\n\n\n The figure 83.9% of partially and completely failed IT projects stands\nalso for the people who have to deal with this burden as well as the economic\nrestrictions that come with it. <\/p>\n\n\n\n How frustrating is it when the review reflects to the agile team that\ntheir work in the sprint was not good? How great is the demotivation among the\nproject members and the project manager if the approval is not granted after\neveryone has given their best? Those involved are familiar with the unhappiness\nthat results, both those who have worked hard as well as those who do not\nreceive the service they have ordered or requested. Those affected, whether\nthey are internal or external project participants, are familiar with the\ndistress that results when the assumed culprits have to suffer consequences. <\/p>\n\n\n\n Not only agile teams, project managers and project participants, but\nalso partners, suppliers, architects, mayors and politicians and all those\ninvolved are familiar with the unpleasant side effects of failure. The\nconsequences include frustration, loss of motivation, internal and real lay-offs\/redundancies,\nthe stifling of decision-making processes and the decline of project and\ncorporate culture.<\/p>\n\n\n\n The shortcomings, already apparent before the crisis, of jointly\nachieving sufficient quality have intensified in digital cooperation. Companies\nhave been forced to organize their work remotely. It is no longer possible to\ncoordinate quality deficiencies personally for a short period of time. <\/p>\n\n\n\n The cause lies rarely in the cooperation itself, but in the quality of\nthe stories or the requirements.<\/p>\n\n\n\n The word quality here refers to the prerequisite for giving people a\nchance to do well. Quality has two shades of meaning, including:<\/p>\n\n\n\n The WeQuality Process brings together quality and mutually appreciative\nsupport into a clear and distinct process. <\/p>\n\n\n\n The use of severity or rigor, the opposite of quality, is limited in an\nenvironment of cooperation. In this way, the claim – to jointly produce\nappropriate quality – becomes the standard, while strictness becomes the\nexception in cases in which cooperation is entered into reluctantly. Thus, the WeQuality\nProcess standardizes the attitude of mutually supportive cooperation and allows\nthe individual\u2019s inner poise to grow. <\/p>\n\n\n\n The venture\u2019s quality is brought about by the WeQuality Process in a self-responsible and self-organized way. This can be extended to all those involved, such as colleagues, divisions, the entire company and beyond the company’s boundaries to customers, suppliers and partners. The resulting complexity and number of participants as well as the high speed are usually no longer controllable by directives and efficiency targets can therefore become difficult to meet. The WeQuality Process reduces external control and shifts the organizational challenges to the personal responsibility of the participants. <\/p>\n\n\n\n So, what can the team and the stakeholders do to ensure that stories are described well enough for the next step of the process? This step is used in the agile way of working, especially in refinement, as shown in Figure 02 in form of a simple Scrum process; the same step is used in all other process transitions from ideas to stories and in sprint planning for the implementation of the product increment. The cycle closes in the review and the product increment reveals how well the idea has been implemented. In classic projects, space should be created to allow the requirements to mature in their quality. <\/p>\n\n\n\n On the requirements side, the Product Owner is the person responsible\nfor the agile-way-of-working; in traditional projects, the person responsible is\nultimately the project manager once the project order has been closed. The WeQuality\nProcess places the responsibility not only on the person who makes a\nrequirement, the process predecessor, but also on the process successor as well\nas on the agile implementation team so that they can organize the work\nthemselves and implement it responsibly. <\/p>\n\n\n\n The Product Owner is responsible for the quality of the stories in the\nbacklog, which represent the work queue. The quality reflects how mature the\nstories are before they become tasks in the sprint backlog. The required\nquality of the stories depends on many parameters, such as the maturity of the\nteam and the maturity of the agile-way-of-working. For the WeQuality Process,\nthe story is only extended by two quality metrics in the how dimension.<\/p>\n\n\n\n The Agile Manifesto is consistently implemented and only as much documentation is provided as is needed by the stakeholders to create a product increment that corresponds to the stakeholders’ idea in the subsequent product review. The scope as well as the detailing of the stories are adapted to the maturity of the participants in the agile way of working and is reduced in a self-organized way to the appropriate level in order to enable successful cooperative work.<\/p>\n\n\n\n With the quality metrics in the story description, all parties involved,\nincluding the stakeholders, the Product Owner, Scrum Master and the agile team are\nprovided with the right conditions for a secure and transparent process in\nwhich stories mature and the agile team gets a chance to do a successful job. <\/p>\n\n\n\n The WeQuality Process is an application of the KiE Scale designed to\nachieve a standardized and accepted evaluation not only of the quality\nindicators but of the Resource Question, which is used to identify the necessary\nresources. <\/p>\n\n\n\n More in this series of articles: “Cooperation at eye level with a universal evaluation system<\/a>“.<\/p>\n\n\n\n More in this series of articles: “The Resource Question<\/a> opens a new dimension of cooperation”.<\/p>\n\n\n\n The two KiE Numbers (8,7) are used to safely control the process and to\nassign the respective responsibilities to the individuals based on their roles\nand to hold them accountable. <\/p>\n\n\n\n Innovation 01: The Product Owner\nassigns a quality score (8) to the story, see figure 02, depending on his\nevaluation of the quality of the story. As an innovation, the WeQuality Process\nleads the Product Owner into the agile values: <\/p>\n\n\n\n How does that happen? The Product Owner is led to reflect on the quality he or she has produced. This first innovation is unusual in the agile and traditional working world and represents the first success factor. <\/p>\n\n\n\n Good enough means an (8) on the standard KiE Scale and is usually expected and assumed to be standard quality. Sometimes, however, it makes sense to choose a lower quality to signal to the agile team that the story is not yet mature. <\/p>\n\n\n\n Innovation 02: <\/strong>The agile team, in turn, provides feedback to the product owner via a KiE Number (7), see figure 02, on the quality the story actually has for them and on their ability to implement the story well. This second innovation is central because it anchors personal responsibility in the WeQuality Process. Moreover, innovation two no longer prescribes what should be, which has only fueled the familiar fruitless interdependencies that people and companies have been struggling with for so many years. The agile team can now act openly with a clear focus on the maturing process and demand the necessary input at eye level. <\/p>\n\n\n\n The KiE Number reflected by the agile team expresses appreciation for\nthe Product Owner’s work, especially if the number is (8), (9) or\n(10=excellent). The agile values simply become a fact of life, instead of a\nsource of distress. <\/p>\n\n\n\n Innovation 03:<\/strong> The further process of cooperation is openly anchored in the WeQuality Process and everyone involved is aware of what has to be done and who is responsible for which situation. The team can work on the story without further communication when the quality score is between (8) to (10). The openness allows the team to take responsibility for ensuring that the agile cooperation is successful. Here, classical leadership is replaced or expanded by DecisionMaking. <\/p>\n\n\n\n If the quality rating is a (6) or (7), the agile team expresses that\nimprovements are still necessary to do well. If the quality number is between (1)\nto (5), the story is rejected because the quality is not sufficient.<\/p>\n\n\n\n Innovation 04: <\/strong>The agile team is now required to inform the Product Owner, by means of the Resource Question, what it still needs to achieve a quality of (8) or possibly (9) and (10) in the story. This innovation changes the collaboration fundamentally; problem-focused talk, including moaning and groaning or even resignation, is replaced by solution-focused discussion. The individual ensures a positive outcome for everyone. <\/p>\n\n\n\n The slight increase of the quality of (6) or (7) can be solved directly\nin a dialogue with the Product Owner. If necessary, the Product Owner can then\nuse the Agile Master to give the agile team what they need to work well. In\ncase of a larger gap, with a quality ranging between (1) to (5), the Product\nOwner has to consult with the Story Owner and, if necessary, with the\nstakeholders in order to deliver a higher quality. Here, too, the Agile Master\ncan provide support. The agile team is also obliged to provide the resources so\nthat the Product Owner can now do his work well. Through this process, everyone\ngrows collectively and the agile way of working becomes more solid.<\/p>\n\n\n\n Innovation 05: <\/strong>The whole team learns self-responsibly and in a self-organized manner within the framework and protection of the WeQuality Process. That sounds very simple and it is. Nevertheless, the WeQuality Process has a great effect, especially for projects that work in different locations with remote collaboration. The communication between people thus becomes more clearly oriented, so that small details that might otherwise have been overlooked do not lead to major escalations later on. Through the graded interaction, everyone experiences that the resources needed to achieve a good result are in large part available. <\/p>\n\n\n\n If significant issues are unclear, these gaps become apparent at an early stage as opposed to in the review, when the agile team has already done the work. In this way, valuable resources cannot only be saved, but the agile team can achieve a high rating for product increment in the review, while avoiding negative consequences for motivation and self-confidence.<\/p>\n\n\n\n Innovation 06: <\/strong>Classical leadership is replaced by DecisionMaking, which is integrative leadership. In fact, the integration of the WeQuality Process and the DecisionMaking processes is a change that ought to be introduced, committed to and consolidated as such. <\/p>\n\n\n\n The integration of the quality metrics in collaboration tools like Jira\nor Trello are easy to manage. The municipal administration of one large German\ncity, placed the quality indicators as well as the Resource Question on a\nsupplementary sheet of its input plans. <\/p>\n\n\n\n As a reward, the agile mindset develops in all participants because the\nagile values of openness, participation, focus, eye level, courage,\nappreciation and commitment are behaviorally embedded and reinforced in the\nprocess. <\/p>\n\n\n\n Moreover, the DecisionMaking and corporate cultures develop in a\nself-responsible and self-organized way because the work has been accomplished successfully.\nThus, DecisionMaking evolves as integrative leadership instead of authoritarian\nand participatory leadership.<\/p>\n\n\n\n When, after the WeQuality Process has been completed, the stories are\nclearly described and people have come to understand each other better, the\nconditions are in place for Prioritization to determine what will and will not\nbe done in sprint planning. <\/p>\n\n\n\n After Prioritization, the Commitment Process becomes a snap, and the\nsprint goal and associated stories can easily be committed to in sprint\nplanning. <\/p>\n\n\n\n This creates all the conditions for a successful review, with\nstakeholders again using the quality metric to appreciate the results achieved\nor sending them into another loop for improvement. Thus, the loop, starting\nfrom the requirement through the epic, story and the implemented result is\nclosed. <\/p>\n\n\n\n The success criteria, which are clearly identified in the Standish Group\nReport (2019), are also important. That is, user participation, stakeholder\ncommitment and realistic expectations are securely anchored as process\ncomponents of the WeQuality Process and DecisionMaking Processes and increase\nthe chance of successful work. <\/p>\n\n\n\n All participants in the agile way of working now have the chance to do their\nwork well and the chance for the stakeholders to get what they need increases.\nThe WeQuality Process thus supports self-organization to ensure a functioning\ncooperation and an appreciative approach. <\/p>\n\n\n\n People are beginning to develop mutual understanding, to work more\nclosely together and to give each other a chance to do well.<\/p>\n\n\n\n The DecisionMaking Processes can be used with the digitized\nDecisionMaker for both presence and remote collaboration. With the\nDecisionMaker, both the WeQuality Process and the Prioritization and Commitment\nProcesses can be mapped. More mature agile teams will implement the quality\nmetrics in the backlog system and integrate the digitized DecisionMaker in all\nagile ceremonies. <\/p>\n\n\n\n More in this article series: “Bring about shared decisions with the digital KiE-DecisionMaker<\/a>“.<\/p>\n\n\n\n The WeQuality Process is suitable for simple delegation, for simple\nagile way of working as well as for complex traditional projects and scaled\nagile. <\/p>\n\n\n\n The world’s largest software integrator started a DevOps project at the German\nthird largest car manufacturer with a classical approach and was on the verge\nof failure with a retrospectively measured velocity of 3 after 12 months. As a remedial\nmeasure, DecisionMaking with Scrum was introduced as an agile method. Even\nthough or perhaps due to the fact that the team was forced to collaborate\nremotely, the WeQuality Process had an overwhelming effect immediately after\nthe introduction of the agile way of working.<\/p>\n\n\n\n The agile transformation took 3 months and after 6 sprints a stable\nvelocity had been reached. The DevOps project was successfully completed after\n16 months.<\/p>\n\n\n\n During an agile transformation coaching at a large German online retailer, the original problem was the low grade (6) in the product review. The board’s assumption had been that the agile team would not be able to produce the quality required for acceptance. The shadowing, in which an experienced Agile Coach attended the agile ceremonies, revealed both the problem as well as the solution. <\/p>\n\n\n\n In fact, only 60% of the stories in the review were accepted. However,\nthe shadowing during the planning phase showed a highly developed Scrum\nprocedure with a quality of (9) as well as a sufficient quality (8) in the\nsprint backlog. <\/p>\n\n\n\n The assumption that the agile team had not been working properly could\nnot be confirmed after a few hours of shadowing. The Resource Question applied\nby the experienced agile team showed that the stories had been specified with\nan average of only one quality (3) and that senior members of the agile team,\nin elaborate analyses, had been able to raise the quality of the sub-tasks to\n(8). In short, shadowing and analysis of the artifacts were carried out; product\nbacklog and business requests confirmed the assumption that the levels of quality\nas low as (3) or (2) were simply not sufficient to do the job well. <\/p>\n\n\n\n The agile coaching was rededicated to an agile transformation coaching\nfor the creation of an agile process for\n“Business-Requirement-Creation”. The participants were trained in\nDecisionMaking, whereupon the agile process “Business-Requirement-Creation”\nwith agile ceremonies and artifacts was designed, introduced and consolidated. <\/p>\n\n\n\n After 6 months, the Business-Requirement-Process was introduced with the\ncommitment of the executive board. Since then, all artifacts have been created\nwith adequate resources and in adequate quality. The quality is produced in\nearly phases, which limits later problems and expenses. Finally, a closed cycle\nleads to a high level of maturity of the product increments, while allowing the\ncompetencies and the trust among participants to grow.<\/p>\n\n\n\n “With the WeQuality Process, the personal responsibility of those\ninvolved develops as a prerequisite for achieving joint success. In addition,\njoint support for the overall delivery result is developed and anchored in the\nprocess<\/em>.” Richard Graf<\/p>\n\n\n\n The current crisis is forcing us all to work together digitally<\/a>. The shortcomings of making decisions together, which had already been apparent before the crisis, have intensified in digital cooperation. Companies now have to organize their work remotely and many people are trying to maintain their social contacts with it.<\/p>\n\n\n\n The freely accessible digitized KiE-DecisionMaker<\/a> solves these problems.<\/p>\n\n\n\n More articles about remote collaboration can be found after the sources below at tag \u201cArtificial Intelligence<\/a>\u201c.<\/p>\n\n\n\n _______________<\/p>\n\n\n\n June 2020 – Richard Graf, Elsa Graf<\/p>\n\n\n\n “Lack of Quality is the top factor in all partially or completely failed ventures<\/em>.” Richard Graf<\/p>\n\n\n\n Graf, Richard: Die neue Entscheidungskultur: mit gemeinsam getragenen Entscheidungen zum Erfolg. Carl Hanser Verlag GmbH Co KG, 2018<\/p>\n\n\n\n Graf, Richard: Die neue Entscheidungskultur: mit gemeinsam getragenen Entscheidungen zum Erfolg. Carl Hanser Verlag GmbH Co KG, 2018<\/p>\n\n\n\n K. Beck et. al.\n(2001). Manifest f\u00fcr agile Softwareentwicklung. Abgerufen 02. Juni 2020, von https:\/\/agilemanifesto.org\/iso\/de\/manifesto.html<\/a> <\/p>\n\n\n\n Standish Group\nreport 2019. Abgerufen 02. Juni 2020. www.opendoorerp.com\/the-standish-group-report-83-9-of-it-projects-partially-or-completely-fail\/<\/a><\/p>\n\n\n\n McKinsey (2019): Why do most transformations fail?. Abgerufen 02. Juni 2020, von https:\/\/www.mckinsey.com\/business-functions\/transformation\/our-insights\/why-do-most-transformations-fail-a-conversation-with-harry-robinson<\/a> <\/p>\n\n\n\n Jeff Sutherland et. al.:\nUnternehmensf\u00fchrung Schnell und Flexibel, Abgerufen am 12. Juni 2020 von https:\/\/www.harvardbusinessmanager.de\/heft\/d-146757099.html<\/a><\/p>\n\n\n\n Graf, Richard: Die neue Entscheidungskultur: mit gemeinsam getragenen Entscheidungen zum Erfolg. Carl Hanser Verlag GmbH Co KG, 2018<\/p>\n\n\n\n K. Beck et. al. (2001). Manifest f\u00fcr\nagile Softwareentwicklung. Abgerufen 02. Juni 2020, von https:\/\/agilemanifesto.org\/iso\/de\/manifesto.html<\/a> <\/p>\n\n\n\n Standish Group report 2019. Abgerufen\n02. Juni 2020. www.opendoorerp.com\/the-standish-group-report-83-9-of-it-projects-partially-or-completely-fail\/<\/a><\/p>\n\n\n\nWhat failure means for people<\/h2>\n\n\n\n
Remote collaboration intensifies the problem<\/h2>\n\n\n\n
The WeQuality Process ensures clarity<\/h2>\n\n\n\n
![\"Simple](\"https:\/\/www.k-i-e.com\/wp-content\/uploads\/2020\/06\/228-en-02-Simple-agile-process-with-quality-process-June-11-2020-KiE-Labs-Inc..png\")
Consistent implementation of the Agile Manifesto<\/h2>\n\n\n\n
![\"KiE:](\"https:\/\/www.k-i-e.com\/wp-content\/uploads\/2020\/06\/228-en-03-Dimensions-of-a-Story-with-Quality-Numbers-KiE-Labs-Inc..jpg\")
WeQuality Process<\/h2>\n\n\n\n
![\"KiE:](\"https:\/\/www.k-i-e.com\/wp-content\/uploads\/2020\/06\/228-en-04-The-Quality-Process-KiE-Labs-Inc.-1.jpg\")
This is how quality matures<\/h2>\n\n\n\n
Prioritisation and commitments<\/h2>\n\n\n\n
![\"KiE](\"https:\/\/www.k-i-e.com\/wp-content\/uploads\/2020\/06\/228-en-05-DecisionMaking-Processes-KiE-Labs-Inc.-1.jpg\")
WeQuality Process for more complex processes<\/h2>\n\n\n\n
![\"KiE:](\"https:\/\/www.k-i-e.com\/wp-content\/uploads\/2020\/06\/228-en-06-complex-Projects-and-Scaled-Agile-KiE-Labs-Inc.-1.jpg\")
Success-Story DevOps \u2013 Velocity from 3 to 30<\/h2>\n\n\n\n
![\"KiE:](\"https:\/\/www.k-i-e.com\/wp-content\/uploads\/2020\/06\/228-en-07-Success-Story-DevOps-Velocity-3-to-30-KiE-Labs-Inc..jpg\")
<\/figcaption><\/figure><\/div>\n\n\n\nSuccess-Story Business Engineering \u2013 Quality from 3 to 8 <\/h2>\n\n\n\n
![\"KiE:](\"https:\/\/www.k-i-e.com\/wp-content\/uploads\/2020\/06\/228-en-08-Agile-Coaching-Shadowing-2020-KiE-Labs-Inc..jpg\")
More about remote collaboration<\/h2>\n\n\n\n
Sources<\/h2>\n\n\n\n