I think a lot of people and teams get hung up on the UX done side of a story. They need to focus more on done “right.”

Thanks for taking the time to comment!

Where I am working now, we are really having an issue with moving the UX team to agile, and its really slowing things up.

One approach were thinking about is to have the UX team front load, so they build up assets that the rest of the team can then get on and build.

I have a fundamental issue with this approach in that it fosters and split team attitude (still them and us) and this is not good long term.

I like Urs approach from identifying the technical limitations and take the decisions and approachs that frees the team up to do it properly.

Properly for me is that the team is capable of taking the User Story to Done.
so.. UX,Design,Dev,Test and Release.

Cheers

We do this for every aspect (UI, DB, …) in our project just as Jeff wrote above. We call these people or groups “consultants” to our core team. These consultans can come from within our company or from the customer or are hired externally.

In reply to UI vs. functional features:
We use a design similar to MVC/MVP (Passive View Command: see http://www.planetgeek.ch/2009/04/08/passive-view-command-pvc-pattern/ for a short description) to separate UI (the look and feel) from the logic (user interface logic, business logic, …)
This pattern allows us to have very little blocking issues between functional and user interface feature development. And we can change the UI (look and feel) very quickly without breaking the logic behind it. Furthermore, we can build real functioning skeletons (something like a prototype) to give our customers something to click on. This skeleton consists of the real View and Presenter, but fake Commands and Model.

1. I think FDD better fits contract based development then either XP, or SCRUM. “Contract based” usually means fixed price, fixed time and sometimes means strong customer control (especially in govermantal projects). I’ve found XP, SCRUM to be “too agile” for this type of projects. Meanwhile FDD has techniques to reduce risk in such situations(see [1]).

2. Experts say that FDD can deal with varying skill levels and can scale up. Meanwhile XP is targeting mainly seniors, and is designed to work with 2-10 programmers (see [2]). I agree with this opinion:) Namely I cannot imagine a large XP team, where senior programmers works with lower skilled ones and meanwhile the team aligns with the “Collective Ownership” principle.

3. Also note that in usual projects “mixing skill levels” means a more economic/cheerful approach then working with just seniors – since tasks are at different difficulty levels in usual projects. It would be a very expensive approach assigning senior developers to easy tasks. Also senior programmers would quickly quit in such a situation…

4. Most of the projects that I participated in involved new technologies that had been never seen before by the development team. At this point I think FDD lacks any support – thus I would say FDD (without extending it) is better suited for projects where only proven technologies applied. Meanwhile XP has technique for such a situation (eg. spikes).

But this is just my opinion, and again I could be wrong:)

Refs:
[1] http://www.featuredrivendevelopment.com/node/527

[2] http://edn.embarcadero.com/article/29684

Also how would you rate FDD as opposed to other Agile Development models?

I’m assuming you gather the features (user stories) from your customers. Do you have a proxy to the customers or is it direct interaction?

Side Note: Anyone have trouble with the comment system showing up when you are a registered user, or when you are logged out. I have a feeling there is a bug I’m trying to stamp out.

1st step: Capture user requirements; define funtions/features; design the shape model (containing both data and UI elements, and whatever layer the application has).

2nd step: Roll out an application framework early targeting basic application elements, including both server side and client side (eg. UI) logic.

3rd step: Go on and produce the software in an iterative manner. In every ~4 week iteration: design the detailed model, implement and hopefuly test it:) At the end of the (2-3 month) milestones deploy it:)

In this approach the UI expert is responsible for the basic UI features: produces/documents basic page templates, stylesheets, widgets, etc. This work is done mainly in the 2nd step, then he switches to ’support mode’.

The specific applicaton functions (including both view, and controler logic) are done in the 3rd step: planned/coded by application designers/developers. The UI expert only assists it.

Ps.: I said we tried to follow FDD, since sometimes the customer wants something else. Sometime he wants waterfall:( And after all he is the customer.

From my first reading of Kent Beck’s XP explained book, I had envisioned his iterative development (in early stages) to mean either or wireframming or HTML prototypes–wiring the back end in later after you had agreed to the scope. We now have such incredible tools to prototype, I don’t see the reason to “sling code” until the interface is defined.

The tangential benefit–from my perspective–is a really solid programmer and problem solver can better define the data set to be captured, present and future, based on the agreed interface.

yes, no?

In my experience application screens, and scenarios can be classified into a small number of basic scrren/scenario types. So right at the begining of the development process, the UI expert designs sample shots covering all typical screens, creates the supporting code (CSS, Javascripts, images, etc.) and documents it through a UI design reference (containing both usage overview, and element specifications).
That is to say the UI expert is responsible both to design for usability, and to create-support-and-maintain the neccessarry UI code.

Excelent:) But do we solve our homework? No.

In my (current project) experience ‘design for usability’ is not the biggest problem. The though problem is ‘functional UI planning’:

How can someone go agile with detailed UI plans? if the customer doesn’t trust in user stories? if he asks for detailed UI plans before we can go into production?

Just as UIDESIGNER says: “I’ve been banging my head against a wall trying to figure this question out for some time now”:)

I push this common language through my workflow process – sketches, mocks, wire frames, and interactive pdf’s and into the actual UI design.

I’m a firm believer in a specialized UI & UX person and a team if necessary.

In regards to the roles a single UX person takes. I think a good UX person is able to understand and weigh simple programmatic problems of implementing complex but easy to use UI in applications.

They need to share the vision with the business units and help them define the “what.” What is the “problem” and ultimately devise UX strategies for arriving at a solution.

I think the development team needs to be aware that the UI needs to be flexible to quickly adapt to change. One big problem is inflexible UI that is too tightly coupled to the code. It can really ruin a UI designer day. I’ve had many of those.

Agile can work with UX. I’ll be talking about this a lot more in several upcoming articles. You have to be more alert and better able to change in the stream rapidly. You have to be able to understand musch more of what the user stories mean (vision, value). You have to be able to understand how to adopt, drive, and illicit changes to happen at all levels of the process. You have to champion the right causes.

In essence this article is a precursor to understanding how to not let the process drive you – In this case Agile, but to drive the process in a way that keeps you more involved at all steps but doesn’t drive you insane.

That’s a good segway into the next article I’ll be publishing in a week or two.

Thanks for the feedback!