On design process

After publishing the article Redesign process of JankoAtWarpSpeed, I was criticized by some people that I used Scrum "improperly". This related to uneven iterations, non adequate documentation and the fact that I was alone in the project. All of these claims are accurate. But I didn't use Scrum. It was rather an iterative design combined with some Scrum techniques and artifacts. Honestly, I don't believe that there is a proper way to use a process and that one process (or, more formal - a methodology) can be used in all situations.

So what I did was that I chose techniques that were appropriate for that project. Iterations allowed me to have testable prototypes and feedbacks, despite the fact that they didn't last for 2-4 weeks as it is defined by Scrum. Lightweight documentation (such as user stories) helped me save time and stay focused. Product backlog was a nice tool to keep the project under control since I was able to work only when I had some free time.

Formal methodology or process in this case would probably contribute to a never ending project. Although this was a personal project, this can be applied to any project you normally do for your customers. Each one is different and carries its own constraints and uncertainty. Sometimes the problem is tight deadline. Sometimes it's resources. And sometimes it could be the scope. Therefore designers should be able to adapt their processes to circumstances on each particular project.

The problem is present in large teams also. Teams often have their own processes or apply some of known methodologies, and they stick to them regardless of circumstances (of course, some practice only ad-hoc approach which is nonsense on its own). It is not rare that teams adopt a process after successful completion of a project. This becomes their one-size-fits-all processes. It is also not rare to see that methodology turns into a pure bureaucracy. Seems as if some companies adore ginormous, heavyweight methodologies.

If we say that a process is a set of steps and rules that we take to accomplish our goals, it becomes clear that these steps can't be used always and in every situation. Following steps of some process really doesn't guarantee success. It only guarantees that you will follow the steps. And, very likely, not repeating previous success using the same steps.

In his speech from 2008, Journey to the center of design Jared Spool compares process with methodology and eventually a dogma. But he also emphasizes the importance of tricks and techniques, or toolbox of each team member. The success of efficient teams (and individuals) is in knowing the wide range of techniques that can be used in different situations.

For the end I would quote Joshua Porter (taken from the article The Process Police)

No process guarantees success. If there were a process that guaranteed happy users everyone would be using it. But design doesn’t work like that: it’s iterative, responsive, ever-changing. You have to react as much as plan. You have to change your process on the fly to react to the marketplace. That’s why we need to optimize for what’s most important, a happy user, and do whatever it takes to make it happen, process be damned.

My dear Scrum fanatics, Scrum is not always the answer.