Stop Demonising Process

All too often people appeal to being “Agile” as a way to avoid following or having process. It could be because the term “Agile” implies flexibility or even because the Agile Manifesto itself says explicitly that “Individuals and interactions over processes and tools”. Here, the manifesto doesn’t say that being “Agile” doesn’t mean you don’t have process, it simply says you favour individuals over process. The demonisation of process could also be a knee jerk reaction of when teams had process imposed on them.

Most beginner exercise programs follow a process that leads to linear progression

Process is basically a series of actions that are followed by individuals to meet a particular end. Modern delivery teams shouldn’t avoid process because process allows us to standardise actions that are repeated. This leaves room to maneuver when creativity it needed, unexpected disasters happen, and unplanned work arises. On the other hand unneeded process creates an overhead for team members that limits their ability to be creative, slows them down, and impedes on delivery by making work the process rather than the work being the primary goal being delivered as part of the process. Process also protects team members by ensuring all work is flowing through the standardised practices. This ensures work isn’t pushed to the team, work is completed to the highest quality (rather than being half-done), and ensures things are not forgotten.

We should favour people over process but also have process. Both aren’t mutually exclusive and can exist together. The best process is the process that is derived through team consensus. That is, when the process is defined by the people who will follow that same process. If we have process that is defined through team consensus then we have achieved the ability to favour the person over the process. When process is derived by an external party who imposes the process on people, then we have favoured the process, by virtue of, assuming the process will work without consulting the people it’s being imposed on. In summary, process should serve the individual in a way that allows them to deliver software to end users and not be an impediment to that goal.

Process that is agreed upon by team consensus is more likely to be followed than process imposed on teams. This is another advantage of having processes defined like this. There is a danger though that teams may become overly attached to a process that “has worked” and that they have defined. Teams may then become clouded from better ways of doing things. This is where understanding that processes must improve and change is vital to continuous improvement. Changes to process must be tried, discarding changes without actually trying them will defer improvement to speculation rather than being validated by experimentation.

Processes must change and must be given a chance at the same time. A concrete example is: Trying to reduce length of iteration cycles (to say 1 week) and/or having more aggressive/lower WIP (Work in Progress) limits. Both these changes to process can be difficult to follow. The first, because software may not be delivered in a particular iteration and may impact certain metrics. The second, because by reducing WIP there may be a perception of high slack time. Both changes to process may also raise to the surface issues of work item quality. Having more concise deliverables (requirements, user stories etc) means they are delivered quicker and go out to the customer quicker. However, if the proposed changes to process above are not followed through for a few iterations the problem of work item quality may never actually rise to the surface. As such, if a process change has been agreed upon as a team, it’s important to as a team, try the process change and give it a chance even if it is discomforting at first.

Processes should be in place to support team members and not impact them. By not having process team members may be left vulnerable to external parties. Processes defined and followed by the same people ensure that people are still placed above process and increase the likelihood of them being followed. In order to judge whether new process help or hinder a team. New process should always be given a chance even if it means a slight discomfort initially.