Is the ThoughtWorks mind the creative mind?

The guys over the fence in the media and advertising world are seeing a paradigm shift away from focussing upon the narrow “message” of a campaign to the broader “user experience” that encompasses the whole brand, not just a flashy graphic. This requires the “creative minds” to broaden their horizons. One such creative mind has created a picture that illustrates this.

The creative mind

This is a good way of thinking when attacking an IT problem. Not just focussing upon implementation detail, but the whole user experience. It means broadening the mind beyond the analytical. In addressing IT problems, developing greater “curiousity” and “expressiveness” is not a giant leap. But sesuality? Can developers ever have a sensual mind?

Recent experiences suggest so. Once a Dev has been hypnotised with a bit of web 2.0, emotional design seems to flow through their arteries. They “seek to satisfy all the senses. Aesthetics, beauty and form are driving forces…” That is they get all gradient-fills and curves and funky Ajax gizmos…

If it takes one man 3 days to dig a hole…

I was talking to someone working on the Kings Cross regeneration project and he told a sorry tale that has a certain resonance with IT projects.

So they were drilling a big hole that had to be drilled and they came across a major sewer. Now someone should’ve known the sewer was down there but clearly they didn’t and the hole drillers had a problem on their hands. You can’t drill through a sewer, the sewer had to be moved. And it is no easy task moving a major London sewer, it requires major bypass surgery. Costs necessarily spiral – it’s a new project building a new sewer and with the hole unable to be drilled the timescales of the regeneration project slip.

But that’s not the end of the story. Apparently they start digging a new trench to lay the new sewer bypass and it is by a building full of business people who like to have their office windows open and clearly don’t take kindly to all the noise and dust from the trench being dug. And work on the new sewer grinds to a halt as negotiations take place on what to do. They have the windows open because it is hot weather and they have no air conditioning. Time slips further and costs escalate even more as the solution is agreed. Until the contractors have installed air-conditioning in the building no work can continue on digging the trench, no work can continue on bypassing the sewer and no work can continue on digging the hole.

Hot air balloon

For a while I’ve been buzzing about Luke Hohmann’s innovation games and am looking forward to his new book coming out. Using games, stories and pictures is a great way to get people engaged in workshops and get to the crux of problems. One problem you often get with people sitting around a table is a small number of vocal people contribute loudly, leaving timid bystanders with good stuff to contribute afraid to get involved. Obviously a good facilitator will look to overcome this, but get people in pairs, give them blank cardboard boxes and coloured pens and ask them to produce the packaging for the product they want to develop and you’ve got a great levelller.

These exercises do take time and can really only be done one at a time. In an attempt to fuse together the “product in a box” identifying customer needs and “speedboat” which identifes the anchors that are holding the project back, I’ve used the analogy of a hot air ballon a couple of times to some success. You draw a huge hot air balloon on the wall with ropes teathering it to the ground. You then get participants to put the features that they’d like to see advertised on the balloon. Participants write these down on post-it notes and they are stuck on the balloon. Clearly if all these features were all written across the balloon they would not all fit if sized so they could be read when the balloon flies in the sky. So just like in Formula One where a logo on side of the car will be larger (and more valuable) than the advertisment on the back of the drivers helmet, you then identify those features that must be visible from the ground (high priority) and those that may only be seen on the ground (low priority). That’s the first part of the exercise. The second part is to get participants (again using the post-it notes) to imagine the ropes are project constraints that will stop the baloon flying. In the space of 40 minutes if all goes well you will have driven out the top-of-mind features the participants want the project to deliver (and priortised them) and identifed the top-of-mind risks and issues that particiapants have. And most importantly you should have everybody engaged; with any luck a bit of laughter will be heard on the way. And that can’t be a bad thing in a corporate meeting room.

I feel like a client

I took all of last week off to install a new kitchen.  The only thing I couldn’t do was fit the surfaces so I got the professionals in to help.  Air was sucked in through the teeth, the head shook.  “What numpty fitted this lot in?  Look at the gaps”  …Well I was going to use filler.  “If you want the kitchen to look good in a years time, we’re gonna have to pull it all out and start again”.  I don;t have time to start again, new baby arrives tomorrow.  Grrrrr.

And it occurs to me that this is just like the real world of business.  “We don’t need the consultants in, we’ll do it all in-house”.  But just like my kitchen, inevitably things go wrong, deadlines get missed and you end up having to start again and pay more than you ever anticipated.   Moral of the story, if you are going to do something, do it right.  Know your limitations.  Get the experts in.  Trust them.

Some people say anything to recruit

Recieved an unsolicited mail yesterday from a consulting firm looking to recruit developers (not a well targetted mail for me to receive it). What can they offer?

“Unlike many “consulting” firms, we don’t hire and fire based on client and project demand; we’re interested in a long-term relationship with people that share our drive. We hire employees because WE like them, not on the say-so of our clients!!”

Hmmm. so that’s a sustainable business model that inspires confidence…

I could’ve told you that…

Sometimes you have to wonder about academics in their ivory towers of research.  At the Ergonomics Society Conference a paper was presented on a usability evaluation of MP3 players and virtual jukeboxes.  The researchers used “reparatory grid analysis”, a pretty cool technique that got subjects to create their own “constructs” by which evaluations were made.  I’m not knocking their work – it was a good peice of research,  what I do question is it’s worth.  The research took several months and signficant effort to complete.  And thier conclusions?  Of the dozen or so products evaluated the iPod and iTunes were top of the class in usability.  I could’ve told you that after a couple of hours playing with all the devices (backed up by “heursitcs” if you want a veil of research rigor behind the results).  But accademics don’t do the pragmatic.  They need validity and relaibility.  Business needs results fast that sometimes only pragmatism and a healthy disregard of scientific method gives.

Who is talking to who?

A successful agile project depends upon open channels of communication. Unfortunately this is all too often usually between different parts of the organisation that do not have a track record of talking. Getting a conversation between the business and IT can be a challenge, especially when the two sides don’t really know each other. The trouble is that when we roll up at a client we don’t really know who knows each other – what channels of communication are open and what are closed. what is the reality that the organisational chart doesn’t show (if you can get the org chart – not so long ago I worked with a client whose org chart was inaccessible – it was password protected on their intranet).

Social Network Analysis is a useful technique for identifying and visually representing the way that individuals are connected within a social structure. It can be as simple (does Jack communicate with Sarah) or complicated (is Jack a casual acquaintance of Sarah or a trusted friend). I’ve a feeling that when we first start working with a client who is new to agile, there should be an element of “organisational readiness” that would include SNA to identify the channels of communication. I’ve been playing with Agna as a tool or doing this, and am looking for others to play with.

There’s a leak in our pipework

Grrrrrr.  Drip drip drip.  Water dripping through the kitchen ceiling.  So I rush upstairs, pull back the carpet, rip up the floorboards and hunt the leaking pipe.  …to no avail.  I locate a stream of warm water, trouble is it’s not coming from a pipe, it’s pouring down the inside of a partition wall and there’s not a pipe around.  So the only way to find it will be to knock out the wall and hope there’s a pipe somewhere behind.  Quick call to the insurance company – I’m covered for the search and find, but not the plumbing.  Grrrr.  If this house was software it would be a pizza house.  Everything is so tightly connected, you can’t just pull something out – it’ll pull allsorts out with it.  Better start again.   But in software you don’t have insurance for the mistakes that some  foolish previous owner made.

Another way of prioritising stories

One of the cool things in Agile is the way we prioritise stories – functional and technical requirements. With the stories being cards it is easy to shuffle them about on the table and move them up and down a hierarchy of importance. Trouble is such a simple idea often fails to provide the simple desired outcome.

Problem 1.
Prioritisation is difficult. Bad experiences with IT often lead the business to believe that anything given a low priority is effectively being de-scoped and thus are reluctant to mark anything low.

Problem 2. Relating the prioritisation back to the business objectives. If it is not made clear before (and during) the exercise that the prioritisation should be based upon business objectives (for example we are doing this project to reduce costs or drive revenue) stories tend to be prioritised according to the personal agendas. So the marketing stakeholders will be pushing content management to the top of the pile, change management will be pushing training and support tools, IT will be pushing diagnostic tools… and the high priority stories become a disjointed list of features that do little to address the business objectives.

Problem 3. The language of prioritisation. Often it is not clear why we are doing the prioritisation. The business wants the project with all its features – otherwise why would it have identified them in the first place. MoSCoW – must have, should have, could have, want to have softens the language of “high, medium or low” but there is still a bucket of “W – want to have” which in effect is perceived as “won’t have”. Doing away with language altogether can be more effective, but ranking the stories tends to lead to clusters and moving things out of the clusters (i.e. assigning lower priority) tens to be painful.

Problem 4. Highest priority stories do not make a release. Let’s be clear, more often than not the objective of the prioritisation exercise is to drive some sort of release plan. To be successful a release should constitute a meaningful and coherent collection of stories that drive business benefit. Logging in to your shopping cart is deemed as being of high business benefit, password reset and logout low priority. Yet without these the release is incomplete.

So what to do?

The concept of a tree is useful, there are roots that are essential, a trunk, branches and leaves (and the leaves can be pruned by the conscientious gardener to produce the perfect tree), but this approach does not really address problem 4.

We’ve started trying a new approach which seems to work. You are open and honest about the purpose of the exercise. It is all producing a high level feature plan to inform the way we will develop (and maybe release) the software. We make it clear that it is not about fixing scope or producing a release plan that we will all be held to (things change right?). You lay all the cards on a central table, spread out and not overlapping. There are four separate tables labelled A-D (or however many ‘releases’ you aspire to). These are the following:

Table A – If you could launch the product tomorrow, what is the bare minimum you would require to satisfy immediate requirements of customers and the business?

Table B – What would your customers require next? What would does the business need next?

Table C – You’ve been live for a while, what comes next?

Table D – These are the final features that are important but not mandatory on tables A-C

It is important that the cards do not have titles on them. That way the people prioritising them must read them (and understand them) before assigning each card to a table. You then prioritise in time boxed iterations (it can be useful to have an egg timer to help this). In the first iteration you ask everyone as individuals to pick a card from the centre and place it on a table. Remind them to think about the business objectives. The only rule is that the tables must contain a roughly even number of cards. (If table “A” becomes “full” a gate keeper can prevent more cards from being added to it. Remember this is just the first iteration).

The second iteration involves everyone standing around Table A and looking at is as a meaningful release. Does everything in there meet the business objectives? Is it self contained? The objective of this iteration is to exclude items that could come later (for example “data migration”. For the first release maybe it would just be a pilot and we could manually put customers on the system). There may be comments that there are things missing – it doesn’t matter, we will find those later. Again, time box the iteration and then move on.

The next iteration focuses upon table D. What needs to move up? Ten minutes then move on to tables C and D. These might be hardest; it is easy to agree what must be delivered early and what can come last, but the stuff in-between can be a challenge. Maintain momentum by always returning to the business objectives, and what are the most important to deliver on first. Once all tables have been visited a final iteration walks through them all. Again, it is made clear that this is not something we need to be held to, but it informs how we move on; to drilling into more detail on the high level stories and producing sufficient insight to make meaningful estimates. Estimation? Now that’s a different story.

12 of 13