Author: will

The focus manifesto

Posted on by will

Do you ever feel like you’re rushing from one thing to the next, without really doing any one thing properly? Are you running from one social appointment to the next without taking the time and attention to enjoy each one? Is your desk like a constant fireworks show of new emails, instant messages, phone calls, sms notifications, flashing lights and pinging noises, all begging for your attention?

This is sadly all very, very familiar to me.

I just finished reading Leo Babauta’s Focus Manifesto. It’s all about “finding simplicity in the age of distraction”, which screamed out to me straight away. His basic premise is that distractions and noise are killing your creativity and limiting your potential. He argues that the best way to get more done is to do less. Leo talks about being constantly connected to the cloud as an addiction, one that must be treated just like any conventional addiction.

I think I’m often trying to go too fast, without taking the time to really take in what I am doing. This goes for both my work and personal life.

At work, I have a ton of different projects on at once, people coming to me all through the day needing questions answered, issues resolved, priorities decided, and a constant stream of emails, meeting requests, instant messages and phone calls. I quite often leave the office at the end of the day and I’m disappointed and frustrated that I haven’t gotten enough done, even though I know I was working at 110% the whole day. Now I realise that I’m not usually frustrated because I haven’t gotten enough done, but rather because I’ve not gotten the right things done. I can quite easily spend an entire day poring over emails, answering IMs, and sitting in meetings. In fact, there are so many emails that I feel like I’m moving at a hundred miles an hour just to read them all, let alone reply. And at the end of the day, I’ve written and read a lot of emails, but the important stuff hasn’t been looked at. The good stuff… and, you know what, it’s the fun stuff too! But it doesn’t get done, because it’s too easy to get trapped in the distraction trap.

Leo’s focus manifesto has a ton of practical suggestions on how to clear your mind and your desk (figuratively and literally) and focus on the right things. The things you want to be doing – the things that make you happy and satisfied. He also talks about solitude and time for reflection as being super important for recharging your creative batteries.

And best of all – Leo’s book is free!

Starting tomorrow, for example, I’m clearing off all the crap off my desk to create a bit of clean space – and then I’ll be on to my calendar with an axe…

Personalisation is not overrated

Posted on by will

I came across this very old article about personalisation of websites from 1998: http://www.useit.com/alertbox/981004.html

The article discusses the fad of website personalisation that was sweeping the web back in the late 90’s. Back then, many websites were making the first efforts to personalise the web by giving complex personalisation options to users, through which the website could decide which content to prioritise and so on. He goes on to say that personalisation in this form is pretty much overrated, as the majority of users consider filling out large questionnaire type option screens far too unwieldy and confusing. He does give two situations where personalisation can work, that are characterized by being:

  1. very simple to describe in machine-understandable ways, and
  2. relatively unchanging

To this list, I would add a third characteristic: silent.

Flash forward to 2010: personalisation is alive and well all over the web. The difference today is that there are no more long-winded options screens to tell the website who you are and what you like and don’t like. All that information and more is available on the web, for free. Your Facebook account holds more personal information about you than anywhere else, and it’s almost certainly more than you think. Add to that your web usage habits, what you click on, who your friends are, and what other people who are similar to you did, and there is more information than ever to offer you a fully personalised experience. From the ads that you see on Facebook to the books Amazon tells you to buy; nearly everything you see on the web is specifically targeted at YOU. But it’s silent… you don’t even realise it’s happening – and that’s the beautiful (and scary) part of it.

So what does this mean for experience designers? Well firstly, we should realise that this extends beyond the realm of advertising. We have access to so much of this information, and we can design user experiences that are unique, personal and delightful. (And we can do it without compromising user’s privacy).

I think there are five levels of data that we can look at about our user when designing their experience:

  1. Who you are.
  2. Things you do.
  3. Things your friends do.
  4. Things the crowd does.
  5. External factors.

Let’s look at some examples:

Who you are:

  • where you live
  • where you went to school/university
  • your interests/likes/dislikes
  • relationship status

Most of this is available publicly through your Facebook profile. If your product has it’s own profile service, then it can be aggregated with the information available from Facebook to create a very healthy set of data about who your user is.

What you do:
This is relevant to the specifics of your service. Let’s assume we’re looking at an online mapping application.

  • What you search for (search queries – places, categories) – collect all categories and rank the most searched for categories/regions
  • What you click on
  • Where you check in (category, region)
  • What features of the service do you use 
  • What you ‘like’, rate or review

What your friends do:

  • Again, relevant to the specifics of your service. 
  • Places your friends have been to (category, region)
  • Places your friends ‘like’, rate or review
  • Combine with your friend’s ‘personal’ data amalgamation (see above)

Things the crowd does:

You can learn a lot by watching the behaviour of the crowd. We’re talking generalisations, yes, but these can be refined based on your user’s profile to form quite valuable predictions of user’s future behaviour.

  • People in this area also tended to go to these other places… or of the people who checked into Subway, 40% also checked in to Starbucks, etc
  • People who looked at this place, also looked at these other places (Amazon style recommendations)

External factors:

  • Where you are (this is the most obvious and necessary one)
  • Time of day (prioritise lunch places midday, bars in the evening, etc)
  • Time of year Weather (if it’s raining, snowing, sunny, warm, cold, etc)

By watching carefully what individual users do as well as what the crowd does, and combining this information with your user’s profile information, you have a powerful platform for creating a personalised experience. How to turn this data into something meaningful would be the topic of another post… 

The right to satisfaction

Posted on by will

If you’re not happy at work, I think you have two choices. You can either:

  1. take an active role in making things better, or
  2. leave.

Everyone has the right to improve their own situation. If you see problems or difficulties at work, you can raise your voice and help find constructive solutions.

But if you’re going to respond to every initiative with innate cynicism; if you’re going to sit in every meeting and complain about your colleagues; if you’re going to spread rumours and dissatisfaction and nurture dissent, then I think you owe it to yourself to leave. Now.

Life is way to short to sit in a job that leaves you unsatisfied.

A half product is better than a half-arsed product

Posted on by will

Most software projects have a deadline of some kind, and only the very lucky few don’t have a budget. In this landscape that leaves two things you can compromise on: features, or quality.

The temptation is always there to try for as many features as you can. Rush to cram them in. Squeeze, push. Race to the finish line, push it out. 

The problem is that when you’re rushing, when you’re cramming, other things tend to get dropped. Unit tests don’t get included. The testing team get new features to test on the last day before release, and can’t really test it completely before it’s released. Defects that would normally be fixed are deprioritised due to time. 

Sound familiar? It does to me – I see it every day.

Why do we always let ourselves try to do everything?  Instead, why don’t we try thinking about our feature set? Chances are we can survive with a smaller feature set. 

Design what can be realistically achieved to the best level of quality in the time you have available. It’s better to launch a half-product, than a half-arsed product. 

The danger of cc and reply-all

Posted on by will

I got an email the other day, adressed to me with a mailing list of all the other Product Managers from our site in cc, that started with the words: “Actually, that’s completely wrong.” It was referring to my previous mail to a small group where I had made a comment about the readiness of a particular component to be integrated. It wasn’t just the arrogant, schadenfroh tone that irked me, but the sudden inclusion of the complete mailing list in cc. “Hey look, everyone, he was wrong!”

When you put people in cc on an email, you are making a statement. Always. The cc list can completely change the meaning and intent of an email… Who you include is often almost as important as what you say. So please be careful…

If you write to a colleague to give not-so positive or negative feedback, and you put their manager in cc, it is an escalation. If you don’t put their manager in cc, it is colleague-to-colleague feedback which has a much lower chance of provoking a defensive reaction.

If you write to a colleague to give positive feedback and you put their manager in cc, it can often increase the weight or worth of the feedback significantly.

When you answer an email with a reply all, especialy when you want to critisise or disagree with a point of view, etc, including everyone is a a statement that you want everyone to know that you disagree. This can sometimes be constructive, but if you intend to attack an idea or point out how someone was wrong, it can quickly look immature and cheap. 

Replying all to point out someone’s failure or weakness is like when you used to run to mum and dad as a child to tell on your sister whe she did something she wasn’t supposed to. It might feel satisfying for a minute, but at the end of the day you will end up looking like a child.

Recurring impediments

Posted on by will

Last week I wrote about impediments, and making sure you go through them every day at the daily scrum standup. As I was discussing blockers with my team over the past week I noticed (again) that most of these impediments are recurring… they seem to crop up nearly every sprint.

Scrum teaches us about the impediments log, which you keep during a sprint to track the burndown of impediments. Even more interesting, I think, is to track a history of your impediments over time. Which ones turn up often? Which ones seem to cause the most interruption/downtime? What common themes are there?

This information becomes perfect input for retrospectives or general continuous improvement, and you can easily see the issues that are the most problematic or recurrent, and tackle them first.

Change the unchangeable

Posted on by will

In an environment where so many people avoid decisions, shy away from responsibility and avoid asking hard questions, the people who do this well stand out.

Shake a few trees. Take a risk and raise a tough issue. What’s really stopping you? What are you afraid of?

Politics? Don’t want to make an enemy? The times in which trolls and power seekers can gain influence without creating and delivering are slowly but surely coming to an end. The Internet has relativised the playing field, and our creations and art speak for themselves.

Afraid that you’ll look silly or uninformed? If you raise your hand you will almost certainly be wrong from time to time. Maybe even often. But recovering from being wrong with grace and dignity and learning from your failures is far more valuable to you and those around you than sitting silently.

Do you believe it’s unchangeable? That the status quo is unquestionable and immutable? It’s not.

True, you want to pick the battles you can win. But pick one. Try it. Look around you, and pick one thing that has been bugging you but you have always considered unchangeable – then change it.

What’s getting in your way?

Posted on by will

The daily scrum standup is about answering three very simple questions:

  1. What did you do yesterday?
  2. What are you going to do today?
  3. Do you have any blockers?

All three questions are important, but you know what… this is another great case where the whole is greater than the sum of its parts. It’s the combination of all three that make the standup as effective as it can be. 

I often see the third question get dropped from standups. I think developers naturally want to downplay impediments… I think they want to feel that they can solve them, no big deal. But the thing about forcing developers to articulate the things that might get in their way is not only so the Scrum Master or Product Owner has the opportunity to comment or act on them… the act of talking about your blockers forces you to think about it actively, and quite often things will come up that the developers themselves weren’t really aware of. 

On top of that, undiscussed impediments are like little icebergs floating around in your sprint… icebergs with which you will most certainly collide on the afternoon before the sprint demo, when you have no time to respond in order to save the sprint. Keeping an up-to-date impediments log is the best way to avoid nasty surprises on sprint demo day.

What gets in your way?

Scrum is not a solution to your problems

Posted on by will

Scrum won’t solve all your development problems. Even if you implement 100% of the Scrum textbook (and most companies don’t), it won’t fix a broken development environment overnight.

Scrum process just helps to bring your problems to the surface so you can see them and deal with them. It’s all about exposing problems and issues, so you can identify them and do something about them. Scrum process aims to ensure that problems can’t fester unnoticed – but are brought to the attention of the whole team very quickly.

  • Scrum roles force defined and logical team roles and work division. You know exactly what you expect from a Product Owner, and he knows what is expected of him. If someone on the team is not fulfilling their role, it’s easy to spot, allowing you to do something about it.
  • Scrum meetings ensure that the team meets and discusses the appropriate things at the appropriate time. If the specifications are incomplete, if the stories are unclear, if the product vision is not defined – you will know it in the Sprint Planning meeting when the team can’t accept any stories. 
  • Continuous integration ensure that your development environment runs smoothly and minimises downtime or team-blocking integration issues. If there are intrinsic problems in the architecture, if the code is too brittle or if there are skill deficiencies in the team, you will see it in the CI environment.
  • Sprint demos give the team a target for a sprint and an opportunity to regularly celebrate what has been achieved as a team. But… if there are problems in the development team, if there are skill deficiencies or if the team is being blocked or interrupted, you will see it quickly at the sprint demo with the amount and quality of the stories that were completed.
  • Regular releases allow you to respond to your customers and stakeholders faster, and fix bugs or problems quickly… but if the team is not quality-conscious from end-to-end, you will see it in the quality of the code that is released at the end of the sprint.
  • Sprint retrospectives give everyone a chance to look back and think about what went well and what can be done better. Issues and team blockers will be raised by the team, and problems that don’t get fixed will get special attention…

It’s all about making the problems visible. Scrum won’t solve the problems that you have – that’s your job. 

Why the Product Owner is not the Scrum Master

Posted on by will

Despite what is often the case in software organisations, a Product Owner is not a Scrum Master. To me, the two roles are both absolutely critical to the success of a scrum team, but they are not only very different, but quite often contradictory.

The Scrum Master protects the team from interruptions and blockers and facilitates their working together both within the team and with other teams. The Product Owner sets the direction of the team and the vision of the product and defines and prioritises the backlog based on product needs and input from stakeholders. 

Mike Cohn describes it by drawing a comparison to a pirate ship: if you consider the ‘management’ tasks that need to be taken care of on board Blackbeard’s Queen Anne’s Revenge, there were two main types: Star tasks (risk-taking, planning and strategic), and Guardian tasks (protective, ‘crew’ support tasks). 

The team should see and know the difference…

You can read the full article here.