Agile Zone is brought to you in partnership with:

Janko is UI designer, software engineer, blogger, speaker and artist. Janko has posted 20 posts at DZone. You can read more from them at their website. View Full User Profile

On design process

05.06.2010
| 1047 views |
  • submit to reddit

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.

References
Published at DZone with permission of its author, Janko Jovanovic. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Paul Russel replied on Sun, 2012/06/10 - 4:59am

Well, I -do- believe that there is one proper way to use a process.  Failure to use it as designed is no longer that process.

You created your own process that fit your needs better.  It was no longer Scrum.

It's a fine distinction, but an important one.

As for adapting to every project, that works great for very small teams.  For larger teams (meaning 4 or more, in my opinion) then you had best stick to something as best as possible so everyone stays on the same page.  If not, it's "what random change are we doing this week, boss?"

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.