A Quality Approach to Engineering

Call: +44 (0)23 8098 8890
E-mail:

Posted 24th August 2018, By Ross L

Introduction

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.

Conclusion

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.

References

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

Ross

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

Latest Blog Posts

Partial team photo summer 2018
Posted 7th September 2018, By Jon O
Claudine was one of our interns this summer. Having had an enjoyable experience she captured a summary of her time at ITDev and agreed we could share it. Here' ...more
Posted 24th August 2018, By Ross L
This blog describes how ITDev have solved the complex problem of keeping their development team right up-to-date with (ever improving) development processes ...more
Posted 27th July 2018, By Steven S
We often work on client projects that use the Linux operating system (OS), either as a desktop operating system or on their embedded system. The core of the ...more
Balancing the benefits of contractors vs consultants
Posted 19th June 2018, By Jon O
Recently I was in discussion with a potential client about the challenges he was having with resourcing one of his projects. His automatic assumption was to ...more

Latest News

IBC 2017 Registration queue
Posted 10th September 2018
The Broadcast and Pro-AV industries are key markets for us and some of our clients. In recognition of this we plan attendance at key industry events like ISE ( ...more
Welcome meal photo
Posted 7th August 2018
As mentioned in our last news item, we have 3 summer interns working with us for 10 weeks over the summer. We combined a celebration of their joining the team ...more
Posted 13th July 2018
With our success in recruiting two graduates already this summer and the imminent arrival of 3 summer interns, we've had to make some rearrangements in the ...more
Posted 15th June 2018
Demonstrating our commitment to providing opportunities for growth and responsibility, and to meet with Health & Safety requirements, two staff have the ...more