Agile Tuning: Process vs. Practice

On a continuum, you'd have well-defined processes on one end and loosely defined practices on the other end.

Agile has been adopted as the main principle, philosophy and methodology to manage the project and even run the business today. Within the years of experimenting and tuning, it also develops systematic processes and best or next practices, why are they important for the success of Agile and how to leverage them in Agile management?  

Practices are activities, processes are well-defined steps: Practices are activities that are used to manifest or implement Agile principles and values. The specifics are left up to the people who make them work based on their knowledge, skills, etc. As soon as you have more than one practice - and you need to go through a sequence of interdependent steps - you will have a "process." Processes are a series of well-defined steps leading to repeatable, predictable results. All the knowledge necessary to carry out the work is embedded in the process. On a continuum, you'd have well-defined processes on one end and loosely defined practices on the other end.

Processes and practices are a reflection about how the organization thinks about itself: It is a choice to design a process and manage practice so that it supports Agile values and principles. You can have Agile practices adopted in a non-Agile process, and vice versa. Both need to be aligned with agility. Conversely, a process does not exist in the abstract. It needs to be instantiated through a sequence of steps, which are "practices." At the end of the day, process, procedure and practice are all just words in the overall "taxonomy" that describes work, and people often swap them in and out of usage to suit their purpose at the time. As for the idea that agile is a process in its own right. So what's really important is that you have a set of things that enable you to achieve your objectives within your specific environment and, those things are clear, understood and practiced collectively within the internal and external interfaces. And as you go along, you swap out the things that don't work with things that do. Of course, the choice of what practices to adopt, and in what sequence you want them executed, is of great importance.

Mix-match ideas and practices: In development work, it is inherent that there are things we don't know we don't know. In such an environment, so it is important to cover the “why,” before people address the "what" or "how" of practices or processes. Teams should be able to mix and match ideas and practices from various different process to create value driven effective ways of working. Does it matter, which process one follow as long as it is capable of consuming good ideas and is easily adaptable, even if they arise from other processes? The end goal is to produce an effective working software quickly.

The idea of the process is to enable the system. But you should not get obsessed with a process. Agile is not your end goal. Agile should help you to reach your end goal. The moment you see something more useful one should adapt that. Overly rigid processes are seen as a block to innovation or progress rather than a facilitator of it. The best, most relevant and innovative ideas in the world will be completely useless to your business unless they can be implemented to the benefit of your customers in a way they're prepared to pay for them. Integrating valuable ideas into a business is definitely more likely to succeed if a well-understood sequence of practices is followed.

Either processes or practices, they are just set of things that enable you to achieve your objectives within your specific environment and they are well understood. But they are not static, and can be updated in order to adapt to the changes, in order to achieve the ultimate business goals.

Posted in: Agile,Connecting Dots