Future Quotes

I wanted to share a facilitation technique that’s worked well for me in a couple of different scenarios. It’s similar to a Futurespective, or the Innovation Game “Remember the Future”.

Like a Futurespective I ask the participants to put themselves forward in time, to a time after the project has completed and the new application (or whatever) is live and in use. Rather than looking back at the project and identifying successes and challenges I ask the participants to consider conversations with key stakeholders. In the first instance I ask them to imagine the best case scenario where everything has worked perfectly, delivery has been on time and the functionality meets or exceeds the end-users’ expectations. “What would you like to be told?” I ask them, “Or overhear at the watercooler”. On separate stickies (big ones preferably) I ask them to write down a particular sound bite or quote that sums up the response they want to get. I then repeat the exercise but ask for a worst case scenario.

The first time I ran this exercise I did it with a very dynamic, creative CEO who had a vision for a new version of his company’s core software application. Like a lot of dynamic, creative people he was brimming with ideas but it was hard for us to understand what were his priorities and what was the big picture. In this exercise I asked him to imagine conversations with his key external stakeholder, with his CFO and overhearing comments from people who use the application. We wrote up the quotes on big flipchart sheets and I thought the results were really interesting. From the exercise we got a clear expression of what our business sponsor thought his success would look like. Without asking him “What are you critical success factors” we got a pretty good view of what he (subconsciously?) considered success in terms of delivery time, cost/benefit and even user experience. We could use these quotes to plan our work diving into the roadmap and the backlog by considering “How will X help our CFO say Y”.

I tried the technique again in a very different environment.This time I was facilitating a meeting of a group of managers who were kicking off a new initiative across multiple teams. I wanted to use the exercise to start building a common understanding between the members of the management team of what they considered was expected of them and what they felt were their main challenges. So we identified some stakeholders at all levels and again did the best-case-scenario, worst-case-scenario quotes. We then made an affinity diagram for each stakeholder, grouping together quotes that seemed to be related. After that I asked all the participants to look at the quotes and the groupings and write on a different coloured sticky what thought or word each quote brought to mind. In other words what would be going right or wrong to make someone say that. This gave us the material for further discussion as a group and allowed all the participants to see and hear what their colleagues thought was significant.

I’m definitely a fan of this as an approach, either as a way of clarifying one person’s vision and expectations or getting a group of people to share their own assumptions about a project.

An announcement

It’s official: I am the Bette Midler of Agile enablement!

that's me!

On my current engagement I’m working as an Iteration Manager on a development project but I’ve been asked to help out and coach another team as they try and work more iteratively. They aren’t writing much in the way of code, it’s more about the co-ordination and roll-out of a customised product. It’s been an interesting challenge thinking about how agile principles can add value in their case but one made much easier by their desire to work in a new manner. In particular the PM felt a more iterative approach would improve communications with their stakeholders and within the team.

The first thing I advised them was to develop a backlog or master story list and not keep it in excel. I’m a big fan of some kind of big visible chart that shows everyone what is outstanding in the project. So we had a kick off meeting where we brainstormed the tasks and actions needed to complete the project (first having brainstormed what completing the project really meant!). From this the team produced an affinity diagram, grouping the activities together. This has become the basis of our project backlog cum burndown – we have a big visio model with 4 columns of tasks and each iteration we tick off more tasks until everything is done.

In our iteration planning each team member looks at the task list and signs up for what they can complete in the next 2 weeks. We also review the sign-up from the last iteration and see what was blocked or what couldn’t be done and agree how we can resolve those in the iteration ahead. We’ve even done some t-shirt sizing of tasks and assigning a simple points scale to each work item. I’ve encouraged each team member to have their own scale because QA tasks and PM tasks are completely different. But the hope is that in the next iteration planing they can use ‘yesterday’s weather’ to give themselves a quick sense-check on whether they are being over-optimistic or not.

So far the response has been very good. The approach seems to be working well with people saying it’s particularly improved their knowledge of what each person is doing on the team and that they value the visibility into the project status. At the end of the last IPM I got a wonderful compliment from the Project Manager. “JJ” she said, “you are the wind beneath our wings!”

Robert Louis Stevenson: Agile Guru

I came across a wonderful quotation from ace Scots pen-jockey and moustache fan, Robert Louis Stevenson, that really helps get the Agile message across.

The principles behind the Agile Manifesto include:

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”

RLS explains why:

“Literature in many of its branches is no other than the shadow of good talk; but the imitation falls far short of the original in life, freedom, and effect. There are always two to a talk, giving and taking, comparing experience and according conclusions. Talk is fluid, tentative, continually ‘in further search and progress’; while written words remain fixed, become idols even to the writer, found wooden dogmatisms, and preserve flies of obvious error in the amber of the truth.”

So next time a client asks why you are doing everything on story cards mention the wooden dogmatisms and the flies of obvious error in the amber of the truth…

declaration of agile independence

At ThoughtWorks we are often engaged by clients to help them get more Agile. We call these gigs “enablement” or “organisational transformation” and that’s often done as part of being staffed on a development project.

One of the challenges we face working with companies who are starting to embrace Agile development is that everyone has got their own idea of what that means. Agile has lots of general principles and standard practices. Things can get crunchy however when we start to make practices practical in a particular environment and practice some of the principles that we preach. When all the fine talk becomes action it can suddenly make clear any challenges with the existing culture and practices. Making these clear and resolving them is one thing but often these lines of friction and confusion remain unstated and people start down paths of sub-optimal practice.

It struck me the other day that while Agile has a famous Manifesto, Agile projects could do with a constitutional document of their own. Something that states what they believe in and how the world is going to be. There’s a time and a place for the endless flexibility of an unwritten constitution but revolutionary change calls for statement of intent. This is especially true in the case of teams that are starting off with Agile for the first time.

I’d like to suggest that the final part of kicking off any agile project is drafting an Agile Declaration of Independence. The key stakeholders gather in a glorious congress (or meeting room with donuts); representatives from IT, the business and the Agile coach come together and specify what Agile is going to look like in that environment. It’s a chance to hammer out some of the uncertainties that there may be and provide a project charter that will help as the team grows. Of course I favour customer collaboration over contract negotiation but this isn’t a contract – it’s the context of our collaboration.

A project declaration of independence might be something along these lines:

We the people of [project name] hold these truths to be self-evident:

That all story points are created equal and can be switched in and out of a release to accommodate change.
That a story is functionally complete when all acceptance criteria are met and that any new acceptance criteria require a new story.
We will plan to iterate over each story 3 times to perfect the usability of each feature.
We shall write tests before code and strive to maintain an 80% unit test coverage.
Developers will pair on stories and strive to rotate around all the functional areas in our system
[and so on…]

This isn’t meant to be a template, each team should work out their own guiding principles and what they will look like in practice but they should cover the main thorny issues on a project:

• How do we manage scope and accept change?
• What is “Done”?
• How are we going to work?

I also think it’s important that there is some ceremony here. Agree  it and sign it at the end of the project inception. Stick it up somewhere in your project room. And make sure somebody uses really big letters because I hear the head of the PMO has bad eyesight…

gol!

The disconnect between business and IT. We’ve all heard about it and we’re all doing something about it, right? We’re embracing Agile, getting Lean and developing cross-functional teams in our bid to deliver valuable software to the people who actually need it.

But I’ve discovered a place where the business and IT don’t meet and I think it’s pretty important. It’s in the product backlog. More often than not this will be a spreadsheet or maybe an excellent tool like mingle (plug plug) with a list of stories in it. Stories are grouped by release and often by functional area too. But it’s pretty unlikely the business case for your project cares about functional areas. It’s got some goals. Maybe one, maybe more than one and with luck these have been quantified and prioritised and used in your planning and story writing.

And then ignored for the rest of the project.

The business value that agile teams are so keen to deliver lies inchoate in the product backlog. I would suggest you can get a idea of what a system is supposed to do from reading the business case. Can you get a good idea of the business case for your project from reading the backlog? There’s the disconnect.

Next time I’m building myself a backlog I’m going to add another property to my mingle story card template: Goal. Each item I put down in my backlog must explicitly reference one of the goals of the business case. During the inception phase it should be easy to report on what percentage of our scope is given over to satisfying Goal A and what percentage to Goal B. We can get  an immediate validation on whether we’ve got our scoping right or have we come up with 100 stories about the least important (but technically most exciting?) feature we could develop. When we do release planning we can again get a quick indication of what the thrust of the release is from a business perspective.

A goal-centered backlog I believe would also give added impetus to employing user-centered design techniques on a project. If one of the goals of the application you are building is to save $500,000 per annum in training costs by having a simpler and easier to use application then the user research, information architecture work and interaction design activities necessary to make something “simpler and easier” need to be in the backlog somewhere. They may not end up as conventional stories but they do need to end up as something that gets done (which incidentally is how I define a story).

fair warning

This morning (Sunday 2nd November) I got the following warning when logging into my email:

Gah!

interface this

I wrote in another place that the more I see those “I’m a Mac, I’m a PC” ads the more I think I’m a PC. This forthright narrowmindedness has meant that I didn’t enter the world of keystroke application launchers until earlier this year. That was when Launchy came into my life and ever since then the way I use a computer has changed out of all recognition.

ALT + SPACE opens the Launchy pop-up. Type in a couple of letters and it suggests what you are looking for, learning from what you chose before, click enter and away you go. I use Launchy not only to open applications but to go to my bookmarked websites and navigate my file system. One very obvious change can be seen on my desktop:

There’s nothing there! All my shortcuts are in folder that Launchy indexes. Any files that appear on my desktop are things that I am working on now or need some attention. My desktop acts like a to-do list or inbox. Once I’ve done what I need to do I file them away somewhere. And if I can’t remember where, Google Desktop will find them next time.

Navigation using the keyboard is fast and very satisfying. So much so that I wish I could zoom around in my favourite apps the same way. Of course in the good old days you could, it was all function keys and hierarchical menus. But webapps are all about clicking, breadcrumbs and the like. Breadcrumbs are all very well if you want to find your way out of an enchanted forest. But this is the space age baby, why can’t we teleport? Some people have started already: there are keyboard shortcuts aplenty in Gmail.

I’m not for a second arguing that we don’t need well thought out, Fitts friendly, intuitive interfaces first up. The value of keyboard navigation is for the power user, the person who feels mastery of the tool and the way it works clickwise. But what an important user community and what a powerful version 2.0 feature! Release your application soon, with your well tested interface, get it working in production and realising business value. Then work with the users to make it better. You’ve probably got a backlog of great features you want to get working on, but the chances are you released with the main functionality already there. Making it faster to switch between projects, view the story tree, look at your other accounts, add items to your shopping basket can make for a compelling experience which differentiates your product from the market or saves your people time.

UX eye for the BA guy

Last week my excellent colleague Cristin Witcher and I presented to the International Institute of Business Analysts (Calgary Chapter) on the subject of user centered design. We had a big crowd and it went down very well – in fact we’ve had two further bookings on the back of it.

The focus of the talk was on Personas and Lo-Fi Prototyping, based on a case study of a recent project that Cristin worked on. To be honest Cristin did all the hard work, I just brought a much needed bald white-guy angle to the proceedings. The bit I liked the most were the examples of good and bad design from the real world that she had found.

One of her examples of bad design was a shot of the interior of a Chrysler PT Cruiser. The challenge was to open the window. Because on the door where anyone who has ever been near a car would expect to find the window controls there was nothing. Instead you had to go hunting (or open the door if you prefer). It turns out the window controls are in the middle of the dashboard. The designers have sacrificed ease of use for originality or creativity. Big woo! All in all a great example of how standards and conventions help us when navigating an interface in the real world or online.

On the up-side was this shot snapped in TW’s favourite Calgary coffee shop, Bumpy’s.

Want to take a spoon, which side do you go for? My suspicion would be the one with the handles sticking out, just asking to be grabbed. This is a brilliant example of Steve Krug’s “Don’t Make Me Think” principle where even without trying to read the labels you can get a good idea of what does what. The interface helps us achieve our goal more quickly.

My main contribution to the proceedings was a shot of the interior of my apartment here in Calgary. It’s great, don’t get me wrong, and it’s got one of those massive North American fridges that makes ice and everything. Trouble is the fridge is directly opposite the broom cupboard and you can’t stand in front of it and open the door at the same time. From anywhere in the kitchen getting something out of the fridge involves the following steps.

1. Open the fridge door in your face
2. Close the fridge door
3. Walk around the fridge
4. Open the door again
5. Take item
6. Close door
7. Walk back around the fridge

I’ve put a photo in the presentation below that makes it a bit clearer. The point I wanted to make by all this is that the Customer who pays for our service is very rarely the User of the finished application. In this case the Customer was the property developer building the condo block. To the developer a big fridge and a broom cupboard are all good things to have in a kitchen and the builder delivered to the specification. The User of the apartment however has a completely different set of goals. Some early user testing of this configuration would have soon pointed out the problems.

Analysts/Designers need to develop workable applications for users, whilst still satisfying our customers who will be paying the bill. This can be a difficult balancing act but the user-centered techniques described in our presentation are a way for us to try and manage this process.

IIBA presentation

if ThoughtWorks was a ski hill…

…it might be a bit like this:

as seen at Panorama Mountain Village, BC, Canada

Getting Agile

I gave my first professional public presentation today at the CIPS Calgary BA special interest group. The title of my talk was “Getting Agile or How I learned to stop worrying and love the index cards” and the subject was my experience in moving from working as an analyst in structured techniques to being an agile BA.

I’ve attached the ppt if anyone is interested (it’s a biggie – 3.5MB!). I talk about what I think is the difference between agile analysis and what I used to do, how I came to understand stories, what makes an effective story and what I do now as an analyst that I didn’t do before.

It all went rather well. We had a crowded room (70+) and many questions at the end. So I’m quite keen to do some more of this kind of thing.

Getting Agile or how I learned to stop worrying and love the index cards.ppt