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
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.
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.
