Where to start?
That’s a hard question to answer in a digital environment with accelerated competition and a low predictability. There are so many possibilities between UX, Agile, Lean, DevOps or SRE practices that we can end up paralysed.
One thing we know is that Quality at Speed software is necessary for survival, requiring to:
- Discover valuable user experience with minimal effort & commitment;
- Implement fast minimal software that can scale later with minimal rework;
- Set foundations we can capitalize on to accelerate our iteration cycles.
Quality Engineering helps us select the most valuable practices by constraining the entire software lifecycle to continuous value delivery. Its implementation relies on the five domains of MAMOS: Methods, Architecture, Management & culture, Organization, Skills.
This article focuses on the methods required to start with Quality at Speed software. It is much different from my previous article on Quality Engineering Methods where I mention more methodologies, and with a step should not have mixed with change management.
Follow the QE Unit for more exclusive Quality Engineering from the community.
OKR, DoD, DoR: Give a clear direction and align expectations
First things first, Quality at Speed software requires to have clear objectives and milestones to focus the team on what matters. Their effectiveness then depends on the clarity of roles on a commonly agreed list of tasks that constitute valuable software.
OKRs (Objectives Key Results) clarify what matters. It is a methodology from Agile referential requiring to define concrete results that together realize an objective. OKRs have to be inspiring to all team members, time-boxed, ambitious yet realistic to achieve.
The DoD (Definition of Done) and DoR (Definition of Ready) make software deliverables crystal clear for the different actors. They require defining a checklist per type of deliverable that the team can then rely on during the implementation to maximize Quality and Speed.
The absence of these methods leads to a lack of focus and clarity between team members resulting in a waste of local optimisations, multiple reworks, and frustration. Even software with good coding standards is useless if there are no users finding value in it.
Design Thinking: Prototype a Proof Of Value on personas
Delivering a valuable user experience is the result of fast experiments with minimal effort and commitment. And the level of competition with limited demand forces to provide the best solution to a specific problem an audience is ready to pay for.
Design Thinking is a methodology focusing on discovering the valuable elements considered by potential users. It relies on rapid iterations of value-hypothesis techniques to find the solution to the identified problem, resulting in a POV (Proof of Value).
Personas define digital audiences that are interested by the solution offered. The segmentation of users in different personas identifies their key differences to better address their needs—product offering, customer journeys, after sales can be tailored per persona.
Bypassing the use of Design Thinking methods create teams that work business as usual and that gradually become more auto-centered. Instead of increasing the value delivered for existing and new personas. Their users quickly switch to Quality at Speed competitors.
Kanban: The light way to build and deliver software in just-in-time
Starting with an Agile framework sounds like a good idea. But capturing value from an Agile methodology requires time and stability. For example, Scrum rituals take time to implement and to get a good visibility on the team’s velocity. You need to go faster when starting.
Kanban is an efficient and lightweight method to work in just-in-time. The most valuable elements are the first to be worked on, with a work-in-progress limited by the actual capacity of the team, without much upfront planning or forecasting. A possible variant is Scrumban.
The previously shared methods of OKR, DoD, and DoR are equally compatible for Kanban and Agile frameworks. Each item of the backlog must be tied to an OKR with explicit expectations to consider the task “Done” and “Ready”.
Kanban is much simpler to deploy for teams and individuals. You don’t have to implement a whole set of rituals or compute a velocity to plan better sprints. Delivering what is expected as fast as possible is what matters, in our case that is Quality at Speed software.
Craft governance: Use peer reviews for more quality and less rework
The immateriality and subjectivity of software make it difficult to align the same vision among team members. A simple and effective way to improve the software process for Quality at Speed is by implementing systematic reviews along its lifecycle.
Critical checkpoints on the software lifecycle from idea to delivery can be supported by a review process:
- Priority review will verify the pertinence of a task in regards to the OKR;
- Requirements review can help discover forgotten points like accessibility or privacy;
- Architecture review enable to step back on the big picture and long-term goals;
- QA plan review enables to align stakeholders on the testing scope and priorities;
- Code review enables to refactor or improve code earlier and at lower cost;
- Production-ready review checks that minimal go live requirements are met.
Performing a systematic review at each step is an investment to check the Quality requirements that will minimize useless rework afterwards. It is a combination of shift-left and shift-right along the software lifecycle, illustrating the end-to-end view of QE.
A pragmatic way to implement such reviews is to embed them directly inside the DoD and DoR at the right place. The priority of their implementation can be in the listed order, starting as early as possible in the software delivery lifecycle. And what about testing?
Agile testing: Leverage quadrants for select the adequate technique
Testing merits a dedicated focus in itself. The activity tends to be mixed with quality and viewed as a secondary technique to perform once the development if one—if done at all—or a matter of automating a series of use-cases. It’s much different, and can help to accelerate.
Agile testing is a methodology brough by Lisa Crispin and Janet Grégory, applying the Agile mindset to testing activities. It mainly relies on using the Agile Testing Quadrants to define the mix of testing required between different quadrants and perspectives of the product.
Defining the priority of the testing effort requires an alignment on the product’s OKRs and the personas requirements. If the product needs to cope with variable workloads, you better plan to perform spike testing in the performance test category, enriching the DoD & DoR.
Testing is a balance between value, risk and confidence. Not performing any time will lead to regular bugs and costly reworks; and to the contrary, too much testing on non-required testing is a waste of effort that will not bring value, not reduce any risks or improve confidence.
The Quality Engineering methods, one part of the equation
These methodologies are fast to implement and enable the team to focus on what matters with minimal effort and commitment. They are all an investment in your Quality Engineering ecosystem as you can develop them afterwards, without wasting your initial efforts.
Some methods may raise the question of adding automation in the process. For example, why not perform automated functional testing in the software pipeline with Quality Gates? That’s a valid point, requiring first presence of CI/CD pipelines.
The domain of Architecture will provide these automation capabilities, as well as scalability as your objective is to expand your business with Quality at Speed software. Like the methodologies, fundamental architecture elements of Quality Engineering are necessary.
Next articles will share how to start with the other domains of MAMOS. Until then, the respective contributions to Quality and Speed for methods are now available on the ebook On Defining Quality Engineering: Thrive your business with Quality at Speed software.
Ready to start with the Quality Engineering methods?