QA TESTING: Jeff states that, “they employ automated testing to shorten the cost of adding to and changing the software.” MAYBE: QA testing is still plagued by the fact that it is difficult, if not impossible, to test the millions of pathways an end-user may take through an application. If you are automating only a fraction of what is possible, then your testing is still inadequate and you are kidding yourself as to the actual “cost” of testing. Agile may have a number of positive features, but it is not addressing this major QA issue.

COURSE CORRECTIONS: Jeff states, “More frequent feedback and delivery cycles also results in quicker course corrections, which can reduce project risk.” COMMENT: “Course corrections” could involve minor, even cosmetic changes to a GUI. On the other hand, they may cause fundamental changes deep down in the software and cause major redesign, recoding, and retesting. I’d love to see some actual data on various real projects, but it seems to me that course corrections could increase project risk, and the more course corrections there are, the greater the risk.

USABILITY TESTING: Jeff states that, “UX members have less time … to evaluate the product. This means instead of designing and validating a fullsolution before sending it forward to development, the UX team mayonly design and validate just a bit - or design some and only validate the most risky aspects of the design before development. QUESTION: Users want to do real-life tasks, which usually involve many sub-tasks, which may well range into all sorts of odd corners of the application. After doing sub-task 3, say, the user needs to be triggered somehow by the software to do sub-task 4; and they also need any pertinent information about doing this sub-task (either text in the GUI, pop-ups, context-specific help, message dialogs, etc.). If they lack either of these items, the risk of them not being able to complete the overall task increases greatly. If the sofware is released only in incomplete “splinters”, then it will not be possible to complete many real-life tasks. How then is it possible to check for usability, except near the end of the process when most of the GUI is available?

I can see how this could work for very simple web-based applications (e.g., photo sharing) that have only a handful of tasks with a few, obvious sub-tasks, but I don’t see how it can work for applications with any degree of complexity.

CUSTOMER VALIDATION: Jeff states, “I’ve seen environments where a UX team functions in partnership with business analysts under a product manager - all of these folks working together to fill the role of an agile customer. If you’re a UX person, you’re an agile customer. COMMENT: One of the major reasons that applications fail to gain market acceptance is that, for whatever reason, Marketing professionals often seem unable to exactly define what end-users need and will respond to, as compared to what end-users say they want or what the decision-maker (guy with the checkbook) thinks he wants. I don’t see the Agile process dealing with this in any way, especially with UX folk, business analysts, and product managers filling the customer role: They are just going to confirm their own prejudices.

There seem to be many good features in the Agile process: Development teams meeting and talking more frequently, daily standup meetings to keep everyone on the same page, cross-functional teams sitting closely together, minimal documentation, and so on. However, to an outsider, it doesn’t seem to address a number of real issues, as noted above and by the other comments.

My company has also moved into using the Agile approach. It seems to me that this method was developed by Developers, not Designers and without Designers in mind. Quite often Development teams gloss over the design aspect of an application. When I say “design”, that includes requirements, interaction, look-and-feel, etc. I think, and others here have hinted at it as well, that proper application design cannot take place at breakneck speed. As Tai Toh essentially says above, you can’t design part A to fit with part B correctly, if you don’t know what part B is yet….never mind parts C, D and E.

I think Agile is smart and Agile can work but I think there is a fair amount of “design” that has to take place before that first sprint. Perhaps the design team is always at least a sprint ahead of the development team.

I would love to hear more chatter around Agile and the design process.

I work in a product design environment. We have adopted our own specialization of agile development and it actually works well. I am the UX leader and occasionally the software architect, sometimes at the same time.

We begin our product development with a couple of phases of research and investigation before starting actual development. This is to investigate customer needs and profiles and refine the requirements. Once we begin converging on a definition, we begin developing the overall view of the interaction model and the high level software architecture. These are both tested before we begin actual development.

For each iteration, I firm up the design for the areas to be developed in the next iteration, consistent with the overall vision, and assist in developing the current iteration. This is a lot of pressure on me, but so far the results have been good. We do a light round of user testing at the end of each iteration.

For our team, in our environment, doing our products it works. Your mileage may vary.

Ed

Thanks for the response. I think the situation is a little more complicated than as you describe. Contractually speaking, the things we develop can’t be templated and redeployed across multiple clients–it’s the nature of the contracts that my company signs–all custom development with a huge focus on visual design and UX. Granted, technology has become a bit more flexible, but a lot of the requirements are driven by the UI.

Quite simply, we’re so used to designing the UI first. We don’t have that opportunity with Agile. From a coworker:

Which makes me think that Agile is just a substitute for a good design process, and one that costs the client a lot of money in re-working decisions. I’ve been on a couple of agile projects and it’s difficult to design in slices - the user experience is a combination of all elements and you can’t get part A right (or even signed off sometimes) until you know how part B works. I think it’s probably better value to get the entire design right up-front (on paper) and then roll out the development in an agile fashion, refactoring the design as needed based on user/customer feedback and technical discoveries.

Operationally, as a consulting company we struggle with things like staffing shortages, skillset shortages and a turn-over rate (while lower than the industry standard for professional services) that makes knowledge sharing difficult.

We have an Agile process in place that is suppose to be repeatable. Works well with Development, but the Creative Design / UX team has the short end of the stick. It’s hard to slice Design in iterations. It’s even harder to say to a client, “Hi, remember the first 3 iterations, well we made a mistake and have to revisit them all.” This is very hard to do in a “fixed-time, fixed cost” environment. At this point, I don’t know if it is possible.

Add to the fact that some clients are simply not ready for the rigours of Agile Design (e.g., they are not available, they are not engaged)–it gets messy.

-T

Have you tried to offset the initial impact when diving into agile by templating your services and sticking to a basic skeleton of services and products that you already know how much will cost and how long will take to re-implement (since we are talking about templates, after the initial development work, most of the work afterwards will de re-deploying it to different clients). This is the bit you could keep fixed both in time and costs, along with your team’s sanity.

You can create a set of ready-to-use solution(s) that you can offer upfront to clients and go back to the old drawing board whenever any customisation is required.

Going from a documented and risk-averse methodology to an apparently laissez-faire methodology such as agile is a shock to the system. I have heard of people that developed some weird traumas with much less than that :). But in the transition time, you guys might find helpful to have something stable to stick to as a stepping stone to gradually deeper waters.

Cheers!

I’m afraid though that the methods presented don’t really bring to mind the real issues involved here. UX by its nature is not componetizable the way development can be (actually, it has been argued by technology architects that agile doesn’t work for the reasons I’m about to say for design purposes).

Applications are systems. You can research and design pieces, but for more successful design products, you’ll find a more holistic approach to design where total language sets are created and managed and used to narrate a story. In order to do this takes time. Now that isn’t to say that you can’t have development working with design on proofs of concepts and other prototyping of technological needs as they come forward, but this is very different from a production lifecycle.

I find that Agile often puts “expediency” in front of “efficiency” in the way it works at the world. It took a problem, which is development is too slow and quality is too low and tried to fix THAT problem without looking at the total ecolotical effects of fixing that problem. Its like when electrical cables create magnetic waves that throw migratory birds off course and then there is an insect invasion due to lack of birds in the old area.

Design is not about producing things. Design is about conceiving of systems, languages, and then communicating these ideas. This is done through long hours.

Yes, you can discount design techniques, but you get what you pay for.