2010.01.07. SLC, UT.
At the Salt lake city (discussion: Re: Salt lake city) roundtable (discussion: Re: Salt Lake City agile round table protocol) today, we channeled Jeff Patton, who is allegedly up in Minneapolis with some others trying to work out a customer/user-centric extension to the Agile Manifesto. We decided to see what we would come up with in about 20 minutes playing the role of software users trying to get our wishes expressed.
We didn’t have time to settle on the grammar, so there are three variants of essentially the same words available. I don’t think it matters a lot which one you quote, the sentiments are the same. You can vote on your prefence or contribute your view.
Choice A:
We want product teams to deliver products
... that don’t merely “work” or fit a checklist, but solve my problems,
... that don’t merely fit my needs at a moment, but evolve as my needs evolve,
... that don’t work the way designers think I should work, but work the way I work,
... that I don’t merely see as tools, but see through to the work I’m getting done,
... that I don’t merely use, but I feel a joy in using.
.
Choice B:
We want product teams to deliver products
... that solve my problems, not merely that work or that fit a checklist,
... that evolve as my needs evolve, not merely fit my needs at a moment,
... that work the way I work, not the way designers think I should work,
... that lets me see my job getting done, not see the tool in front of me.
... that I feel a joy in using, not merely use.
.
Choice C:
“I’m tired of products that I merely use, that merely “work” or fit a checklist, that merely fit my needs at a moment, that I see merely as tools, that work the way designers think I should work …
I want products that work the way I work, that solve my problems, that I see through to the work I’m getting done, that evolve as my needs evolve, that I feel a joy in using.”
.
Choice D:
We wonder why teams often deliver products that pass tests, but that don’t solve our problems, that we merely use, that merely “work” or fit a checklist, that merely fit our needs at a moment, that we see merely as tools, that work the way designers think we should work …
I want products that work the way I work, that solve my problems, that I see through to the work I’m getting done, that evolve as my needs evolve, that I feel a joy in using.
.
Present for this exercise were Christian Hargraves, Andrew Shafer, somebody sitting next t Andrew, Kevin somebody, somebody else, Mickey Roos, Kay Johansen, Nate Jones, somebody else, Richard somebody, Zhon Johansen, and Alistair somebody. (If you know their names, for goodness sakes put them in!) Dale Emery suggested choice C, Laurent Bossavit suggested choice D.
How’d we do, Jeff? What did you lot come up with?
cheers – Alistair
(p.s. Does anyone else out there feel these worthwhile? Contribute if you wish to add to the discussion)
The first two statements remind myself off the Cooperative Game Manifesto. Deliver working software, but tomorrow be put in the situation to adapt it to my needs.
Personally I would like to try to challenge the third statement based on a story I heard from Gojko Adzic. In a talk he mentioned the situation that in the early Java years he was involved in a project to develop a product in Java, which should replace a legacy system. The users asked for printing functionality, which was merely a mess in early java versions and hard to incorporate. So, they got back to the requirements discussion and asked the users why they would like to get such a feature. They started to elaborate what they were doing. In the legacy system the there were basically three masks for input data. Since they needed on the second mask entries from the first mask, but these were not shown up in the old system, the printed out each input form after filling in the values. Then they took the print-out and used it to fill in data for the second mask, printing it out in order to fill in data for the third mask. Of course, the obvious solution to take the data that were already put in to the next screen, was answered by the user with a “You can do that?”
I would rephrase it to something like “that don’t work the way designers think I should work, but work the way I can work most effectively,”.
Preferences:
I dislike the second version, since by placing the don’ts in the back it puts too much focus on them. The message that is kept is the latter term. The principle is followed in the first and third option. I think the Agile Manifesto and the Craftsmanship Manifesto both are written in that manner, too.
The third one from Dale is a great distinction to the other two manifestos I mentioned. Maybe you may want that bridge, then you could prefer the first option. Maybe a direct distinction is relevant here, then choice 3 does fit more. I like both.
-by Markus Gaertner on 1/8/2010 at 2:38 AM
We need to show this to users. Preferably people who don’t make software but have software made for them. I don’t think some users would care about experiencing joy, they just don’t want frustration. How about ‘makes my work more enjoyable’ instead? The enjoyment comes from (suggestion) ‘makes my job easier to do’.
The idea of making software that fits the users, ‘work the way I work’ is great.
It always seems to me that designers and programmers think people want to use their program all day. Sometimes they will use the software all day but often they don’t. Often the user has many tasks and there is only one part of their day which they use the software. They want to get in do the work and get back to more ‘enjoyable’ parts of their day. To summarize, they often don’t care that much about the software. They just want their job made easier, faster, less boring, and more enjoyable.
This is a great first iteration. My vote is for A or B.
Let’s get this in front of some Users if it’s their Manifesto.
-by Billy Garnet on 1/8/2010 at 8:58 AM
(Alistair’s note – I tried to think of someone who deals with software system users at an interesting level, and asked Eric Olafson, CEO of retail-software provider Tomax to comment. Here are his words.)
First off, it’s a good idea, the user should feel respected and well treated in the whole process. And like a lot of first drafts, it might overachieve a little. I think if users felt that the process achieved on what they need, they would be ecstatic.
One of the things that I think is overplayed is the degree to which users want something that does exactly what they do today (let alone anticipates their next move!!). This is true of the middle ranking folks that stare and say, ‘that’s the way we’ve always done it’. But when you talk to the business unit leader, CEO, chief, top guy, etc — they will more likely tell you that what they are doing today is not sacred, and in fact, if anything, they suspect it is likely sub-optimal. I see many in software who fail to get this message. So the real trick, from the software development side, is to tease out of the people involved (ie. both the big chiefs and the indians) a sense of ‘what work/job is getting done’ and interpret it from the standpoint of ‘outcomes’ — which, btw, is a huge term and needs to appear more often in designing software.
This is a Clayton Christensen idea (what job is getting done) and involves the idea that sometimes getting to the right outcome involves doing something disruptive.
Another, somewhat off topic notion, that I think about is the idea of slow software — borrowing from the idea of the slow food movement – that we should not be in a hurry to write any software, there’s too much emphasis on speed vs. understanding, producing things vs. getting it right. There’s an old school notion here that developers really need to get to where they are seeing the problem space not only from the user’s perspetives but in a sense, past it, looking at solution scenarios that drive the most optimal outcome. Users love people that take this approach as they feel the connection is genuine and they respond incredibly well.
-by Eric Olafson on 1/8/2010 at 5:07 PM
I was going to comment – and I will do so shortly – but I had to stop to observe how this Wiki where we’re chatting violates the User Manifesto.
Here’s what happened for me: clicking “Join the discussion” caused everything but the discussion to disappear, leaving me unable to refer back to the text I was about to comment on.
Further, I was presented with an ugly brute of an input box, the CAPTCHA its most visible feature.
Trying to look around for cues (“Help! how do I get the text of the Manifesto to appear again?”) I noticed how confused the whole page makes me. The slew of links at the top, surmounted by tabs, flanked by further navigation options…
So, yeah. Room for improvement here.
-by Laurent on 1/8/2010 at 5:56 PM
OK, now that I have a) vented and b) put up the Manifesto in a new tab…
I prefer choice B. Needs wordsmithing; the repetition of “that” in the first point violates the parallelism in the rest; I prefer “see through to the work” to “see my job”; I’d prefer “feel joy” to “feel a joy”.
Strikes me as somewhat rah-rah overconfident, which fits the Manifesto format but that’s what people are tired of at the moment. Perhaps it’s possible to express these sentiments in a more tentative form, e.g. : “We wonder why so many teams turn out products that pass all their tests but don’t actually solve our problems…”
But, you know what – I suspect this isn’t going to solve the issue you want to solve. Programmers will read this, nod sagely, resolve to heed it, and keep on working as before.
What I really really want – I’m saying this as a user – is for the programmer to come sit silently beside me for one day, see how I work, see and understand my frustration (as well as my elation when I come across something well done; but these days, mostly my frustration).
(BTW at present one Webapp I’m mostly elated with is xero.com – ping these guys and ask them to tell you how they work. They manage to make accounting fun. Hat tip to Kent Beck thanks to whom they crossed my radar.)
Really, that’s all the User Manifesto I’d want: “Programmer/designer/analyst, get out of your office every month or six to spend a WHOLE day watching your user at work.” Or something like that.
-by Laurent on 1/8/2010 at 6:06 PM
I like these. I’d vote for A, and agree with the comments from Markus and Eric, that the best solution is neither the developers’ view, nor the users’, but something better which is found as the two groups talk (and think). I particularly like “seeing the problem space not only from the user’s perspetives but in a sense, past it, looking at solution scenarios that drive the most optimal outcome”.
-by John Rusk on 1/8/2010 at 8:55 PM
Markus,
The story is good but it wasn’t mine, It was Dan North’s. You can see it on Infoq, and I’d give you a link if this comment system was allowing me to do so :) but google for Dan North Crevasseof Doom
-by Gojko Adzic on 1/9/2010 at 6:58 AM
Hi, Gojko – for links —- we’ve been hit my malicious links, so do this: put in the link without the http or the www, and someone can copy it to a URL line; I’ll come by and connect the pieces later if/when I see it. Or, put spaces in after the http: and I’ll connect it.
– As soon as I find a better way to allow links, I’ll do that (any ideas?)
Alistair
-by Alistair on 1/10/2010 at 11:19 AM
I like the “enjoyable” point from Billy Garnet, and I feel more comfortable with the “D” form.
I used to sum up all the sentences in “User’s curses hit the target, maybe not all of them …but even 1% might be enough to hurt you.”
Anyway, as many were saying a synthesis is needed: investigating frustration doesn’t necessarily point to a solution, nor we can expect the users to bring in creativity and as developers simply do what we’re told. But it’s anyway better than just repeating the same old mistakes.
-by Alberto Brandolini on 1/10/2010 at 4:12 PM
I think a user manifesto is going to be a very important step forward for our industry. Moreover, I think we should pay attention to marketing and we should strive to make this one as publicized as the agile manifesto, since the readers of such a manifesto are more likely to be non-geeks, and they would be vastly greater in number. I’d prefer the first version, but the 4th item:
“that I don’t merely see as tools, but see through to the work I’m getting done,”
is not quite clear, for example the same statement in the second version:
“that lets me see my job getting done, not see the tool in front of me.”
tells the intent much more clearly (btw I’m not a native English speaker, so it may also be just me).
Plus, I think we need another such document (also to be read by users) which (somehow) protects the developer. For example, the document may include statements like:
- I understand that seemingly small changes may be harder to implement in software
- I understand that some features are more important than others, and all features cannot have the highest priority
- I understand that I’m supposed to be open to discussion and to actively participate in discussion rather than giving one-way requirements
Anyway I think this manifesto a great thing, and I’m looking forward to viewing usermanifesto dot org in my browser.
-by Serkan Camurcuoglu on 1/31/2010 at 2:47 PM