Jakob Nielsen on the use of Agile methods:

Agile’s biggest threat to system quality stems from the fact that it’s a method proposed by programmers and mainly addresses the implementation side of system development. As a result, it often overlooks interaction design and usability, which are left to happen as a side effect of the coding.

In my experience, mostly as a developer, it is really easy to dismiss interaction and usability design for two reasons.

The first comes from the developers themselves, trading prettiness and consistency of user experience for cleaner and sounder domain models whenever they go in opposite directions. Signs this is happening are developers crying YAGNI when the stakeholders ask for a zoomable chart or DTSTTCPW when a sortable, paginated data table is required.

Next time you see a system where there are enormous listings of items with no search, pagination or sorting, ask the developers if they have ever watched a typical user at work; chances are they have only thought about the system as they see it: since the testing dataset is usually small, a loop spitting out a bit of HTML for each element isn’t such a big deal. They might even say there’s a story to implement all that lovely stuff later on, but they just get moved over and over to the bottom of the backlog barrel… until everyone watches a person struggle to find needles in a tabular haystack all day. This is a simple example – almost too trivial actually, but one I’ve seen happen way too many times.

Changing the perception that usability is just the icing on the cake draws attention to all that wasted time to the stakeholders, and should enable a much better dialogue: developers get to write an application users will love, stakeholders spend their money wisely on something that will actually increase return on investment (as productivity gains), users feel empowered and less likely to make mistakes. Everybody wins.

The second reason UI design and usability get overlooked, and this is the one Frank alludes to in his latest post, is that some agile teams rely a bit too heavily on the stakeholder’s descriptions of what is wanted. It instantly reminded me of one my favourite quotes from Cars:

Lightning McQueen: All right, Luigi, give me the best set of black walls you’ve got.

Luigi: No, no, no! You don’t know what you want! Luigi know what you want. Black-wall tires, they blend into the pavement, but these white-wall tires, they say look at me, here I am, love me.

Lightning McQueen: All right, you’re the expert.

I find it rare for the stakeholders to know exactly what they want, down to what the end-user experience should be like. Thinking about a reasonably-sized application at this level of detail can only be done as a series of small, incremental steps and having someone on the team who is really obsessed about making every single pixel on the screen be in the right place. And if you read the last sentence and thought “well, that’s not exactly the role of my stakeholder!” you get the point: the stakeholders should not have the final word as to what the usability and experience details should be, in the same way they simply delegate to and rely on the expertise of the development team to flesh out the details of a persistence layer.

Have look and feel expertise in your team, and trust it, in the same way you would trust the database or network connectivity expertise.

A toothpaste factory had a probem: they sometimes shipped empty boxes, without the tube inside. This was due to the way the production line was set up, and people with experience in designing production lines will tell you how difficult it is to have everything happen with timings so precise that every single unit coming out of it is perfect 100% of the time. Small variations in the environment (which can’t be controlled in a cost-effective fashion) mean you must have quality assurance checks smartly distributed across the line so that customers all the way down the supermarket don’t get pissed off and buy someone else’s product instead.

Understanding how important that was, the CEO of the toothpaste factory got the top people in the company together and they decided to start a new project, in which they would hire an external engineering company to solve their empty boxes problem, as their engineering department was already too stretched to take on any extra effort.

The project followed the usual process: budget and project sponsor allocated, RFP, third-parties selected, and six months (and $8 million) later they had a fantastic solution — on time, on budget, high quality and everyone in the project had a great time. They solved the problem by using some high-tech precision scales that would sound a bell and flash lights whenever a toothpaste box weighing less than it should. The line would stop, and someone had to walk over and yank the defective box out of it, pressing another button when done.

A while later, the CEO decides to have a look at the ROI of the project: amazing results! No empty boxes ever shipped out of the factory after the scales were put in place. Very few customer complaints, and they were gaining market share. “That’s some money well spent!” – he says, before looking closely at the other statistics in the report.

It turns out, the number of defects picked up by the scales was 0 after three weeks of production use. It should’ve been picking up at least a dozen a day, so maybe there was something wrong with the report. He filed a bug against it, and after some investigation, the engineers come back saying the report was actually correct. The scales really weren’t picking up any defects, because all boxes that got to that point in the conveyor belt were good.

Puzzled, the CEO travels down to the factory, and walks up to the part of the line where the precision scales were installed. A few feet before it, there was a $20 desk fan, blowing the empty boxes out of the belt and into a bin.

“Oh, that — one of the guys put it there ’cause he was tired of walking over every time the bell rang”, says one of the workers.

At ThoughtWorks and many other workplaces all over the world, employees are given SecurID tokens, a tiny and nearly indestructible device with an LCD screen that shows a different sequence of six random numbers every minute.

So, what do you do with a sequence of random numbers, apart from logging into your corporate intranet and email using secure two-factor authentication? You play Poker, of course!

The rules are pretty much the same as a Draw Poker game, only without any card changes or betting round. Ordering is also different, 0 being the lowest and 9 the highest values. There are no suits, but the time left to the next sequence change, displayed in bars at the left-hand side of the token, can be used to settle ties. A new round is usually more convenient, though.

As two fobs don’t change sequences at the same time, it makes sense to shout out your hand as soon as you look at it, or see if you can get away stalling everyone until your next hand shows up, if you have nothing. Of course, there’s room for the High-Low Split variation, but that could get a bit messy and has been discouraged.

I was introduced to this brilliant little game last night, and it has instantly gained my preference over Rock, Paper and Scissors to settle small arguments such as who’s going to get the next round, fix the build, pay the restaurant bill or drive the rental car.

Interesting quote from my colleague Obie after my comment that software development projects have five variables (time/duration, budget/price, scope, people/rates and quality) and that we should be able to respond to change in all of them, on this post:

(…) Letting quality slip has never, ever produced good results in my experience. I’ve been in situations where the client was explicitly demanding it, but it was still a bad idea and has all sorts of negative repercussions on the team.

Some might argue over the exact definition of those variables and how they play together. I write specifically in the context of consultancies, in what I may have some experience in.

In this context, budget/price equals time/duration of the project times people/rates including the management overhead. It’s a simple and easy equation which has traditionally left the scope and quality variables out, up for discussion. And those discussions can go on and on until the last pointy hair is yanked in despair.

To us and most people in the Agile world, quality is not even really a variable – we like to think it’s a constant, and hopefully fixed way up high close to 100%. To clients, not necessarily so – while some definitely know the importance of a good QA, some might be willing to take the risk and compromise the quality of the product in order to gain some market advantage by reducing the duration of the project, or to save some money on the short term.

As long as everyone understands what playing with that variable causes to the sustainability and risk of a project, and there is a justifiable reason to do so that the whole team can buy into, I don’t see a problem. But, you see, that’s only a theory of mine – I’ve never actually seen that compromise being made with a reason I could believe myself.

PS: I need some feedback on this! If you know – or even better, was involved in – a project where that happened, please get in touch.

I had an interesting chat last week with some colleagues from ThoughtWorks about a situation we currently have at a few of our clients. It’s an interesting economical challange and, even though I’ve missed most of my Economy classes, I still like the subject. Point is, companies and IT contractors tend to develop a variation of the Stockholm Syndrome over time because of the way incentives play out.

It goes like this: FooCorp has a big IT project ahead of them, which will need about a dozen developers. They’ll only need a third of that to maintain the application once development has finished. It makes sense for FooCorp to hire the remainder of the staff as contractors, so that they can show them the door without too much hassle when everything goes to production use. Contractors, therefore, take the risk of having to look for another gig sooner than expected, in case the project gets cancelled, and adjust their rates accordingly. Those high rates may lead to a project management working under budget pressure, which might drive managers towards shrinking the feature set and/or the schedules. Here’s where the fun bit starts: are there any incentives for a contractor to actually deliver any quality software at all?

As I see it, there are two positive incentives: peer pressure in justifying rates, and collecting good contacts and references. In the situations we have been witnessing, those pale next to doing whatever is possible to extend the contract, which more often than not are some incarnation of finger-pointing, back-stabbing or just plain inaction in order to make the project as late as possible. By extending the contract, they can ensure there’s always time to fix the mess created by blaming everyone else but their contracting buddies (those who’ll happily point them to new gigs) and pretending to work harder than everybody else by assuming authorship of other people’s work and ideas, while happily surfing the web all day.

Wouldn’t anyone at FooCorp notice that? They may have, but by the time they realize how serious the situation is, it’s usually too late to dismiss the contractors without seriously bleeding knowledge from the project and risking the schedules too much. In a way, there’s all this business knowledge being held hostage by the contractors, and the ransom is to be paid in monthly installments, until FooCorp’s employees pick it up and are able to run maintain the project on their own. Keith Henson wrote, in Sex, Drugs, and Cults:

Fighting hard to protect yourself and your relatives is good for your genes, but when captured and escape is not possible, giving up short of dying and making the best you can of the new situation is also good for your genes. In particular it would be good for genes that built minds able to dump previous emotional attachments under conditions of being captured and build new social bonds to the people who have captured you. The process should neither be too fast (because you may be rescued) nor too slow (because you don’t want to excessively try the patience of those who have captured you).

Of course, there are contractors with good ethics and who manage, against all odds, to deliver some truly amazing code.

I don’t remember exactly how I ended up there, but after following a discussion on a possible Refactoring browser implementation for Ruby over at Murphee’s, Lean Manufacturing grabbed my attention. Besides Just-in-Time production, there is another big aspect of it that I hadn’t paid much attention to before: Muda, or the reduction of waste.

Waste, in the Toyota Production System, can come from seven different sources: overproduction, waiting, transporting, inappropriate processing, unnecessary inventory or motion, and defects. They can all be mapped to the software development domain quite easily, and most have a direct link to agile methodology practices, even if in some cases you have to stretch your imagination a bit. Not to wonder, as most of software development processes were directly inspired by production line practices – not necessarily in the conveyor belt sense, but more as in “I have (resources, ideas) and would like to make (manufactured products, software) out of them. What is the most efficient, effective and sustainable way to do so?”

There are two things we can waste while developing software: time (and its little brother, money) and brainpower (and its big brother, talent). Interestingly, flushing one down the toilet also brings the other with it: a project stuck in endless meetings or in fixing production issues is wasting both its people’s time and brainpower, and I find it fascinating and saddening at the same time how often I see projects that are up to here in both problems: a production issue is found, meetings are held for days or weeks, but nothing gets actually done to fix the problem and avoid it happening again. During those meetings, there’s lots of talk about changing the architecture, platform, getting more programmers and tools, or my favourite, “just rewriting the whole damn thing.” And rewriting a significant part of your system, as anyone who watched Netscape die can tell, doesn’t work.

Still, why is this behaviour so common, and why aren’t we working on bringing refactoring support for purportedly extremely productive languages like Ruby like there is no tomorrow, as to avoid repeating the mistake of rebuilding things instead of beating them into shape?

This write-up by Clay Shirky at Many 2 Many on why he sees the never-ending debate about Wikipedia to be a matter of fundamental differences in thinking is just brilliant, and it probably has a much broader scope than just technology innovations. Here’s a couple of choice quotes:

When thinking about technological change, there are two kinds of people, or rather, people with two kinds of maps of the world — radial, and Cartesian. Radial maps are circular, and express position in relative coordinates — angle and distance — from the center. Cartesian maps are grids, and express position in absolute coordinates.

Anything that was bad at Point A and is still bad at Point B gets factored out of the radialist critique. Any change where most of the bad things are still bad but a few of the bad things are somewhat less bad seems like a good thing to us, and if it can happen in a way that requires less energy, or better harnesses individual motivation, that seems like a great thing.

I’ve started reading The Wisdom Of Crowds yesterday, a wonderful book about how decisions taken by groups assembled under the right conditions constantly outperform the ones taken by experts. There are numerous examples, tales and food for thought served warm and with some delicious toppings.

I’ll refrain from blurting out quotes, because there are just so many good quotes I can’t really decide on anything significantly interesting that could be taken out of context. Anyway, if you can’t take the time to read the whole thing, try Smarter than the CEO, an essay by the same author, James Surowiecki.

I reckon there’s a huge and barely explored field for great software to grow in based on the wisdom that crowds hold: most companies don’t really take into account the power of its combined intelligence, relying on higher-ups to decide on what’s important when creating a good environment for groups of employees to decide on these matters could yield more accurate decisions.

Software that helps assembling and aggregating information from those groups within a company barely exists today, and I’m trying to come up with something. Shouldn’t be too hard, actually: some companies have experimented with internal stock markets and had fabulous results, and maybe that’s a good way to go. I’d buy a lot of Dan North and Liz Keogh shares by now: there’s GeekNight next week and JBehave is surely going to be discussed.


PS: I promise the next picture will not have insects of any kind.