Things you hear in the elevator

"The project is a great success but the system is still not being fully used. It's really hard to convince people to use all of the features."

-- anonymous person standing in a lift

The First Law of 'Captive' Users

I thought I would frame this thought as a law, just for fun, and because it sounds like one. Viveks blog entry got me thinking about why useability is often left behind. This is based on observation, experience, and too much wasted breath trying to convince people to spend money on user experience. I don't particularly like the reality it depicts but I do believe it to be true. Test your project with this logic and let me know if it holds.

If a company does not need to compete for business through external use of a particular software system, and if the users of the system are from different companies that will profit from the use of the system, then no more than a minimum amount will be spent on the user interface and useability. The users of this system are 'captive' users and will generally have to choose between using the system and not accepting business.

This situation commonly occurs where a large corporation has outsourced a non-core component of their business. A smaller company services this large corporation, and the large corporation builds the software used in their business interaction. Essentially the customer is building a system for the service provider, so the customer will build what they like. After all they are always right.

The converse to this law also holds, as with any respectable law :-)

If a company competes by attracting business through user interaction with a software system, then money will be spent on the user interface and useability. The amount spent will be the amount required to surpass competition.

Why is this? Well, from a financial perspective, only invest in something that will generate a return. If the captive users want a better UI, then let them build their own, integrate B2B and assume the cost of ownership for the user interface system. The people who commission us to build their software, will always use the ROI yard stick to measure the value of an activity. So before you try to change their perception of how the user should interact with the system, take a careful look the underlying financial drivers behind the development of the system. It will save you some breath, and maybe reduce your user experience evangelist status a little :-)

Retrospectives and group development

It surprised me the difference a retrospective made. I didn't feel comfortable that we were skipping them, even thought the project was happily adapting on the fly. Retrospectives had been tried on a previous project and had not gone well. So, after 4 months of development we finally did our first retrospective. The project was in excellent shape, so it was a good opportunity. I was really amazed at the positive effect it had. What was most interesting to me was the effect the event had on the group -- we really started to gel as a team.

From 5 Stages of Group Development:

forming -> storming: risk conflict. 'To grow from this stage to the next, each member must relinquish the comfort of non-threatening topics and risk the possibility of conflict.'

storming -> norming: listen. 'The most important trait in helping groups to move on to the next stage seems to be the ability to listen.'

norming -> performing...'The Performing stage is not reached by all groups. If group members are able to evolve to stage four, their capacity, range, and depth of personal relations expand to true interdependence.'

middle-toy-sprint

Three thoughts keep circling in my mind lately, interweaving like a Celtic design: Stuck in the middle; "If it's not deployed, it's just a toy."; Everything is done in a sprint.

I generally find the middle part of any project really boring. I naturally love initiation. I have really learned to love completion. But the middle always sucks. Agile goes a long way to eliminating this nasty middleness. I think an ideal agile project would be completely devoid of this evil plateau of boredom.

For me, completion means software deployed in production being 'used' by users (maybe not in anger but worked with from a meaningful perspective). No toys. Initiation involves reviewing, planning, discussing. Not looking too far into the future and not predictive. Put these together and there's no need for middle.

I like the idea of absolutely everything being completed in a sprint. This seems like the right way to do things. Maybe 30 days is too long but if *everything* has to be completed then maybe not. It's a really long time to wait for feedback, but a nice tangible duration for project governance, planning (not predictive) and reporting. The people who think about money and value, love monthly reports. It's how they run their business. It's how they measure their success, and how they extrapolate their likely annual performance.

Fantastic SyXPAC Apprenticeship Patterns Session

Awesome. What can I say. I was a little nervous beforehand. SyXPAC is generally a very technical forum. However I was delighted by positive response to the Apprenticeship Patterns.

We talked, we shared, we explored.

This was one of the best experiences I have had, discussing the very fabric of our industry. Not the technology that we all love so dearly, but the stuff that holds it all together. Our motivation, our passion, our craft.

The group was amazing. I gave an overview of the Dave and Ades’ work, and then we got stuck in. I introduced each pattern, shared my own experiences, then we discussed. The response was fantastic. Everyone had something to offer. We spent and hour working our way through the patterns of Walking The Long Road, only finishing because we ran out of video to record the event.

It’s clear to me how significant this Apprenticeship Patterns work is. When I first discovered it I soaked it up, nourishing my need for direction and definition in an industry almost barren of structure. It gives me an great sense of satisfaction to help disseminate this message, and to see the positive effect that it has on my peers.

We'll be having another session in a few weeks. Check out the SyXPAC site for details.

The Fortune at the Bottom of the Pyramid

"IF WE stop thinking of the poor as victims or as a burden and start recognising them as resilient and creative entrepreneurs and value-conscious consumers, a whole new world of opportunity will open up."

I recently read this article. It has an amazing resonance for me.

I don’t know a lot about economics, but I think I can recognise something exceptional when I see it. With his unique perspective, C.K. Prahalad is really on to something. I might be a little naïve in saying this, but it seems to me, that this is the future of economics. Now everywhere I look I see pyramids. In particular I see the resilience, diversity and ingenuity that lies at the bottom of each one.

What makes a great leader?

The Yipster's got me thinking about this with his post on project culture. I immediately thought of Level 5 leadership.

I think Jason’s blog entry follows on from a comment and a discussion, on the fact that managers do better than developers at the XP game. This came from Mike Lee who has recently run about 10 XP games for one of our clients, as a part of a company wide introduction to agile.

Why? Maybe because managers are better at self-organisation. The crux here I think, is that good managers are also good team members. This draws me back to Jim Collins’s research, that truly great leaders have the ability to work at all 5 of levels of his pyramid, and that skipping levels is something that needs to be made up later.

Iteration Slop: trailer-hitched QA

We got talking about this at lunch today. Unfortunately I have not done an agile project that didn't suffer from this... from Michael Feathers IterationSlop:

"The worst form of iteration slop is what I call trailer-hitched QA. When your team does trailer-hitched QA the developers work until the last possible moment within the iteration and when the iteration ends, they hand off to the QA team. The QA team gets the "final" build and they work with it for a while, running more automated and manual tests. Often this takes close to the length of an iteration. At the end of the process, QA gives their approval and the development team looks back at them, in the distance, and says 'Great! We really did finish that work!'"

How common is this? Post me some numbers if you have a chance, % projects that you have been on where trailer-hitched QA was standard. At the moment I am 100% for two agile projects -- both were trailer-hitched (one successfully completed, the other looks good at the moment, although the QA is well behind).

Why does agile "feel" good?

Working on agile projects feels really good. Delivering regularly, writing lots of tests, integrating hourly, interacting with the customer. These are all truly gratifying activities from both professional and personal perspectives. But there's something more to this. Just standing in a agile project space, looking at the walls feels really good. Why? After think about this for a while I have finally formed a theory. To be honest my subconscious has been throwing me plenty of clues, I just haven't known what to make of them.

At school from age four to twelve, everything we did went up on the wall. The pictures we drew, projects we took part in, the words we need to learn. Everything important got stuck up one way or another. Regularly we refreshed the walls with new, important information. The wall was a source of learning, activity and history.

For weeks now, my mind has been flooded with images of childhood information radiators. I can clearly see the birds nest on the nature table, my paintings over the door, the index cards of "big words" on the wall. These images remind me of happy, productive times where learning was spontaneous - you just looked at the wall for information.

Further than happy childhood memories though, people have been drawing on walls since the dawn of time. Agile project spaces "feel" good because this is how we have presented, communicated and retained crucial information for eons. If it's important draw it on the wall and share it with other people.

(You can also send it "straight to the pool room" if it’s truly significant: The Castle :-)

The more you flow, the faster you go

I've just started working on an agile project with Darren Cotterill, in Sydney. Ben Hogan and Jason Yip have already blogged about it, so I thought I would chip in with my two cents.

The project is really quite agile but "officially" it's a waterfall project. We're considering hanging up a picture of a waterfall, just so we can point and say "look, there's the waterfall". Really there isn’t a splash of waterfall in the vicinity.

We're a small team: 3 devs, a BA, a PM, and a tester. We have an enviable collection of whiteboards and wall space. Everything we’re doing is represented on a wall or a board. The PM is open and creates some awesome burn charts. The BA is ex-techy and writes exceptional stories. The customer is relaxed and good fun. We just write tests, write code and crack silly techy jokes.

It’s clear to me that there is something special about this team. We have only been together a few weeks, and already we’re already working very well together. Some teams I have been apart of, never achieved this level of cooperation and collaboration, even after months together.

The key element within this team is flow. The flow of requirements through development into test is smooth and quicker than expected. The flow of verbal communication is instantaneous and creates an informative environment. The flow of good humour keeps us all amused. All of this creates a well functioning team but the real key is the true flow that emanates from each individual. Each member of the team is truly enjoying their work. Everyone is contributing, and every contribution is highly valued. This creates an exceptional flow of positive energy that propagates continuously. This energy motivates us to go faster, and to reach for that almost impossible end date. Well, that and the promise of “all you can drink” beer when we make over to the finish line :-)

Simple Goals

It’s important to me to have goals. They help me figure my life out. They act as a filter for my choices.

Jason Yip recently read The Goal. Talking to him about this book really got me thinking. Thinking about a single overriding goal for me and for the company I work for, ThoughtWorks. What is our goal, what single purpose unites us?

One reader of The Goal reflected: “I just had a thought about this inspired by NonviolentCommunication: the purpose of business is to serve life, the strategy is to make money. Thinking of it this way really clears it up for me”. --JasonFelice

I thought this perspective was a bit too commercial. If business really served life then we would already live in a utopia, long beyond the point of needing a primitive concept such as currency to make our system work. I think our goal should only be altruistic: "To serve our society without exception". This didn’t quite fit thought, so I reformed my goal to:

“To create sustainable economic value in pursuit of intellectual value to the benefit of all people.”

Jason rightly pointed out that this sucked. It sound like too many concocted corporate mission statements. “Wording is too unnatural though. From the gut, how would you say it?”. So I had another go:

“To further humanity through commerce while remaining economically viable.”

Again not quite hitting the spot. So I thought for a while. I analysed the basic concepts. I looked for the simplest way to express each thought. This is what I arrived at as my goal:

“Learn some stuff, help some people, and make some money”