I realize that the term Agile Design refers to a software methodology. I was wondering if there were any methodologies that people use that apply the same kind of thought process to Product Develpment (i.e. a product that has multiple disciplines involved such as electronics).
For example, there is the Core Teams Methodology. But I find that that is limiting. It leaves responsibility in the hands of a single stake holder per discipline. It leaves a lot of room for miscommunication, or even worse, selective communication. Corporations seem to like this kind of methodology, b/c it ultimately leaves a single person culpable for each discipline. As in, one person’s head is on the chopping block, not a team.
I really like the idea of Agile Design and applying it to the process of a multi-disciplinary team. Creating an electronics product is the perfect example of a product I am referring to.
All products have diametrically opposed disciplines fighting each other, but we all have to work together. The more we knock down the walls between the disciplines the better product we get (IMO).
Just to clarify, the essence of Agile or Extreme Programming (XP) is that there’s no way to know what your customers want and changes are inevitable, so engineer your products in a way that allows you to flow in changing requirements as you learn about them. This works by skipping design, and pairing customer-representatives with engineers during the development process, then developing in a highly modularized and “agile” way. Agile was developed and furthered by engineers not used to working with designers (in the software world, this is highly probable.) As a firm believer of “design”, I’m extremely skeptical of Agile and have yet to see it deliver compelling products or user experiences.
Some processes I believe in:
Iterative User Centered Design
Integrated New Product Development
Portfolio Management
Stage gate
Core teams (what’s the alternative?)
Matrix management (functional disciplines assigned to project teams)
Thanks for the clarification on what the core of Agile is. I am, obviously, only familiar with it on the surface.
What I do like about it is the “partner” aspect of it. Or, at least the way it was described to me. Two (or more) programmers working side by side. One on the keyboard while the other designs and noodles over ideas, etc.
I guess what I am trying to get at with this discussion is Design process. I am trying to find an alternative to Core Teams. I find that Core Teams is not really a “team”. Again, I may be missing the full point of Core Teams.
What I have found more often than not is that Core Teams promotes silos. Each discipline defending their ground from opposing positions. Where I feel that true design, and true innovation comes from a quick (agile?) multi-disciplinary team working in the same room with the same goals. Everyone elbow to elbow. It creates an understanding of each other’s disciplinary needs. I have seen it reduce timelines by 35% and increase product efficiency - as you know, CG, efficiency in the wireless handset is paramount.
I’m interested in applying agile techniques to experience or product design. The part that can apply are the short interations to turn out something that is ‘release’-able.
I still have high hopes for using this process. Instead of coding, we would be sketching or building rough physical prototypes.
Jon, I believe Agile Design has a objective of running a project and prototyping quick without the specs fully fleshed out. Then allow during the process, time to make improvement or iterations.
Sound familiar? I had a discussion with a UX designer and according to him this process actually was inspired from ID.
For Core teams methodology, it has its cons, but it has a lot of pros for example leaving the decision to be made by a single individual or a few individuals. You can’t design by committee that’s for sure. For the silo nature of things this is more about managing personalities IMHO. Big companies like it simply because often product development is too big for one person to handle.
I understand the Core Teams all too well. I’ve been entrenched in them and there are some fatal flaws. Your point about the management style is well taken. I suppose Core Teams, is effectively what I am talking about (“no silos”) as long as every discipline is represented at the table.
Where I really see it falling short is in the early stages. What it truly comes down to is the upfront planning of the product. Holding each team member accountable for their actions and everyone being myopically focused on NOT allowing feature creep. When the team “wings it” through the design with a less than complete product spec is when the problems occur.
In other words, figure out what you’re going to sell VERY early in the process and have everyone agree to that. Changes are necessary, but as long as everyone is part of that product specification and configuration process, you will at least have a foundation of understanding at the very beginning.
I can never remember the nomenclature “agile / extreme” programming. Have you seen the two programmers sitting together while one codes and the other watches? It looks weird. The observer isn’t ‘noodling, designing’, they’re watching the coder for real time errors to reduce software bugs. Apparently, software coders despise this process.
I’ve visited lots of large companies, all have some form of the core team methodology, although with various different names. I guess it has a balance of right approach and ease of implementation. A universal aspect is that the core team leaders spend a majority of their time in meetings; perhaps this is one of the core teams’ method goals to free up the engineer doers to do whatever they do.
Also, overall, companies I’ve visited that have a pervasive, corporate-wide committment to any semblance of the core team model have very long project development times but usually less late stage emergencies.