Don’t Lose Sight of Agile by Going Agile

Insight Main Image

The following article is a guest post to Zephyr from Rodney West, Senior Consultant and the Editorial Director at Isos Technology. Isos Technology is a partner of Zephyr and is the market leader in solving complex enterprise challenges from Agile adoption and QA to DevOps and they help teams improve quality and speed delivery.

The inclusion of too much process is a common pitfall for Agile. This hazard can strike teams who have been using Agile for a long time as easily as teams new to Agile.

As a software engineer, part of your training is a focus on process. Detailed, repeatable processes are powerful tools for creating and modifying software. They provide blueprints for reaching goals and are excellent starting points for newly onboarded team members. How can they be bad?

Bringing it with you

Here is a metaphor for the role of process in agile. People used to move to Arizona from other parts of the country to get away from their allergies. The flora in Arizona was perfect for allergy sufferers. Unfortunately, many of these people brought the plants they were allergic to with them so that they would feel more at home. As a result, Arizona is no longer a haven for allergy sufferers because of the proliferation of these plants.

Agile is similar to Arizona in this metaphor. In its pristine form, Agile is devoid of the process baggage inherent in other methodologies. However, bringing over processes from other methodologies overburdens Agile teams, decreasing the effectiveness of the Agile approach.

A pinch of salt

I’m not saying all process considerations are bad. Too little process is just as detrimental as too much. A primary benefit of agile development is flexibility. Including too much process decreases flexibility, while too little doesn’t provide a solid foundation. In both cases, teams may end up focusing more on process aspects instead of development tasks. At the end of the day, clients won’t care about how closely you are following a rigorous process if you don’t deliver anything.

So exactly how much process should you include? Unfortunately, there is no hard and fast rule other than “only as much as you need.” It’s like adding salt to a recipe. Add too little salt and your food will taste under-seasoned. Add too much and you will ruin the whole dish. You must carefully balance the included processes, tuning over the course of your project.

Just count the dunes

A general rule I try to follow is limiting the amount of process around my Agile development to the minimum needed for getting tickets to the right people and groups as well as handling high level transitions. Tickets themselves can (and should) contain additional details, but they should be as process light as possible.

Minimizing processes in tickets doesn’t mean different workflows are not used for different types of tasks. QA tasks will have very different workflows from development or documentation tasks. At the planning and overall project tracking level, however, workflows and their associated processes should be abstracted away.

Author Rodney West: Rodney West is a Senior Consultant and the Editorial Director at Isos Technology. He has over 17 years of experience in Software Development, Software Architecture and Technical Leadership in a wide range of industries. His approach to software development focuses on the interaction between corporate culture and development processes in the delivery of software.