Agility

Is your IM this agile?

Doe the next thynge

My dear mother studied English at Edinburgh University in the early 1950s. As well as the usual Chaucer and worthy 19th century literature the course included a lot of Latin and Anglo-Saxon of which she could remember but one phrase in later life.

“Wyrd bith ful araed” she would say at opportune moments: “Fate is inexorable”. I was very impressed. It was all part of her love of words and language and she had another olde English phrase she would dish out when necessary: “Doe the next thynge“.

The origins of this phrase are unclear but seem to come from the bible via a Christian poem. This would make sense as mum was a deeply religious woman but she never mentioned the rest of the poem to me. I think this phrase on its own appealed to her as being a) quite funny and b) common sense advice. At times when I felt overwhelmed by things, generally having too much on my plate she would gently remind me that things weren’t so difficult. All I, or anyone, could do was “doe the next thynge“.

It struck me last night that “doe the next thynge” makes a good motto for an agile analyst; BUFD wants us to “doe every thynge“, agility comes from being able to define what’s the next thynge to doe. That’s part of the value that an agile analyst can bring to a project: identifying thynges and working out what to doe next. What’s the cure for analysis paralysis? Doe the next thynge. Think of it like leeches but less icky.

The real skill for us analysts comes not so much in understanding the thynges but determining what should be next, especially what should be first. Once you get further into a project the traditional approaches to prioritisation apply – by business value, by risk mitigation, by knowledge gained. But right at the start of a project or client engagement the next thynge can sometimes be elusive. So I like to start by asking my client what they need to know that you don’t know now. You should get a bunch of thynges from that. Using your skill and judgement decide what to do next. And just doe it.

Big Visibile Business Value

When did you last see your business value?

When did your project stop caring about business value?

It didn’t right? You work on an agile project. Agile projects are all about delivering business value, ergo your project still cares about business value.

Let me put that question another way. What’s the real value to the business of the feature you are working on today? Why is this thing worth implementing now?

It strikes me that we pay a lot of attention to business value when kicking off an agile project. We may directly look at the business case and the key business drivers. We will use this information in our prioritisation, scoping and initial release planning. And then we put this information in a jar marked Steering Committee and for the rest of the project team that’s the last we really hear about it.

Last year I had the good fortune to hear Markku Koppinen, ThoughtWorks’ former COO (and still our special friend!), give a fascinating talk about his time working for Frank Williams at Williams F1 racing. His premise was that as a formula 1 racing team the organisation had one goal: to make the car go faster. Any decisions made anywhere in that organisation, no matter how far from the pit lane, were still to be challenged with the question “Does it make the car go faster?”

I think projects should have a question like this; each release could have one; even each iteration. Working as an integrated high-performing team means having common priorities but if we don’t know the priorities or what really matters, then how can we achieve this state?

Part of kicking off a project, or a new release (or even an iteration) should be to define the priorities, to find that big question. If you can’t then is the project really worth doing? Is it worth working hard to achieve? And when I talk about priorities I don’t mean the high-value features. What are the high-value outcomes for the organisation? Why is that October deadline so important? If it’s clear to the team that shipping in time for Christmas can double the expected ROI on the project then how much easier might it be to fight gold-plating, feature creep, or make those scale vs scope decisions?

The problem is that the “business value” often remains locked in that jar marked Steering Committee. So let’s get it out there, written up on a big flipchart sheet, somewhere the project team can see it. I’m not saying we spill the beans on a top-secret business case but let’s write down why this is important. Why not make the “will it make the car go faster” question for the project, the release or the iteration part of your information radiator up there with the story wall and the burndown chart.

All the world’s a stage.

I’ve had the good fortune to attend an internal training course this week, brilliantly facilitated by my colleague Jeff Patton. Much of the content was around the art of facilitation itself and lo-fi modelling techniques and otherways to break through or stave off analysis paralysis.

In one exercise my colleague Amit (sharply dressed as ever) and I (less so) were co-facilitating a session where we were trying to drive out the high-level business drivers behind an initiative our clients were considering. We had decided to do it together without giving much thought to how and so we dived on in.

It was just like being back on stage in an improvisation show. I was there thinking “Well I want to do this..I wonder what he thinks.. ooh I didn’t expect that”. We didn’t have time to plan so we had to improvise and we had to work together. In practice that means taking it in turns to drive and accepting the other person’s steering. If one person felt we were approaching a cliff they could try and steer back in an other direction. It was pretty chaotic but it worked and it was clear that all the basic improv techniques applied: offer, accept, listen and keep it simple.

Last year I lead a workshop comparing Agile Development and Improvised Comedy called “Whose line of code is it anyway?”. I did it for internal ThoughtWorks groups in the UK, Canada and India in the end (US, OZ and China – I’m working on it…). I’ve attached my slide show from the Indian session here if anyone is interested.

This week’s experience made me think that there is further I can go with this. I’m going to start thinking about improv techniques for facilitators and how to apply them in a more formal business setting rather than in a knockabout workshop. If you have any thoughts, suggestions or comments please let me know.

 

DOWNLOAD PRESENTATION

Batch-it Job.

I bank with smile, largely because they are called smile (and the ethical policy keeps me warm at night). Their online banking experience is OK: it’s a bit boring but I get things done. Their phone help, however, is outstanding, the best experience I’ve had with any organisation. This week they came to my assistance again all because of an email I’d been sent.

On Wednesday I got an email from smile. It began “Your current account statement is now ready. To read it, access your
account and click onto statements.” So I accessed my account and clicked onto statements. My most recent transaction was dated the April 24th. But today was the May 2nd. My current balance was £300 less than the balance at the end of what I’d been told was latest statement.

I was confused, and a little bit worried, so I rang the telephone banking. Turns out I was the victim of a batch(-it) job. The operator could see my latest statement on her system, only they didn’t appear online till “later on”. I’d only discovered this because I’m in Canada and an email that is usually sent in the middle of the night (UK time) arrived while I was online. Typically users find this in their inbox first thing in the morning and if they are motivated to look at the details they will find the statement ready for them to view. My first thought though was why not make the communication follow the fact and not precede it?

It may be that there are processing reasons that compel this approach and that for the greater good it may be worth surprising those few customers logging on from overseas or lonely obsessives online in the middle of the night (I realise those groups are not mutually exclusive – hem hem). But I wonder… it seems to me a relic of an “overnight batch-processing” paradigm that an internet bank should not be reliant on. Moving to the web means shifting thinking patterns in all manner of ways. Satisfactory user experience means keeping your promises – including (especially?) the small ones.

Continuous Improvement

I bought myself an iPod shuffle this week. You’ll never guess what I’m most impressed by…

“The size?” Nah – I knew it was small when I bought it.

“It’s smashing orangeyness?” Nope, that’s nice but it’s not impressive.

“Some otherwise invisible technological marvel about which you are poised to enlighten us?” Er.. No.

It’s none of that. What’s really impressed me is that Apple have made it easier to put on the headphones!

Now maybe you are thinking that you have no problem putting on headphones thanks very much; where headphone putting on is concerned you are up there with the best. Maybe you are the Roger Federer, the Sidney Crosby or the Tiger Woods of headphone donning and you are secretly hoping that putting on headphones is included in the 2012 Olympics (at LEAST as a demonstration sport) because you KNOW you’ll win gold. Well bully for you! To be honest I’ve never had a problem putting on headphones either. What’s so impressive is that Apple have made something that’s already simple even easier and as a result I (the end user) am delighted.

Can you guess what they’ve done?

Unlike any pair of headphones I’ve ever owned, especially in-the-ear headphones, they have put L & R on the inside! The place you’re naturally looking at when you try to put them on. And they’ve made the letters BIG, so you can actually read them, echoing Fitts’ Law. It’s a classic usability improvement where someone has observed how people use a product and changed the way things are done to accommodate how people are. In the days of old school “Cans” putting Left and Right on the outside made sense. That was typically the easiest place to print it and read it. But as headphones have evolved the emphasis has been to make them smaller and lighter, not easier to use. Kudos to whoever decided to change that.

I’m well aware that I’m making a mountain out of a molehill here but the point that there’s value in making simple things more simple is worth remembering in software development. Think about the apps you use or you are developing, what’s the simplest task? Chances are it’s something people do often, maybe without thinking too much about it. What if you made it even easier?

What’s wrong with a little peace, love and delighting the customer?