How to Implement Quality in a Lean-Agile Environment Successfully

How to Implement Quality in a Lean-Agile Environment Successfully

Lean-Agile Environment

Enterprises realize that they can’t use traditional methodologies and expect to keep up with the changing market. The speed at which markets are changing has created the need for a much faster approach. Enterprises must be able to respond continuously and quickly to evolving customer and market demands. With the customer and product quality at the center, companies are looking to reap the benefits of greater performance capabilities and customer satisfaction. The SAFe (Scaled Agile Framework) enables customer-centric enterprises to keep their overall business agility goals aligned with the adopted processes, while delivering continuous value to their end-users.

The foundation of a successful Lean-Agile transformation is building a Lean-Agile environment and having Agile and Lean thinking and a Lean-Agile mindset. Lean Thinking is mainly defined through SAFe’s House of Lean, which was inspired by Lean manufacturing (derived from Toyota’s Houses of Lean). Then, it was applied to software solutions development.

Think big, act small, fail fast, and learn rapidly, but to achieve this, all members of a project must understand Lean thinking before implementing it in a real-life situation. Only when all the Lean-Agile principles are implemented together (and combined with common sense) is there a basis for success.

Scaled Agile Framework helps implement quality, and having built-in quality is one of its core values (as well as a principle of the Agile Manifesto). Built-In Quality principles and practices ensure that each product element (at each one of the program increments) meets specific quality standards throughout the product development cycle. All teams, including hardware, software, security, compliance, legal, product marketing, etc. apply Lean Agile principles and practices and goals of built-in quality. But since work products vary by discipline, their practices will also vary.

Successfully Implementing Quality in a Lean-Agile Environment

Building high-quality requires commitment and ongoing training, but the benefits are worth the investment. The benefits for Lean-Agile leaders include:

  • Improved ability for scaling, innovation, and planning, as well as meeting compliance requirements
  • Improved delivery predictability and velocity
  • Higher customer satisfaction and respect for people
  • Better system performance

Here, we will discuss the five main aspects of successfully implementing quality in a Lean-Agile environment, which business-focused teams can use as a reference when applying built-in quality principles and practices to their products. Typically, there are 5-10 teams working in a scaled Agile environment. Each of the teams has a product owner, Scrum master, and a team of developers. The product owner is responsible for the product delivery, defines the vision of what needs to be built, and conveys the vision to the team and the enterprise.

1. Test-First and Continuous Delivery Pipeline for Achieving Flow

Lean Agile teams work in a flow-based and fast system to quickly develop and release high-quality solutions. Instead of doing most of their testing at the end of the product development cycle, they perform many tests early-on and at multiple levels. These tests are defined for code changes using TDD (Test-Driven Development). Feature, Story, and Capability acceptance criteria use BDD (Behavior-Driven Development). And Feature benefit hypothesis uses Lean-UX.

Think test-first

Agile teams perform tests for everything at the same time or before the item is created. They always test first. Test-first applies to both non-functional requirements (NFR) and functional requirements (Feature and Stories) for reliability, performance, and product development process. Teams strive to automate the tests in order to run them quickly. Many enterprises’ testing portfolios are unbalanced with too many expensive, slow, and large tests.

Accelerate feedback with reduced test suites

Development teams experience delays as tests grow over time, so complete test suites may take a lot of time to set up and execute. Therefore, teams should create reduced test suits to perform tests and ensure essential functionalities before moving through other stages.

Build a continuous delivery pipeline

All the built-in quality practices contribute to creating a Continuous Delivery Pipeline and the enterprise’s ability to release on demand. Before arriving in production, changes that are built into components are tested across multiple environments.

2. Architecture and Design Quality

What ultimately determines how a system can support business needs (current and future ones) is its architecture and design.

Support future business needs

Architectures and designs must evolve as requirements evolve based on development discoveries, market changes, and other reasons. Traditional processes cause inefficiencies because they force early decisions that can result in suboptimal choices. As a result, the inefficiencies can slow down the work and/or lead to later rework. To identify the best decision, one must gain knowledge through prototyping, simulation, modeling, and experimentation. Also, enterprises can evaluate multiple alternatives thanks to a Set-Based Design approach. Once it is determined, the final decision can be implemented by using the Architectural Runway.

Ease testing

Design and architecture determine a system’s testability. All the modular components of the system communicate via well-defined interfaces and create seams that allow developers and testers to replace slow or expensive components with test doubles. Replacing such complexities with test doubles decreases the effort and time to develop and test any component.

Designing for quality

The system design must evolve to support the evolving system requirements. If you end up with a low-quality design, it will be difficult to modify or even understand. Typically, low-quality design with more defects comes as a result of slow delivery. Applying appropriate abstraction/encapsulation and coupling/cohesion make system implementations flexible enough that they can support new requirements more easily.

3. Achieving Code, System, and Release Quality

Code Quality

The code of a system ultimately executes all system capabilities. The ease and speed to add new capabilities depend on how reliably and quickly developers can modify it. There are several principles and practices to rely on in order to achieve code quality:

  • Test-driven development and unit testing

When it comes to the unit testing practice, it involves breaking the system’s code into parts and making sure that each part has automated tests to exercise it. Unit tests run automatically after each change, allowing developers to make fast changes and be confident that the applied modification will not break or interfere with another part of the system.

Also, every test stands as documentation and is an executable example of interaction with a component’s interface, showing how that particular component should be utilized. TDD (Test-Driven Development) is used as a guide for the creation of unit tests – before creating a test, TDD specifies the test for a change. That forces system developers to think about the problem more broadly, including the boundary conditions and edge cases before implementation.

  • Collective ownership and coding standards

Collective ownership means that the code is now owned by one individual or team, which means that coding standards encourage consistency by having everyone understand and maintain each component’s quality. Furthermore, collective ownership helps reduce dependencies between teams, ensuring that each Agile team or developer won’t block the fast flow and deliver value.

  • Pair work

Pair programming refers to having two developers working at the same workstation and on the same change. One developer writes the code while the other is the navigator who provides real-time feedback and review (and they frequently switch roles). Pairing helps create and maintain code quality because the code will contain shared perspectives, best practices, and knowledge from each member. As teammates learn from each other, it broadens and raises the skillset of the entire team.

System quality

Design and code quality ensure that system components can be easily changed and understood, while system quality confirms that everyone is aligned on what changes to make and that the system operates as expected. To achieve system quality, developers and teams need to:

  • Create alignment

Creating alignment is necessary for achieving a fast, continuous flow. Along with shared understanding, developer rework and delays are reduced, which enables fast flow. BDD (Behavior-Driven Development) defines a collaborative practice where the team members and product owner agree on the specific behavior for a feature or story. Thanks to BDD, developers can build the right behavior the first time, avoiding errors and unnecessary rework. MBSE (Model-Based Systems Engineering) scales the alignment to the entire system, and through a synthesis and business analysis process, it provides a complete view of all the proposed functionality for the system (and how the design realizes it).

Agile itself is not a business analysis process. However, Agile teams need business analysts to discover what the end-users need and what changes will have the most value to the business. They are there to collaborate with business sponsors and users and ensure that the parts of working software delivered are going to deliver value in the context of the end-to-end business process. Ultimately, business analysis (and analysts) is required for keeping the team backlog well-organized.

  • Continuously integrate the end-to-end solution

Continuous integration and deployment provide developers with quick when responding to change and feedback. Many engineers continuously make small changes that must be regularly checked for errors and conflicts. Each of the changes is quickly built, integrated, and tested at multiple levels. Continuous Integration/Continuous Development (CI/CD) automates the process in order to move the changes across all development stages, and if a test fails, it knows how to respond. CI/CD strives to automate all tests, but some usability and exploratory tests can only be done manually.

Release quality

The business can measure the effectiveness of a feature’s benefit hypothesis through releasing – the faster an enterprise releases, the faster it learns, and the more value it can deliver. Thanks to modular architectures, smaller changes can be released independently. These component-level changes allow less risky, more frequent, and faster releases. But to ensure quality, these changes require an automated pipeline. This type of infrastructure doesn’t allow changes to be performed manually and directly to production servers but only to server images. After they are validated, changes are launched to replace the running servers. This is an approach that creates more predictable and consistent releases, while also allowing for automated recovery. In case of a production error, the system can roll back the release by launching the previous working image.

  • Supporting compliance

Releasing has some additional conditions for systems that must show objective evidence for audit or compliance. Lean QMS (Quality Management System) defines approved procedures, policies, and practices that support a Lean-Agile continuous process of integrating, deploying, and releasing.

  • Scalable Definition of Done

The Definition of Done is probably the most important way of ensuring that the increment of value is complete. To ensure that the right work is performed at the right time, the continuous development of incremental system functionality needs a scaled definition of done. Each enterprise, train, and team should build their own definition, and while they may be different for each team, they typically share a core set of prerequisites.

Thinking Lean and applying Agile principles successfully require an utmost respect for people and culture, achieving and maintaining continuous flow, and innovation. Respect for people and culture is among the basic human needs and it should extend to relationships with customers, partners, suppliers, and the broader community. Establishing a continuous flow of incremental value delivery needs to be based on continuous feedback and adjustment. Continuous flow is an enabler of effective built-in practices, faster value delivery, evidence-based governance, and constant improvement.

But continuous flow only creates a strong foundation for value delivery – without innovation and planning, both the process and product will be on the path of steady decline. To enable purposeful innovation, you should provide enough space and time for people to be creative. That can rarely happen in the presence of 100% utilization and daily tasks. One such opportunity is SAFe’s Innovation and Planning iteration.

The SAFe journey begins with education and corporate training. The place to start is the i4 Group – a transformation consulting and training firm. Sign up your leadership stakeholders and core change agents to be trained in SAFe and the concepts it is based on. Once they’ve been trained and understand the journey, they will be able to work with experts and design a transformation roadmap for the Lean enterprise.