A Quality Approach to Engineering

Call: +44 (0)23 8098 8890

Posted 24th August 2018, By Ross L


Agile methodologies encourage the tailoring of development behaviours and processes to suit the needs of the team to deliver work more effectively[1]. Updates can present process flow discrepancies when trying to integrate into established engineering processes. It’s of limited value to have well documented processes if improvements are difficult to integrate causing confusion amongst the team. The goal is to have a system where process improvements can be introduced with zero discrepancy or interpretation issues with an established engineering workflow.

This blog describes how ITDev have solved the complex problem of keeping their development team right up-to-date with (ever improving) development processes when using Agile methodologies.

The Decoupled Quality Management System

It’s common for businesses to define and use some sort of Quality Management System (QMS). These systems help businesses be consistent with their approach to tasks, ensuring the output deliverable is to an appropriate level of quality.

For businesses with an engineering workforce, a set of engineering processes and procedures may form part of the QMS. Typically, these documents are stored on a server, and made available to developers via some sort of interface or portal. The trouble with this approach is that they are separated from the day-to-day engineering tasks that are performed by the developers and could be overlooked or misinterpreted, especially if changes are made. Of course, links can be added to the QMS, but they are decoupled from the actual day-to-day workflow.

Ever-Improving Processes

If the processes used in development never changed, an argument could be made that each developer should learn the processes off-by-heart and indeed, in some business situations this is the case. But Agile methodologies promote the use of retrospective meetings to allow the team to reflect and make changes to the way development occurs. These regular reviews of the way engineering is done encourages refinement of the processes used to perform engineering duties. The retrospective requires change in the way engineers go about their day-to-day activities. Processes should be inspected, challenged, and new ways should be found that are more efficient and effective at completing work. Frequent improvements to engineering processes and workflow is normal.

Moreover, if during Agile development the processes are customised or refined, businesses may find themselves in a situation where certain processes in the QMS are superseded with tailored processes from one project to the next. This can leave developers in a confused state, especially if transitioning from one project to the next.

The Human Factor

We’ve established that continuous changes to the development processes can be difficult to keep up with, but there’s another important factor – people. Computers will execute instructions in a predefined order and they do this very well. People on the other hand are not computers and can do whatever they please. Given a decoupled set of tailored processes to follow, before too long, each developer could be doing their own thing in their own way. Within reason, this is to be encouraged. Why should we all use the same editor or development environment? Some prefer Linux, some Windows. Vim, Eclipse or Sublime Text3? But of course, everyone knows that Emacs is best!

There is benefit in following the same way of working in order to align on things that affect other people. For example, the team might agree to use the same tool to conduct code reviews. Otherwise, each developer will need to produce a variety of outputs for each review tool in use (inefficient). Moreover, there are other established processes that make good sense that each developer should follow in a prescribed order.

Even the most experienced engineers can forget things, and so a checklist of items in an ordered list is invaluable to the quality level of a task and therefore a project. Of course, there should always be the reliance on the intelligence of the engineer; no checklist will be able to provide an exhaustive list of quality checks for every possible task or situation [2].

Ticket Customisations

Trac enabled checklist

At ITDev we use Trac [3] for project management and bug tracking. We have developed a plugin to enable the creation of checklists that are easily added to tickets (stories/work items). For example, projects implementing Scrum have checklists for the Definition of Ready and the Definition of Done. These checklists reside at the story level and contain a number of check points so the development team know when a story can be included in a Sprint (played) and when the story is complete. Each checklist item contains a checkbox, description, custom entry textbox, and status text of when an item was completed and by whom. This has helped Sprint success by a) confidence in the readiness of stories to be brought into a sprint planning session, and b) confidence that a story has been fully completed, not just, “I’m Done!” from the developer.

For Kanban projects, the development process can be encoded in the ticket checklist. This checklist is divided into sections, each of which represents a column on the Kanban board. The more sections that are completed, the further across the Kanban board the ticket progresses. The position of a ticket on the Kanban board reflects where the task is in the development process. This is key, because if a developer wants to complete a task, they need to read and implement the next step in the checklist.

Kanban board example

Each project has its own set of checklists, copied from our QMS system, which can be tailored in a controlled way to suit the needs of the project and development team. These tailored checklists are then reviewed during and at the end of each project allowing generic improvements to be fed back into our QMS system. This way, existing and future clients benefit from the experience we gain delivering engineering excellence.



Retrospective Findings

Improvements to the development process identified in retrospective meetings should be actioned immediately by changes to the Kanban checklist. Because the checklist is a direct reflection of the latest development process, no discrepancy exists between the previous and the new process. These changes will automatically be picked-up by the development team for the next iteration.

Likewise with Scrum projects, changes made to the Definition of Ready, Definition of Done or any other customised checklist will be picked up by the development team for the next iteration without the need to remember what improvements were agreed upon.


This blog has described how ITDev have solved the complex problem of keeping their development team right up to date with the (ever  improving) development processes when using Agile methodologies. The development processes are coupled to the ticket workflow, meaning the people working on a ticket are inherently working through the development process. This coupling of process with day-to-day engineering is vital to our pursuit of delivering engineering excellence.


  1. http://agilemanifesto.org/principles.html
  2. http://atulgawande.com/book/the-checklist-manifesto/
  3. https://trac.edgewall.org/


Principal Consultant - Head of Quality Management

BEng - Electronic and Computing Engineering, University of Brighton - MIET

I joined ITDev in the summer of 2013 and I am one of the ITDev principal consultants. I spend a large amount of my time working on client projects using my knowledge and experience of C/C++ in embedded systems. Other technical areas that I work in include scripting and the occasional involvement with VHDL for FPGAs.

One of my keen interests is in the field of modelling using the Unified Modelling Language (UML), which has proven to bring structure and organisation to large scale projects that I have worked on. I used UML extensively during my time working for Philips as part of developing an optical storage data path and at Garmin helping develop the GPSMAP® 8000 glass helm chart plotter.

During my career, I have led and managed several teams. At Garmin, I led a team of 5 software engineers developing a new sonar user experience implementation; at Philips, I led a small team whose responsibility was to produce a slim DVD writer drive; and at NXP, where I was a team leader and principal software engineer responsible for developing and maintaining the final production testing stages for a range of digital TV and set-top box ICs.

I have additionally worked for Xyratex (now Seagate) on a production test platform for their OneStorTM product range.

I am one of ITDev's project managers, looking after various external and internal projects, one of which involves the development and maintenance of company processes and procedures including quality management. I enjoy leading teams and also value ITDev's commitment to Continual Professional Development (CPD) and support this with my coaching and mentoring roles.

There's nothing I enjoy more than spending time with my wife and four children, eating curry and playing the guitar.

View all posts by Ross    |    View all ITDev team members

IET Enterprise Partners logo

Latest Blog Posts

Photo collage of ITDev staff
Posted 13th September 2019, By Orianne T
In follow up to our nomination for "Best Company to Work for" we explore the history behind the company values.
Posted 12th July 2019, By Steven S
Expanding on a previous blog post we now expand on building a kernel for a different architecture, cross-compiling.
Posted 4th March 2019, By Lucas N
Our first CI deployments brought many benefits but we felt that there was still a lot of room for improvement. This blog explores how we addressed these ...more
Image for Time Server blog
Posted 11th January 2019, By James H
Making a Stratum 1 Linux Time Server: Part 3 We have found out in the previous two parts of this series why distributed devices might need a method to ...more

Latest News

Posted 28th June 2019
We've got several 'Reasons to be cheerful' (thank you 'Ian Drury and the Blockheads') here at ITDev. Firstly, we're celebrating two staff milestone ...more
CI Workshop photo collage
Posted 26th March 2019
On 7th March, ITDev brought together peers and associates from over 20 companies to discuss Continuous Integration (CI). As part of the event, we were ...more
ITDev at University of Southampton Careers Fair 2019
Posted 26th February 2019
With available graduate and internship places for this year, ITDev attended the University of Southampton's Engineering and Technology Careers Fair.
Posted 15th February 2019
Following our company tradition, we recently donated the proceeds from our staff-run tuck shop to our nominated charity, Winchester Churches Nightshelter.