loading...

How do you see processes?

agilistandre profile image Andre Rubin ・1 min read

I heard an analogy recently from one of my developers that processes are like walls: you want to work on your code, but there is a wall that prevents you; once you remove the wall, you can get to work faster. However, I deeply disagree with this analogy.

As an Agile Coach and Scrum Master, I value People and Interactions over Processes and Tools. However, it is very clear to me that process and tools can aid software development. For example:

  • Scrum (if implemented correctly (and I agree that that's a big 'if')) can increase the speed at which the dev team delivers value to the end user;
  • Pair programming, although it will slow you down a little (very little), it does generate higher quality code, a shared sense of code ownership (increased Bus Factor), and a faster leveling up of devs;
  • Noisli: When I'm in deep-work mode, this app gets me in the flow so much faster;
  • Retrospectives - the ultimate tool for a team to solve their own problems, for developers to build their dream work environment!

I could keep going on and on about this.

So what are your opinions on this? Are processes a wall for you? Or are they helpful? Can we bridge the gap between devs that think processes are walls and devs that don't?

Discussion

pic
Editor guide
Collapse
xngwng profile image
Xing Wang

Too much of it, process will be like a wall and block your progress. Too little of it, process will be like a ledge that you'll trip over and fall down the stairs/cliff. The right amount of process is like railings, it can guide you and help you go up further more safely.

The bigger the team/complex the project, the more process you'll need.

Collapse
agilistandre profile image
Andre Rubin Author

I totally agree. Would love to hear other opinions on this as well.

Collapse
bertilmuth profile image
Bertil Muth

Processes optimize the efficiency of repetitive work. E.g. reinventing a new way to apply
for vacation every time somebody applies is inefficient.
Problems occur when you try to apply processes to creative work, which by its nature isn’t repetitive.

Scrum is iterative, and iterations are about working on the same subject again. So in my view (as a Scrum Master), it makes sense to have a process for the repetitive parts (a.k.a. the events). But you need to make sure that there is enough space for creativity, and that space isn’t taken away by repetitive tasks (e.g. frequent company meetings)