Although many people do not want to admit it, 83.9% of IT projects failed partially or completely in 2019 (Standish Group Report 2019). This almost unbelievable figure has not improved significantly since 1994.
The reasons for the failed projects are clear to most and involve the lack of quality in the requirements. So far, DecisionMaking processes are missing to compensate for this lack safely and permanently. The success criteria from the Standish Group Report read as follows: user participation and management commitment are also safely integrated into DecisionMaking processes.
There is no shortage of competent agile teams, employees, managers, consultants, coaches and trainers.
Evading reality
In my projects, keynotes and seminars, the uncomfortable confrontation with these dramatic figures is avoided: “You would have to define what it means to fail or to be successful” or “With agile methods, we don’t have this problems”.
The answers to these evasive statements are clear and straightforward:
No, further definition is not necessary because it is sufficiently clear what “in time, in budget and in specification” means.
No, because the people involved are usually aware of and have experienced these pitfalls of failed projects themselves.
No, 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 opens up a new dimension of cooperation”
No, 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.
No, 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.
It is true 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“.
No, 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.
What failure means for people
The figure 83.9% of partially and completely failed IT projects stands also for the people who have to deal with this burden as well as the economic restrictions that come with it.
How frustrating is it when the review reflects to the agile team that their work in the sprint was not good? How great is the demotivation among the project members and the project manager if the approval is not granted after everyone has given their best? Those involved are familiar with the unhappiness that results, both those who have worked hard as well as those who do not receive the service they have ordered or requested. Those affected, whether they are internal or external project participants, are familiar with the distress that results when the assumed culprits have to suffer consequences.
Not only agile teams, project managers and project participants, but also partners, suppliers, architects, mayors and politicians and all those involved are familiar with the unpleasant side effects of failure. The consequences include frustration, loss of motivation, internal and real lay-offs/redundancies, the stifling of decision-making processes and the decline of project and corporate culture.
Remote collaboration intensifies the problem
The shortcomings, already apparent before the crisis, of jointly achieving sufficient quality have intensified in digital cooperation. Companies have been forced to organize their work remotely. It is no longer possible to coordinate quality deficiencies personally for a short period of time.
The cause lies rarely in the cooperation itself, but in the quality of the stories or the requirements.
The WeQuality Process ensures clarity
The word quality here refers to the prerequisite for giving people a chance to do well. Quality has two shades of meaning, including:
- an inner readiness, an attitude to do well with and for others. Quality includes generosity, kindness, helpfulness and mildness. Quality and goodness are characteristics of benevolence. The opposite of quality is severity.
- the degree of desired and intended quality, and thus the value of an object. Important examples, in this case, include the DIN standard or the internationally recognized quality standard ISO 9000.
The WeQuality Process brings together quality and mutually appreciative support into a clear and distinct process.
The use of severity or rigor, the opposite of quality, is limited in an environment of cooperation. In this way, the claim – to jointly produce appropriate quality – becomes the standard, while strictness becomes the exception in cases in which cooperation is entered into reluctantly. Thus, the WeQuality Process standardizes the attitude of mutually supportive cooperation and allows the individual’s inner poise to grow.
The venture’s 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.
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.
Consistent implementation of the Agile Manifesto
On the requirements side, the Product Owner is the person responsible for the agile-way-of-working; in traditional projects, the person responsible is ultimately the project manager once the project order has been closed. The WeQuality Process places the responsibility not only on the person who makes a requirement, the process predecessor, but also on the process successor as well as on the agile implementation team so that they can organize the work themselves and implement it responsibly.
The Product Owner is responsible for the quality of the stories in the backlog, which represent the work queue. The quality reflects how mature the stories are before they become tasks in the sprint backlog. The required quality of the stories depends on many parameters, such as the maturity of the team and the maturity of the agile-way-of-working. For the WeQuality Process, the story is only extended by two quality metrics in the how dimension.
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.
WeQuality Process
With the quality metrics in the story description, all parties involved, including the stakeholders, the Product Owner, Scrum Master and the agile team are provided with the right conditions for a secure and transparent process in which stories mature and the agile team gets a chance to do a successful job.
The WeQuality Process is an application of the KiE Scale designed to achieve a standardized and accepted evaluation not only of the quality indicators but of the Resource Question, which is used to identify the necessary resources.
More in this series of articles: “Cooperation at eye level with a universal evaluation system“.
More in this series of articles: “The Resource Question opens a new dimension of cooperation”.
The two KiE Numbers (8,7) are used to safely control the process and to assign the respective responsibilities to the individuals based on their roles and to hold them accountable.
Innovation 01: The Product Owner assigns a quality score (8) to the story, see figure 02, depending on his evaluation of the quality of the story. As an innovation, the WeQuality Process leads the Product Owner into the agile values:
- Openness
- Participation
- Focus, eye level
- Courage
- Appreciation and
- Commitment
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.
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.
This is how quality matures
Innovation 02: 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.
The KiE Number reflected by the agile team expresses appreciation for the Product Owner’s work, especially if the number is (8), (9) or (10=excellent). The agile values simply become a fact of life, instead of a source of distress.
Innovation 03: 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.
If the quality rating is a (6) or (7), the agile team expresses that improvements are still necessary to do well. If the quality number is between (1) to (5), the story is rejected because the quality is not sufficient.
Innovation 04: 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.
The slight increase of the quality of (6) or (7) can be solved directly in a dialogue with the Product Owner. If necessary, the Product Owner can then use the Agile Master to give the agile team what they need to work well. In case of a larger gap, with a quality ranging between (1) to (5), the Product Owner has to consult with the Story Owner and, if necessary, with the stakeholders in order to deliver a higher quality. Here, too, the Agile Master can provide support. The agile team is also obliged to provide the resources so that the Product Owner can now do his work well. Through this process, everyone grows collectively and the agile way of working becomes more solid.
Innovation 05: 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.
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.
Innovation 06: 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.
The integration of the quality metrics in collaboration tools like Jira or Trello are easy to manage. The municipal administration of one large German city, placed the quality indicators as well as the Resource Question on a supplementary sheet of its input plans.
As a reward, the agile mindset develops in all participants because the agile values of openness, participation, focus, eye level, courage, appreciation and commitment are behaviorally embedded and reinforced in the process.
Moreover, the DecisionMaking and corporate cultures develop in a self-responsible and self-organized way because the work has been accomplished successfully. Thus, DecisionMaking evolves as integrative leadership instead of authoritarian and participatory leadership.
Prioritisation and commitments
When, after the WeQuality Process has been completed, the stories are clearly described and people have come to understand each other better, the conditions are in place for Prioritization to determine what will and will not be done in sprint planning.
After Prioritization, the Commitment Process becomes a snap, and the sprint goal and associated stories can easily be committed to in sprint planning.
This creates all the conditions for a successful review, with stakeholders again using the quality metric to appreciate the results achieved or sending them into another loop for improvement. Thus, the loop, starting from the requirement through the epic, story and the implemented result is closed.
The success criteria, which are clearly identified in the Standish Group Report (2019), are also important. That is, user participation, stakeholder commitment and realistic expectations are securely anchored as process components of the WeQuality Process and DecisionMaking Processes and increase the chance of successful work.
All participants in the agile way of working now have the chance to do their work well and the chance for the stakeholders to get what they need increases. The WeQuality Process thus supports self-organization to ensure a functioning cooperation and an appreciative approach.
People are beginning to develop mutual understanding, to work more closely together and to give each other a chance to do well.
The DecisionMaking Processes can be used with the digitized DecisionMaker for both presence and remote collaboration. With the DecisionMaker, both the WeQuality Process and the Prioritization and Commitment Processes can be mapped. More mature agile teams will implement the quality metrics in the backlog system and integrate the digitized DecisionMaker in all agile ceremonies.
More in this article series: “Bring about shared decisions with the digital KiE-DecisionMaker“.
WeQuality Process for more complex processes
The WeQuality Process is suitable for simple delegation, for simple agile way of working as well as for complex traditional projects and scaled agile.
Success-Story DevOps – Velocity from 3 to 30
The world’s largest software integrator started a DevOps project at the German third largest car manufacturer with a classical approach and was on the verge of failure with a retrospectively measured velocity of 3 after 12 months. As a remedial measure, DecisionMaking with Scrum was introduced as an agile method. Even though or perhaps due to the fact that the team was forced to collaborate remotely, the WeQuality Process had an overwhelming effect immediately after the introduction of the agile way of working.
The agile transformation took 3 months and after 6 sprints a stable velocity had been reached. The DevOps project was successfully completed after 16 months.
Success-Story Business Engineering – Quality from 3 to 8
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.
In fact, only 60% of the stories in the review were accepted. However, the shadowing during the planning phase showed a highly developed Scrum procedure with a quality of (9) as well as a sufficient quality (8) in the sprint backlog.
The assumption that the agile team had not been working properly could not be confirmed after a few hours of shadowing. The Resource Question applied by the experienced agile team showed that the stories had been specified with an average of only one quality (3) and that senior members of the agile team, in elaborate analyses, had been able to raise the quality of the sub-tasks to (8). In short, shadowing and analysis of the artifacts were carried out; product backlog and business requests confirmed the assumption that the levels of quality as low as (3) or (2) were simply not sufficient to do the job well.
The agile coaching was rededicated to an agile transformation coaching for the creation of an agile process for “Business-Requirement-Creation”. The participants were trained in DecisionMaking, whereupon the agile process “Business-Requirement-Creation” with agile ceremonies and artifacts was designed, introduced and consolidated.
After 6 months, the Business-Requirement-Process was introduced with the commitment of the executive board. Since then, all artifacts have been created with adequate resources and in adequate quality. The quality is produced in early phases, which limits later problems and expenses. Finally, a closed cycle leads to a high level of maturity of the product increments, while allowing the competencies and the trust among participants to grow.
“With the WeQuality Process, the personal responsibility of those involved develops as a prerequisite for achieving joint success. In addition, joint support for the overall delivery result is developed and anchored in the process.” Richard Graf
More about remote collaboration
The current crisis is forcing us all to work together digitally. 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.
The freely accessible digitized KiE-DecisionMaker solves these problems.
More articles about remote collaboration can be found after the sources below at tag “Artificial Intelligence“.
_______________
June 2020 – Richard Graf, Elsa Graf
“Lack of Quality is the top factor in all partially or completely failed ventures.” Richard Graf
Sources
Graf, Richard: Die neue Entscheidungskultur: mit gemeinsam getragenen Entscheidungen zum Erfolg. Carl Hanser Verlag GmbH Co KG, 2018
Graf, Richard: Die neue Entscheidungskultur: mit gemeinsam getragenen Entscheidungen zum Erfolg. Carl Hanser Verlag GmbH Co KG, 2018
K. Beck et. al. (2001). Manifest für agile Softwareentwicklung. Abgerufen 02. Juni 2020, von https://agilemanifesto.org/iso/de/manifesto.html
Standish Group report 2019. Abgerufen 02. Juni 2020. www.opendoorerp.com/the-standish-group-report-83-9-of-it-projects-partially-or-completely-fail/
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
Jeff Sutherland et. al.: Unternehmensführung Schnell und Flexibel, Abgerufen am 12. Juni 2020 von https://www.harvardbusinessmanager.de/heft/d-146757099.html
Graf, Richard: Die neue Entscheidungskultur: mit gemeinsam getragenen Entscheidungen zum Erfolg. Carl Hanser Verlag GmbH Co KG, 2018
K. Beck et. al. (2001). Manifest für agile Softwareentwicklung. Abgerufen 02. Juni 2020, von https://agilemanifesto.org/iso/de/manifesto.html
Standish Group report 2019. Abgerufen 02. Juni 2020. www.opendoorerp.com/the-standish-group-report-83-9-of-it-projects-partially-or-completely-fail/
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
Comments are closed.