Business agility is the capability and commitment of an organisation to learn, adapt to, and harness organisational collaboration for the benefit of the customer. It is not simply about changing processes and practices, although these will evolve too.
It emphasises moving outside a traditional IT system, focusing on the customer and continuously asking the question, “is this activity enhancing the customer experience?” If it is not, then it is counterintuitive to its intended purpose and something needs to change.
In many cases, this is easier said than done. However, by harnessing Agile concepts such as “building quality in” and “shift left”, and making the whole team responsible for product quality, it is possible to speed up development and deliver the powerful customer engagement you intended.
Enabling business transformations
Today's organisations are facing numerous challenges in accelerating quality product delivery. Many are turning to enterprise-wide transformations to reclaim or enhance their customer market share.
Agility processes and practices, as well as the all-important change in mindset, are all core to ensuring your transformation succeeds. Not only can these be used as part of the change management process for implementing your transformation roadmap, they are also core to delivering quality at speed.
It is important to break your transformation into small, estimable activities so that you can plan and manage the change successfully. This also provides an opportunity for staff to absorb the new ways of working.
There are three key stages to a transformation:
- Discovery
- Assess your current maturity using a readiness/health check model
- Take key metrics which will be used to measure your transformation success
- Leadership workshops/training
- Create new ways of working. E.g. Agile Operating Model (AOM)
- Pilot
- Pilot selection
- Proof of concept of AOM
- Coaching and training of the team
- Rollout
- Identify Agile champions
- Create roadmap for rollout across all teams
- Training and awareness programme
- Support from coaches as each team adopts the new ways of working
Product quality juxtaposition with speed to market
Maintaining product quality is challenging when there is a drive to deliver faster. Almost half (47%) of companies report that they are adopting Agile in order to improve software quality (13th State of Agile).
However, this is not what is really happening. Organisations may be delivering more rapidly, but their levels of quality are moving in the opposite direction.
One principle of the Agile Manifesto states that, “our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. Thus, Agile teams should always be focused on the customer, and this is even underlined in their use of user stories to capture the requirement.
“User” is the operative word. If the customer is unknown or their needs are not understood, then how can you know that you are building the right product or service for them?
Dev vs Ops: The State of Accountability highlighted several important statistics. Firstly, they found that nearly 40% of respondents said that “moving too quickly” was a primary reason for production defects.
Agile methods emphasise prevention rather than detection. For example, a collaborative technique such as pair programming enables defects to be fixed as soon as it is coded, making it the fastest feedback loop possible.
A quality product starts with quality requirements, with research showing that inaccurate requirements are the third highest cause of project failure (PMI, 2018). Requirement review techniques are essential to building the right product.
This could include the INVEST mnemonic and using checklists in the “Definition of Ready” or “Definition of Done” to ensure that the team completes the quality assurance activities before moving to the next task. Integrated toolsets help with traceability and visibility of features, which allows for collaboration and feedback throughout the development lifecycle.
Secondly, whether intentionally or not, more than half of organisations are still relying on their customers as an alerting system for defects and issues. This highlights the importance of building-in quality and not testing it out.
The earlier in the lifecycle that defects are found, rather than by the client in production, the cheaper (by as much as 1000 times!) they are to fix. Not only is the cost greater by finding defects the further they are away from when they were introduced, but the organisation may face severe brand damage, or worse, loss of life.
There are many Agile practices, such as code reviews, that improve quality quickly, certainly much earlier than traditional methods where testing does not happen until the end of the lifecycle. Adopting some of them are enough to start mitigating many of the above challenges and undesirable outcomes.
Experimentation
Agile methods, such as Scrum, that are empirical enables teams to verify or disprove (find defects) by using observation or experiment.
Business agility includes experimenting and testing hypotheses to ensure the right product can be built from the very beginning. It necessitates employing fast feedback loops to continually refine and improve methods and processes, in turn providing better products to the customers.
It also means that teams should be able to quickly pivot to new business priorities that have higher value, or to terminate a product initiative early in the lifecycle if it does not present forecasted benefits or a return on investment.
One of the ways that teams can ensure that testing is completed within the iteration, and not delay stories being marked as done, is to adopt session-based testing. This uses experience-based techniques to create a plan for the charter (test objective), execution starts, then the tester learns more about the system as they proceed.
The session is then updated with new tests completed, along with any defects discovered. These sessions, once the timebox has expired, are then used to collaborate, and the team decides what is the next priority.
Doing Agile right
Agile has gained a reputation for delivering tangible benefits, and it is a reputation well deserved. After all, Agile delivery are on average 28% more successful than traditional ones.
While this has led to 97% of organisations using Agile methods (13th State of Agile Report), only 11% are getting it right (Scrum.org Scrum Masters Trends report). This figure decreases further when attempted at scale.
The ongoing need for speed can be a constraint in the goal of achieving a sustainable pace. It can also have a negative effect on the happiness and productivity of the teams who contribute to product quality.
It is therefore important that a team is being Agile rather than just doing Agile. Teams simply doing stand-ups, and attending the other ceremonies, does not automatically translate to agility.
The Forrester report, The Definitive Software Quality Metrics for Agile and DevOps, highlights how less than a quarter of firms think that their QA and testing processes address all of business risk in all phases of testing. However, the reality is that most of these same companies have not yet understood the relationship between speed, quality, and risk.
Teams using modern lifecycle practices - such as automated, short release cycles, and testing being conducted by all roles within the team - should, in theory, be both motivated and efficient. However, they are instead experiencing 21% more stress in their work compared to teams using traditional practices (Mabl, 2019) when continuously releasing code.
We would surmise that this statistic, coupled with the Mabl 2019 report, is an indicator of teams not implementing Agile correctly. Thus, it is not good enough to “do Agile” - teams need to “be Agile” in order to succeed.
Many teams believe, mistakenly, that Agile means no longer following processes and practices, or a license to do anything. For example, they may no longer take the time to understand the product risk and use this to drive design, development or testing.
In truth, risk assessment should be conducted during release planning and revisited during each iteration (Sprint) planning meeting. In Agile delivery, risk is made visible and mitigation strategies are discussed regularly as a part of the daily stand-up meeting.
Another myth is that teams do not need to adhere to any standards. Others believe that, if the product is required to follow any industry standards or regulations, they are not candidates for using Agile methodologies for development.
Unless there is a valid reason that says otherwise, good practices are a necessary ingredient of quality engineering. Adhering to coding conventions for automation, ISO standards such as ISO/IEC/IEEE 29119 Software Testing, and industry standards such as W3C, allows for auditability, even in a perceived light-weight methodology such as Agile.
Conclusion
Whether you are at the start of your transformation journey, or in the process of undergoing one, there are some valuable insights in this article about the needs, challenges and activities for well-executed lifecycle practices of business agility. Not only are Agile methodologies critical for continuous quality at speeds demanded by customers, but these practices also form a necessary part of your business transformation roadmap.
Contact us today to find out how we can aid you in delivering quality products as part of your own transformation.