The next planning is coming up and the backlog is not structured or described well enough to allow the team to estimate properly? You are given a task at short notice that you don’t really understand? Shit-In/Shit-Out is a major reason for the lack of success of agile methods and the failure of so many projects. The Standish Group report (2019) identifies the lack of quality as a top factor for such failure: “83.9% of IT projects partially or completely fail.
What exactly has to be done is often not clear
Often, remote collaboration increases the problems. However, the cause of these problems is not the collaboration itself, but often the quality of the stories in relation to the given requirements. Quality here means the prerequisite for giving people a chance to do well. Quality, in this sense, would stand opposed to rigor. According to the Manifesto for Agile Software Development, functioning software is valued more highly than comprehensive documentation (Beck et. al., 2001). Agile way of working has improved collaboration and limited the excesses of documentation, but often at the expense of quality.
Quality is the level of care and mutually supportive collaboration necessary to ensure that the follow-up processes run smoothly and that stakeholders get what they need.
Those who cannot ask colleagues at short notice what is meant by the story or task are often left hanging alone in mid air. One can do one’s best and speculate on what might be meant; still, the situation becomes all the more annoying when one has misinterpreted the story and must deal with the bitter receipt in the review. Thus, a brief look at the task description beforehand will reveal whether people have a chance to do well or not.
A survey during Code Days 2019 showed an average quality of the stories in the backlog of (5), which is not sufficient on the KiE scale (1 to 10).
The agile experts, who have all played an operational role in agile projects, thus rated 91% of the stories from their respective practical experience as not good enough. The experience from 10 years of Agile Transformation Coaching shows a similar picture: the quality of the stories about different industries and diverse projects lies at a mere (5). This does not mean that your industry or project are among them; it only means that if Agile Transformation was necessary, the quality was always an issue, which showed considerable potential for improvement.
The Quality Process delivers clarity
So, what can the team and the stakeholder do to ensure that stories are described well enough for the next step in the process? The key is the Quality Process. This is used and implemented in Agile Way of Working, especially in Refinement, as in all process transitions from the epic to stories. In classic projects, space should be created to let the requirements mature in their quality.
Story or request
On the requirements side, the product owner is the person responsible for agile way of working; in traditional projects, the responsible person is ultimately the project manager once the project order has been closed. The quality process focuses first on the person – the predecessor – who makes a requirement and then on the follower as well as the agile implementation team.
The product owner is responsible for the quality of the stories in the backlog, which represents the worklist. The quality reflects how mature the stories or requirements 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. Typical of a quality story, however, are a priority, result type and scope, a short description, the goal being pursued, and the owner. Only when the stories are mature enough, in other words, when the agreed dimensions are described in the stories, does the product owner assign a quality index as a KiE number. This is the assessment of how well the story is described from the point of view of the product owner. Good enough would mean an (8) on the KiE scale.
This is how quality matures
The agile team, in turn, provides feedback to the product owner via a KiE number, on the quality the story actually has for them and on their ability to implement the story well. If the number is between (8) and (10), the team expresses their appreciation for the Product Owner’s work. The agile values simply become a fact of life, instead of being complained about. The agile team can work on the story without further communication.
If the quality score is a (6) or (7), the agile team expresses that improvements are still necessary to do the job well. The agile team now has to inform the Product Owner via the resource question of what is still needed to achieve a quality of (8) in the story. The slight increase in quality necessary is solved directly in the dialog with the Product Owner. The Product Owner can then give the agile team what they need to work well.
If the quality number is from (1) to (5), the story will be rejected because the quality is insufficient. In this case, the Product Owner has to consult with the owner of the story again and deliver a higher quality. Here, too, the agile team is obliged to provide the resources so that the Product Owner can now do his job well. Through this process, everyone grows collectively and the agile way of working becomes more solid.
That sounds very simple and it is. At the same time, the Quality Process has a great effect. Especially in projects that involve remote collaboration from different locations, people talk to each other with a clear orientation; although they usually find that only small details are missing, such oversights often lead to major escalations. Through the graded interaction, everyone experiences that the resources needed to achieve a good result are in large part available. In fact, the integration of the quality and the DecisionMaking processes is a change that must be introduced, committed to, and made permanent. The integration of the quality metrics in collaboration tools like Jira or Trello requires only little effort.
Prioritization and commitments
When, after the Quality Process has been completed, so that the stories are clearly described and people understand each other better, the prerequisites are now in place for prioritizing and then determining in sprint planning what will and will not be done.
After prioritization and sprint planning, the commitment process makes it easy to commit to the goal and to the associated stories for the sprint.
This creates all the conditions for a successful review, where stakeholders in turn can use the quality metric to appreciate the results achieved or send them into another loop for improvement. Thus, the loop from the requirement through the epic, story and implemented result is closed.
All parties involved in the agile way of working now have the chance to do the work well and the stakeholders to get what they need. The quality process is thus self-organizing and ensures a functioning cooperation and an appreciative approach.
People can achieve better mutual understanding, work more closely together and give each other a chance to do well.
Digitized services for the quality process
Are you forced to work remotely or do you want to have everyone in the team speak at the same time with automatic documentation?
Remote DecisionMaker can be used to map the quality process as well as the prioritization and commitment process. More mature agile teams implement the quality metrics in the backlog system and integrate the digitized DecisionMaker in all agile ceremonies.
How to fail
The poor quality of the stories, along with the lack of commitment and inappropriate process fidelity in agile methods, are among the dominant factors in the failure of agile projects: “Research shows that 70% of complex, large-scale agile change programs do not reach their stated goals. (IBM 2013, 2015, Forbes 2018, Standish Group 2019 with 84%).
Success Story – Velocity from 3 to 30
A reference project was started with a classical project approach and was about to fail with a subsequently measured velocity of 3 after 12 months. DecisionMaking and Scrum were introduced as remedial measures. Even though or perhaps due to the fact that the team was forced to remotely collaborate, the quality process took effect immediately after the introduction of agile way of working.
The agile transformation took 3 months and after 6 sprints a stable velocity was reached. The DevPos project was successfully completed after 16 months.
Now it is your turn
Now take another step towards the agile way of working. Introduce the KiE Quality Process to your team and experience how the secure process increases the quality of the stories and your chances of doing well.
You will develop a common understanding and grow together as a team across disciplines.
We will gladly support you in this process.
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 projects.” Richard Graf
Sources
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.