Agile Zone is brought to you in partnership with:

Michael is a founder of TargetProcess (agile project management software). His Mission is to provide solutions to real problems in agile projects. He wrote several books about web development and many articles related to almost all aspects of software development. Michael is a DZone MVB and is not an employee of DZone and has posted 48 posts at DZone. You can read more from them at their website. View Full User Profile

Agile + UX

03.01.2010
| 1434 views |
  • submit to reddit

Kai Gilb started a series of posts that challenge Agile Software Development. Part 2 is about creativity and “how well” focus in software development. While I agree with the problem, I strongly disagree with the solution. Kai recommends to write requirements (the format he uses doesn’t allow me to call it “user stories”) in a form that does not contain solution:

As a buyer, I want to place a book in the shopping cart vs. It is required that a buyer, by next Feb, can complete a book order of three books, in 1 min.
If by next Feb. it takes more than 6 min., this project is a complete disaster.
On the website it is replacing, it takes 10 min.
Our main competitor has a system, where it takes 7 min.
And after last sprint (if Scrum) we measured our latest version to 6 min.

Developers Are Not Product Owners

Then developers should creatively find the ways to implement this requirement, to invent the solution and to solve the “how well” puzzle. We’ve got a huge problem here indeed. Most developers can’t invent solutions at this high level. They can create beautiful architecture and build the quality in. They can write tests upfront and use powerful tools to speed up development. They can do many things, but often they can’t invent a “how well” solution that will make customers happy. Why?

1. Most developers know nothing about User Experience (and don’t care).
2. Most developers can’t create usable design.
3. Many developers barely know a problem domain and in any case don’t want to dig into much details here.

In short, most developers are engineers (so far?), so what Kai proposes will not help. It is just a theoretical solution to “how well” problem. It’s the same like trying to grow 4 hands and 2 heads to double your productivity (well, sacrificing beauty maybe…)

In Scrum Product Owner is responsible for writing User Stories. It means he should invent solutions and care about “how well” thing.  I don’t see a significant problem here. Of course, it’s great if developers are interested in requirements handling and solutions investigation process, but if they are not, Product Owner can do that alone or with special people who care. Who they can be?

Those people are UX specialists. They know how to solve “how well” problems effectively. They know many things about design patterns and all new trends in interfaces. They like to explore problem domain and talk to customers. If you have such people among developers — you are SO lucky! But often this is not the case.

We, at TargetProcess, try to instill UX culture into development process. We started in August, now it’s February and I can’t say we’ve had much success. Sure there are significant improvements, but to be honest most developers are not so interested in UX staff, they like BDD, DDD, C# and SOA more. I expect it will be a long process that will take years. And our company is quite small. I can’t even imagine an effort for such a radical shift in a huge company.

Broad Requirements Are Not Testable

I wonder how you can write BDD scenarios for broad requirements as Kai suggests. How the hell can you test anything, if you don’t have any clue on how it should work? So broad requirements can’t replace user stories obviously. They can live in backlog, but developers should deal with concrete requirements that are testable right away.

I can agree that you can split backlog in 2 parts. The first small part contains detailed stories that can be put to development asap. The second large part contains broad requirements without solutions. That might be a good idea. But we should clearly separate UX phase and Development phase. During UX phase we should solve “how well/how cool” problems, and during development phase we should solve technical problems only (with some corrections in “how well” for sure if required).

P.S. Kai, I hate gray text on gray background in your blog. It is not user friendly.

 

References
Published at DZone with permission of Michael Dubakov, author and DZone MVB. (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

Ruby On Rails replied on Thu, 2010/03/04 - 4:35am

Agile + UX  hey is wonderfull combation people would lyk to knw it. mostly Ruby on rails developer

Sindy Loreal replied on Sat, 2012/02/25 - 10:00am

I am under the impession that Agile relinquishes the idealism of specialized roles? By honing into such an new role we begin dividing the responsibilities of the team members and are now creating more dependencies? This will leads back towards waterfall projects as we wait for their work.

Comment viewing options

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