More and more projects are opting to work with SAFe (Scaled Agile Framework), especially in the Finance industry. These projects are often large and complex, necessitating implementation and coaching (change management).
However, when SAFe is implemented, there is a lack of ‘training’ that focuses on quality assurance, despite the significant differences compared to traditional projects. Where SAFe processes are iterative, and the traditionelle projects processes are split into phases.
What is the challenges I see:
In my experience, projects are facing several recurring challenges:
- Test activities are often overlooked during the development process, resulting in delayed feedback. It’s common for projects to form a separate test team to assess features during a later testing phase. However, this approach can lead to late discovery of system failures, which is less than ideal.
- There is a tendency to lose sight of End-to-End (E2E) processes. With tasks primarily described as features or User Stories, there’s a frequent oversight in defining and analyzing complete business workflows, leading to ambiguity in test ownership.
- In SAFe environments, I’ve observed a trend toward having dedicated development teams with only developers, that lack cross-functional capabilities. This separation can lead to the creation of silos and, consequently, significantly delayed feedback loops.
How can your project address these challenges:
It is crucial to define what is necessary to ensure quality, even when implementing new methodologies such as SAFe. I recommend adopting Built-in Quality and a Shift-Left approach to optimize the process. Ensure that agile teams are cross-functional and that End-to-End requirements, including traceability to Features/User Stories, are secured. By doing so, you project can achieve better quality.
Incorporating quality into SAFe processes can indeed be challenging and time-consuming. However, it’s important to recognize that process changes do not have to be costly or drawn-out if approached correctly. By making small, iterative changes, the transition can be more manageable and less expensive. This gradual approach allows for quick wins and the rapid realization of benefits, fostering a more efficient and quality-focused development environment.
Optimising the process:
Implementing a streamlined Software Development Life Cycle (SDLC) may seem simple in theory, but practical application requires a methodical approach. Start by outlining the SDLC for your specific project, from the roadmap to production. The goal is to pinpoint precise stages where feedback loops can validate the product’s alignment with its intended objectives. Understand that each project’s SDLC may differ; this framework serves as a diagnostic tool for quality assurance throughout the project’s lifespan. Tailor this model to your project’s unique needs and maintain regular follow-ups to ensure continual alignment and quality.
An example of a development process with a feedback loop might be:
- Roadmap -> Has the business made its priorities?
- Release Plan -> Is the Backlog up to date and features broken down to releasable products?
- Refinement -> Are Features and User Stories ready for the Sprint (DoR)?
- Development -> Have code reviews, functional tests, and automated regression tests been conducted?
- Demonstration -> Can the User Story be accepted?
- End-to-End -> Can the business flow be accepted?
- Monitoring in Production -> Is the quality as expected (Bugs/Performance)?
Incorporating a Shift-left approach, conduct test analysis during the refinement stage to align development closely with testing. Define Features’ acceptance criteria as comprehensive End-to-End (E2E) test scenarios, and articulate User Stories’ criteria through functional test scenarios. This approach ensures clarity of expectations and confirms that what is delivered matches the agreed-upon requirements. While some projects might utilize Epics or Milestones to track E2E testing, the crucial element is maintaining traceability from these high-level objectives down to the individual User Stories. Ensure E2E test scenarios are clearly identified and outlined early, prior to the commencement of design and development phases.
Describing acceptance criteria as test scenarios often uncovers scenarios that might otherwise be overlooked. However, this approach requires having cross-functional teams
Why does cross-functional teams help with quality:
To receive early feedback, it is crucial that the team possesses the necessary skills to handle the task. For instance, including business users in the team ensures that requirements are aligned with business needs, and having testers ensures a focus on testability. This setup allows the team to identify unclear or non-testable requirements during the Refinement phase.
There has been some confusion about who constitutes a development team. Scrum defines three roles: Product Owner, Scrum Master, and Developers. Does this mean business analysts and testers are not needed? No, in Scrum, ‘Developers’ refers to all professionals required to deliver a complete product. Beyond Refinement, cross-functional teams also facilitate ongoing clarifications, shared understanding, and faster feedback. This includes continuous testing, software demos in the development environment, and collaborative ‘pairing’ between developers and testers.
If you want to learn more or have questions to implementing Quality & Test in SAFe or large projects, then please invite me to coffee.
Next blog; How to implement Shift-left in traditional projects.
