Rajeev Kumar — Tue, 02 Mar 2010 23:14:32 GMT

Overall, its a good article. It covers most common issues (in the context of user experience) that folks run into when they use Agile. However, based on my experience with Agile, many of the statements seem to be very generalized. Agile is a philosophy and not a “process”. Agile is supported by well thought practices and guidelines that are based on Lean principles. One can apply “Lean thinking” even on your UX design work as well. As a matter of fact my wife who manages finance uses Agile within her team and works well with planning, communication and collaboration. There are good adoption of this philosophy and there are bad adoptions. I liked this blog entry by Steve Yegge – http://steve-yegge.blogspot.com/2006/09/good-agile-bad-ag…. Here he talks about “good” agile and “bad” agile.

I have worked with companies where most of the “cycle time” was spent on defining the product vision and user experience. Even with people working on user research and design for months, there design and ideas were not even close to “Apple”, “Google”, “Amazon” or any other companies that seem to have a good handle on user experience and innovation. There is something to be said about the “people” and culture of those companies. More lead time and more process by themselves do not deliver good design and innovation.

Currently I am in the process of introducing Agile into my current organization. As we go through the Agile transformation (which includes people, process and tools components), I have been asked to define how the “ideation” happens in Agile world, where would user experience fit, how long should we should we be staying in ideation, when do we have good enough UI design to start the development and so on. My answer is that it depends. One thing is for sure that we need to think about overall product vision and overall user experience before burning development hours. How long will you have to stay in I0 or pre I0 depends what you are working on. If you do it right, you are very likely to strike a good balance where designers get enough time to research and design, and are empowered to say NO its not ready when its not good enough. When to say “good enough” is important and who says that its “good enough” is important as well.

Rajeev Kumar — Thu, 04 Feb 2010 19:29:24 GMT

Good points, Chris. Very good suggestion to David’s point. I agree with you 100% that even the best can deliver “average” quality work if they work under bad process/culture/structure.

For figuring out what form of Agile works for the team, my approach so far has been to introduce the smart guys to Agile principles and let them help us figure out the practice details. As a change manager my job is to get them the culture and structure (and other org stuff that they need) to bring the best out of them. Not that i am successful in getting all they want. Agile philosophy doesnt really pays off if the “org and skill stuff” is not aligned. I tried to introduce to Agile at a very large company. The change did not take roots as i couldnt align the “org stuff” with Agile. Sometimes, a well defined gated/heavy process is what works for a company. Not that i want to be a part of that kind of company.

In my current organization, our product delivery cycle looks similar to what Anthony has described as Agile UCD. Thats how our practices evolved. For “good enough” and product backlog prioritization we let the team (include the CX/UX team members) decide what works for them. Our guidelines are to have customer experience/User Experience leads and product managers make the decision together . We run our “delivery” prioritization/planning meetings every other week that takes care of “Agile as we know”. Its not uncommon for us to take stories/epics out the delivey backlog and put into ideation part “research and concept” part aka I0/pre I0. “Dedicated” team can ask questions make suggestions but when it comes to the aspects of user experience, the decision is made by the CX/UX person. There are other reasons why a story can be thrown out of the delivery queue. This works well for us.

For us, Agile works both for new/big ticket items that go through good ideation process and for “lights on” work (that keep the team busy ). Ofcourse, we have longer time in I0 for big ticket items than for enhancments.

On a side note, I kind of understand what Anders says. I dont personally like house analogy when it comes to building software. Its funny that yesterday I had a product manager in my office using the same analogy to talk about what their product ideation cycle should be so much longer than the other products. Not that i knew the right answer on how long it should be..

Boxes and Arrows: Comments by Rajeev Kumar