In my work as a consultant, I often deal with “processes”. The people I talk with use different definitions of what a process is. That often hampers discussions about processes, and makes it very tedious to come to agreements about how to improve processes.
My definition of a process is “the way we do things around here”. It can be documented, e.g. in a process description or a quality system. But it can also be something that professionals do, simply because they have had similar training. Or what they have learned from experience, by frequently evaluating they way they work and look for improvements. A team may agree to do things in a certain way, based upon shared beliefs. So in my opinion a process is what people actually do. That can differ from what they say they do, or from what is documented. For me it is the actual behavior that counts!
It’s not the process that changes, it’s the people
Why do I use this definition? Because the only way to change the results that an organization delivers is by changing the behavior of the professionals that are involved. Writing a new process document or changing an existing one doesn’t automatically result in changes, because a document is not a process. It is what people do that counts.
Calling it “the way we do things around here” doesn’t mean that things should stay like this. “This is the way we do it” is not a process, it’s denial, an excuse for not willing to change things. If the way things are done isn’t effective, if it causes software to be delivered late, with insufficient quality, then things must change. My opinion is that change always starts from how people are working right now, and not from how it is written down in a document.
Do you have processes in agile? Of course! As a agile team you agreed to work in a certain way, which is your process. Every sprint you discuss how you will deliver the user stories, which is also a process step. And you continuously improve the way of working with retrospectives. Most agile teams use a Definition of Done, which I consider to be a process definition, written by the team itself. Agile teams have shown to be a great way to deliver high quality software products. So yes, there are processes in agile, and agile actually has some process management build in. Also the newest CMMI V1.3 recognizes Agile, and Agile processes, so you can use a combination of CMMI and Agile to improve your business. You can even improve in an agile way, to continuously increase the value that your company delivers to your customers.
I’d like to hear from you: What is your definition of a “process”? How do you use it?
(This blog was posted aug 14, 2010, and updated aug 17, 2011: Added Agile Process Management. Extended on apr 23, 2012 based upon a discussion about following processes).