Show all posts
6 years ago

Agile + UX

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 cartvs.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.

Agile and UX

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.

  • https://www.targetprocess.com/blog Michael Dubakov

    No, Kai, you read it in a wrong way.

    “>> he agrees – developers don't get to be creative in finding solutions to the challenges.”

    Developers are creative with TECHNICAL challenges, and not so creative with UX challenges.

    “>> he does not think they should, the Product Owner does that.
    he does not think that specifying the challenge rather than feeding the solutions is a way forward.”

    Not true. I wish wholeheartedly to have all developers participating in UX phase. However the reality is that they don't care much about design and UX things.

    >>To me, Mr. Dubakov is a “victim” of his culture, the culture I'm addressing and hoping to enlighten a little bit with this blog series.

    Did you read my reply at all? I said we are instilling UX culture in Targetprocess, and I agree that it would be cool to just feed the problems into dev. team and receive packed solutions in several weeks. However it is a complex and slow process. If you have a magic receipt that will change developers attitude, I'd love to have it.

  • Anonymous

    Thought provoking article and fairly decent until the last line…

    You “hate” gray text on a gray background? If you use the word “hate” in this context, what word do you reserve for more egregious actions? I mean, I hate things like murder, lying, divorce, child abuse… that sort of thing.

  • https://www.targetprocess.com/blog Michael Dubakov

    OK, I am not a native speaker, so sometimes use words wrongly :) I read the article, so I did not hate that enough to skip it. The better wording will be “don't like” I assume 😉

  • http://twitter.com/PaulKGoddard Paul Goddard

    The product owner should provide a business problem, and a Scrum development team provide solutions. I would also say that the better Scrum development team I have worked with, have taken pride and care in the UX. You are assuming all developers don't care about UX – but the good ones do. I don't really agree with splitting the backlog into two parts either – the Product Owner reserves the right to walk away after each sprint with the value invested to date. Solving the “how well/how cool” problems after doesn't allow this to happen.

  • https://www.targetprocess.com/blog Michael Dubakov

    I have a question to you. How many developers in the team run live usability test session? How many of them build prototypes to ensure good UX? How many of them a familiar with Persona concept? How many of them do wireframes?

    Also if PO walk away after each sprint, I guarantee that some stories will be done incorrectly, since it is near to impossible to document all stories in the sprint 100% right.

  • http://twitter.com/AnthonyBY AnthonyBY

    I hate to remind you but you owe me fifty pounds (c)

  • http://kaigilb.myopenid.com/ kaigilb

    Hi Michael

    I posted a reply at the blog http://gilb.com/tiki-view_blog_post.php?find=&b

  • https://www.targetprocess.com/blog Michael Dubakov

    I did not find the link Reply on your blog, so I will repost your comment here and reply here as well.

    by Kai

    “I read his post as
    – he agrees – developers don't get to be creative in finding solutions to the challenges.
    – he does not think they should, the Product Owner does that.
    – he does not think that specifying the challenge rather than feeding the solutions is a way forward.

    To me, Mr. Dubakov is a “victim” of his culture, the culture I'm addressing and hoping to enlighten a little bit with this blog series.

    He does suggest that it is a theoretical solution.
    “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…)”
    Well, we have lots of experience with doing this, I for 18 years, Tom for longer. They report (quantitatively) enormous improvement in productivity, creativity and developer enjoyment.”

  • http://profiles.yahoo.com/u/QHTRDS6KOB7USFXPE4N3WXMOYM Olga

    It really appears that Kai has got his own version of Michael's post and is reviewing this version, not what is written here in the post :) Besides, “enlightenment” made sense in middle ages… not now..

  • alayasinabuhijleh

    I agree. I usually run two iterations side by side. One for UX and one for Development. The UX iterations are always 1 iteration a head. The UX engineers and the web designers finalize the UI with the project managers, once this is finalized it will be added to the next Development iteration.

  • Steve Conover

    “Most developers are not product owners” – this is something close to a truism, and what follows is a broad and dangerous dismissal of value of developers' participation in product development.

    These are technology products. The possibilities and limitations of a technology product are dependent upon what can be done in a given amount of time given the state of technology today. Developers are most aware of what current technology can and can't do and at least some developers should be intimately involved in shaping the product.

    What you're advocating comes very close in my opinion to what Martin Fowler describes as “Decreed Stories”:

    “Here's a common misconception about agile methods. It centers on the way user stories are created and flow through the development activity. The misconception is that the product owner (or business analysts) creates user stories and then put them in front of developers to implement. The notion is that this is a flow from product owner to development, with the product owner responsible for determining what needs to be done and the developers how to do it.

    A justification for this approach is that this separates the responsibilities along the lines of competence. The product owner knows the business, what the software is for, and thus what needs to be done. The developers know technology and know how to do things, so they can figure out how to realize the demands of the product owner.

    This notion of product owners coming up with DecreedStories is a profound misunderstanding of the way agile development should work.

    In terms of coming up with stories, what this means is that they are always something to be refined through conversation – and that developers should play an active role in helping that definition.

    The product owner does have a special responsibility. In the end the product owner is the final decider on stories, particularly their prioritization. This reflects the fact that the product owner should be the best person to judge that slippery attribute of business value. But having a final decision maker should never stop others from participating, and should not lead people astray into a decreed model of stories.”

    http://martinfowler.com/bliki/ConversationalSto

  • https://www.targetprocess.com/blog Michael Dubakov

    >>What you're advocating…

    Hmm, it seems I failed to articulate my vision correctly. I don't advocate such team separation. I want to have all team participating in user stories discussions. But what I am saying is that many developers don't like to discuss UX, they like to discuss technology.

    Here is how we do it at TargetProcess. I, as a PO, write user story. Then we discuss it in a meeting with PO + Developers that will implement the user story + Tester that will test the user story + Scrum Master. We discuss functionality and why it has business value. On this meeting everybody can provide advices how to improve the feature. Sometimes there were quite radical changes in user story after the meeting.

    However if we are talking about UX phase, developers do not express much interest. For example, we decided to redesign navigation in a system. We have full process, from personas and scenarios to wireframes and live prototype with live usability testing. We have very good functional solution in the end of this process. Developers did not participate in these activities much. They were invited, but only few of them expressed the interest.

    Summary: It is great to have developers actively participating in all stages of dev. process, from UX to testing, but in reality it is hard to achieve, even if top management supports this goal.

  • http://andrewgolik.wordpress.com/ Andrew Golik

    Oh, sure. The developers are downright silly so they can't design at high level at all. Furthermore they have to pair in order to just create something. It more looks like football, everybody knows how play well but football players know it hardly. It is a pity.

  • https://www.targetprocess.com/blog Michael Dubakov

    Did you read the comments thread? I am not saying that all developers can't design and care about UX much, I am saying that most of them do not care.

  • http://twitter.com/aradzie Alex Radzie

    “Most developers can’t create usable design.”

    May be it's because your developers don't care about the product they are working on? What would happen if they were passionate about it?

    Here's the counter example from http://thegeektalk.com/interviews/scott-chacon:

    “At GitHub we don’t have a project tracker or todo list – we just all work on whatever is most interesting to us. No standup meetings, burndown charts or points to assign. No chickens or pigs. It’s sort of the open source software style of business – everyone itches thier own scratch. Inexplicably, it works really well and keeps everyone engaged, new features appearing quickly and bugs fixed rather fast. No managers, directors, PMs or departments – and it’s the most agile, focused and efficient team I’ve ever worked with. Maybe we should write a book about it.”

  • https://www.targetprocess.com/blog Michael Dubakov

    Yeah, I think you nailed the problem.
    Now we should find a good solution. What should be done to make developers really care?

  • http://profiles.yahoo.com/u/QHTRDS6KOB7USFXPE4N3WXMOYM Olga

    Alex' comment on developers being passionate is about something else. Put simply, it's all about work culture, tasks and goals. Developers are not slackers (mostly), and they do their job the way they should. Passion and care is not all the time about getting job done – you can't always be passionate. It might be that job is your passion. You might have some other passion – not the job you do. But it does not matter as soon as you do your job: if you're in this team – work is work. You just need to be plain professional, if you work as a developer in some company. What I'm trying to say is – developers have tasks to write code and implement functional features. They haven't been told it's their job to care about UX and produce awesome user experience. It's about making a good UX a part of their job. Perhaps they should work in immediate collaboration with UX designers. It's about changing the culture of software development – traditionally, developers do not see it as their tasks to think about designs. Changing this culture is not about “passion” and “care”. It's more than that.

  • Colin Johnson

    There is a good report on Agile + UX on Jakob Nielsen's site:

    http://www.useit.com

    It costs $149 but it is a great read at over 75 pages and describes the problem and some solutions better than the article above.

  • http://twitter.com/aradzie Alex Radzie

    “What should be done to make developers really care?”

    I think I know a better solution. Forget about developers, instead you should teach your UX people how to code. Just imagine, possibilities are endless. Not only can they create great user interfaces, they will also write user stories as they know problem domain so well, so no need for product owner. Now you can get rid of programmers too, who seem to be the weakest link. Usability experts themselves will be able to implement requirements. What a dream team of competent and creative people.

    Jokes aside, I've reread your post with comments again. Your message sounds like developers can't bring business value to user stories only because they don't like working on user interface. And because of that they should be told what to do exactly.

  • http://Nitpicker.PBwiki.com Nitpicker

    I pity the poor folks who have to use the crap your developers can develop. This is why the late Jef Raskin concluded that each project should be run by a UI expert. User testing is not enough. I can tell you how a major voice mail company conspired to make the users seem stupid and irresponsible because the company did what the power users insisted on with no understanding of the trouble that would create.

    Here, you either need to get new developers or to train them to understand the UI issues. Developers who routinely insert modal dialog boxes need reeducation. They shouldn't even be allowed to make Save buttons. You mean if I forget to hit this button you're going to take my forty-five minutes of work and throw it away?!! Do not do that, that would be cruel, though certainly not unusual. That is WHY computers are still so hard to use and behave so badly. I don't want any of the software you let your developers develop. I'll try to find some that care about making it easy learn and easy to use.

  • https://www.targetprocess.com/blog Michael Dubakov

    >>or to train them to understand the UI issues

    That is exactly what we are doing.

  • http://Nitpicker.PBwiki.com Nitpicker

    If you had said that was your plan, I would have applauded your intentions. So now that you clarify it, I do applaud your plan.

    Take a look at “The Humane Interface” even on its Wikipedia page. See also their brief page on the amazing man who wrote that book. I thought he was quite rude to die so soon after writing that seminal book.

    A key feature of humans is that they cannot multitask unless at least all but one of their tasks is learned so well that no conscious attention at all is needed. We should try to make this automaticity easy in the programs we create.

    Just today I watched a Front Line report on the new digital generation who wrongly believe that they can multitask without loss of effectiveness. Egregious examples include texting while driving which makes you more dangerous than being drunk AND crazy while driving.

  • https://www.targetprocess.com/blog Michael Dubakov

    I strongly agree about multi-tasking. It is a real pain to do several activities in parallel on any electronic device. That is why I really like iPhone. It has NO multitasking support :)

  • http://Nitpicker.PBwiki.com Nitpicker

    I saw this pdf http://bit.ly/aDM84a which may make Kai's essay make more sense to Agile teams. It's just as big a shift in emphasis, but it gets there more slowly with more explanation of why the shift matters. A bit more of a recipe (not receipt) to change developers attitude, perhaps.

  • http://twitter.com/knowyourfiles Metability Software

    Nitpicker,

    Developers are not stupid. UX people are not stupid. But you are missing the point: the pivotal issue is the Product Owner. If the PO is not good, nothing works out, because the PO _owns_ the PROBLEM, while the developers own the _SOLUTION_. This is the beauty of Agile, if you work with smart people: everybody does what he is good at / passionate about. I am a certified Agile Product Manager, what does that mean? I live for customer problems, I can literally smell them, it is a joy to talk to them and figure out what the heck keeps them awake at night. I can give a hoot how the code looks. But I sure know how to write market requirements and even PRDs. UX guys must be in the middle – they should know some coding but should be strongly tied to a competent Product Owner.

  • http://profiles.yahoo.com/u/QHTRDS6KOB7USFXPE4N3WXMOYM Olga

    this review goes along very well with this post: Harmonizing Agile With “User-Centered Design”: http://www.infoq.com/news/2010/03/ux-and-agile

  • BlakeKirkpatrick

    In a limited number of cases, the Judge will decide that one party should have sole legal custody. Usually in these child custody issues cases, there has been so much disharmony between the parents that it is in the children’s best interest to have just one parent making decisions for the children. In other cases, one parent has made bizarre decisions and the best route is for the other parent to have all the decision making power.

  • Will

    Sorry, but I am a bit lost. 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.

Schedule your personal demo

Our product specialists will show you the beauty
and power of Targetprocess 3 and help you to customize
it for your process and business requirements

Request

Get your free account now

Over 6000 teams
in 50+ countries start their day with us.
Welcome on board.