One of my constant heartaches when I see design proposals, or worse finished features, is the lack of thought given to the poor end-user. This isn’t a new subject indeed there are currently some insightful blogs from Microsoft employees complaining about the interfaces in some of their own products – Windows Media player springs to mind. With this in mind I thought I’d blog some quotes from ‘About Face 2.0 – The Essentials of Interaction Design’, please read the book but to whet your appetites…
‘…marketing departments are sometimes able to provide requirements, but these often have little to do with what users actually need and have more to do with following the competition, providing feature checklists to IT departments, or guessing based on user surveys or customer wish lists. None of these approaches take into account the users’ goals in any systematic fashion.’

‘…Developers…centring on technology and engineering methodology…Marketing departments focus on what drives press attention, on features lists, on what people say they will buy…The result…software that irritates, reduces productivity and fails to meet the user needs.’

I’ll stop there, if you want to read more then buy the book! But please all you developers and software houses out there, please think about the poor end-user. Take a long hard look at what you’ve developed or are developing and ask yourself honestly, are you making software that thrills or irritates the user?
 

After attending a number of seminars  (esp. the ‘Agile Investment in Software: Who cares how you build it?’ seminar by Chris Matts) and talking to other developers/architects I’ve been considering the pro’s and con’s of, "chasing the money" (Money). The basic idea is that you should provide the business with the best mechanisms for the company to make money. A core issue with any Agile development processes is what feature to implement next. If you take the Money approach then it can help focus the development on the immediate business needs, thus helping the product get to market faster, the business more successful, etc, etc (see Clarke Ching for a good introduction). I can see why this is a good idea (clever me) and it certainly is worth asking the question for every potential feature that could be implemented. However, as with so many ideas neither is it a silver bullet or particularly new. Recently, on different occasions, I’ve been confronted with developers who have not considered the non-functional requirements during their development process. When I recovered from the shock that this can happen I wondered if there was some common problem with the teams. When discussing it at XPDay the first conclusion was simply poor developers. I think there is something to that, certainly in one example the team of people were asked to do development when that isn’t that primary skill, ah the beauty of false economy. The other common factor was a feeling of them-and-us. The team Chris Matts described sounded like just such a case, "The Business people" vs. "The IT lot" whereas the idea is that everyone should be working together (aaaah sweet). Chris’ conclusion was that by using the Money approach the IT team were forced to validate everything they did as a business case. Herein lies the problem, if you combine the Money approach with the lack of importance given to non-functional requirements you run the very real risk of passing over such features in the clamour to grab the money. Some of the features are difficult if not plain impossible to put in afterwards. For example, consider building a house. Customers wants walls and a roof, they don’t care too much about the floor.  Obviously the conclusion of this example is you end with a lovely house that falls over in the next strong wind because the boring no-thrills foundations are rubbish and you end up with one angry customer and a reputation in tatters. I’m not suggesting this means the Money approach is wrong, but you must ensure that non-functional requirements are properly considered (with the proper business case) when deciding upon priorities and don’t use the wrong people! Like I said, I don’t think this is anything new, but it seems to be a lost message when there is a temptation of a quick buck.

One thing that has impressed me with Vista is the handwriting recognition, mine is truly awful but it still manages to translate my scrawl. So today I decided to test run the voice recognition. The dictating a text document is excellent, but not only is it very good at understand what I’ve said but it also understands a huge range of commands that makes it easy to maintain a document. For example, "replace that" will auto-select the word "that" and then supply you with a set of alternatives or you say the word you want to replace it. But what amazed me was when I dictated a simple letter and signed off as "John Smith". It wrote ‘John smith’. So rather then go through the replace commands I tried "capitalize smith" and it did it! Really good stuff. However, controlling Windows via voice control isn’t as easy. You have to learn to ask for things directly rather than navigate though the start menu. It’s a bit like using the Run menu, so rather than finding WordPad via the menu you simply say "Open WordPad". So it’s very easy for those things you know about or know their name, but it’s tricky when you don’t. I’m sure when you get used to it would be truly great too. So well done Vista, I take my recognition hat off to you.

XPDay London 2007

Keynote: Embrace Uncertainty – Jeff Patton

Jeff gave a very engaging presentation explaining some of the issues created by producing an incremental process from sprint iterations. He used a number of pop-stars to illustrate the point.
Roger Waters (Pink Floyd) was product owner concentrating on the burn-down wall and how each story (or brick) was been removed from the wall (or not).

Melanie Brown (aka Scary Spice – Spice Girls) was the lead developer asking Roger to, "tell me you want, what you really want". As the iterations started, Roger could see the bricks been removed (the velocity) but also started to see shortcomings in the product. So he asked for those problems to be solved and Mel B obliged by adding those new bricks to wall. However, inevitably, the deadline loomed and the only way to ship on time would be to cut bricks from the wall, something that Roger’s sponsors will be really upset about.

Jeff then introduced us to another Roger (Daltrey) and Pete Townshend (The Who), they are interested in building a road (magic) bus. They have similar problems with cost and deadlines but they know what to do. They’ve got a set of items (stories/bricks) that make up a bus; e.g. steering, sound system, engine, drinks bar, etc. However, that list doesn’t tell it all, e.g what sort of engine should they have? The decided to construct the bus by targeting the must-haves and by only implementing the basics versions of those items.

The model is translated back to Roger and Mel, by partially implementing stories to a point where they are useful it allows resources to be spread across the waiting stories. I.e. you can produce a working product, it might not have the expected bells and whistles the Roger wanted but at least he’s got a product. Importantly it will be released and be able to start realising revenue ASAP.

Jeff summed the process up with Johnny Rotten (Sex Pistols), "I don’t know what I want, but I know how to get it"

I really enjoyed the keynote, and I could have gone home then and felt it was value for money!

Plus quote of the…year, about team work, ‘You have a hole in your side of the boat’

[edit] – other reviews…

http://adamcohenrose.blogspot.com/2007/11/xpday-2007-embrace-uncertainty-jeff.html

http://www.kerrybuckley.com/2007/11/21/xpday-7-jeff-patton-keynote-embrace-uncertainty/

 

Introduction to Agile: The Software Development Paradox – Clarke Ching

The introduction was good and re-enforced a number of points from the keynote. I really enjoyed the point about software engineering following manufacturing rather than product development, see the cake slides. To paraphrase the cake story, if you wanted to mass produce a cake would you create a recipe, create a factory, mass produce the cakes and only then taste them? Of course, not, you’d taste the cake in the product development stages where it’s much cheaper to change. I thought you could also extend the analogy further by introducing quality control in the manufacturing process but hey that probably muddies the point.

The Social Nature of Agile Teams – Elizabeth Whitworth

An interesting study in the side affects of working in a agile team. The study was on the positive affects and they all seemed to solve problems I’m keen to solve; shared knowledge, knowing what is going on (and expected to be done), reduction in "dark room" developers, etc. All good stuff.

Exceptional Ideas: How to get your message through – Lasse Koskela

A bit of odd one this, ironically I’m not sure what this had to do with Agile development. I think the idea was to be able to sell Agile to non-developers, but the concepts can be applied to anything.
Talked about DICEE;
Deep. A great product is deep.
Indulgent. A great product is a luxury.
Complete. A great product is more than a physical thing.
Elegant. A great product has an elegant user interface.
Emotive. A great product incites you to action.

and SUCCESS – so successful I’ve forgotten what it means already!

Choosing the Content of Sprint & Product Owner Backlogs – Tom Tourwe & Olivier Biot

Talked about how to choose the items and were very LEAN like. I didn’t really like this one as I got the distinct feeling that the message was much simpler than they were making it. I also think they seemed to suggest a too lean approach, e.g. they seemed to suggest things like doing a feature and then worrying about performance later. I asked them about that and they quickly said they didn’t mean that but I know a few of us in the audience felt that’s what they saying. I must say that it was good that they shared their experience but just needed to add a couple of extra points to clarify their ideas.

Agile Investment in Software: Who cares how you build it? – Chris Matts

I enjoyed this and Chris is an engaging character. He said it was going to be confrontational but actually I thought his message was exactly what I thought was Agile anyway. Chris shared his experience about using an Agile process to make business decisions about what to build and therefore decreasing the time-to-market of products. One of his key arguments was that no decision should be made without the business agreeing it. E.g. a developer shouldn’t just refactor some code, they should declare the issue and it should become yet another ‘story’ that the business can decided to implement. That was all good stuff but it went a bit downhill when it seemed to offend people’s purist view of what Agile is, what a development team is, the responsibility of IT, etc, etc. That bored me, but the rest was interesting.

Day 2

Keynote: Cheek-to-cheek: why co-located collaboration persists – Yvonne Rogers

An interesting talk about how important it is to be in the same building as your colleagues and the hurdles of some communication devices (e.g. whiteboard, shared monitor, etc) where people can become frustrated waiting for their turn. Unfortunately that’s a 5 min talk drawn out for 60 mins. Not for me this one.

A Technical Story – Alex Vandenberg

A talk about how technical stories muddy the waters and really any useful technical story should be put in terms of a user story. I don’t think this is a surprise but again it re-enforces this sharing of to-do lists with the *whole* team rather than just the developers.

In the non-functional design space no-one can hear you scream – Sallyann Freudenberg

This was a gold-fish bowl workshop about how to take non-functional ‘requirements’ into account. When asked, "does anyone not understand the difference" I stood up. It’s not that I don’t know what they are but I don’t understand how anyone thinks of them as different. To develop a feature without considering things like the performance, how will it be deployed, what kit are we aiming to use, etc, is beyond me. Sure someone has to decided those things and consult with the customer but that’s part and parcel of any development isn’t? I liked and agreed with what some people said but was dismayed at others. Quotes such as, "it’s difficult because it’s not taught in computer education" just annoyed me. Talk about being spoon-fed, especially when the self same people were complaining about the quality of some developers – hmm.

Business is having to change faster to respond to its customers – how can the Agile community help? – David Stoughton

This talk described the need for business to get to market as soon as possible. For me this highlighted again that "Agile" is a concept before it is a software process. The talk also described how customers know more, the power of a brand and other important market points.

Fiat Lux: Testing with the light on – Joan McGallard, George Joseph & Pushpa Sebastian

A good talk about their experiences in creating automated acceptance testing. I did like their ‘active document‘ where the tests were written in English, via HTML, where the values were decorated with classes that were used to automate a test.

The Secret backlog – behind every bug report is a user story – Antony Marcano

Antony discussed how with a bit of creative re-writing a bug report can be turned into a user story. Subtle wording can be used to show where the story came from, e.g. "Instead of <behavior>" would imply a discovered problem. This is quite nice as it increases the visibility of the to-do list and it puts a more positive spin on the issue. It also allows more people to make a decision on whether the issue should be fixed as it is now in the standard iterative processes. He also said that with this you may want to abandon traditional bug tracking systems and go straight to creating the stories. One point that I found very interested was that the tester created an acceptance test for every bug found.