William Gill

My second Windows 7 Phone app is here!

I’ve recently been experimenting with developing small apps for the Windows Phone 7 ecosystem. My second app, now available in the Windows Phone 7 Marketplace, takes Wikipedia articles in the area around you and puts them on the map.

Discover what’s around you with a tap. The Around Here Wiki app puts you and all the world encyclopedia Wikipedia on the map: together.

Have you ever walked through an unfamilar city and wondered: “What’s that old building over there?” Just pull out the Around Here Wiki, and you’ll find out.

“Is there anything interesting around here to look at?” Around Here Wiki can tell you.

Around Here Wiki is clean, simple and no-fuss. No fancy effects or unnecessary information – just the facts. Want to know more? Just follow the link to the full article on Wikipedia.org.

You’ll always know what’s around you.

Download it for your Windows 7 Phone here. Don’t forget to rate it!

Facebook was not the first social network. As early as the first dot com boom in the late 1990s companies like sixdegrees.com had launched with services similar in theme and purpose to what Facebook became. When Facebook launched in 2004 from a dorm room at Harvard there were already a number of competing products: Friendster and Orkut were already successful online social networks, and mySpace already had millions of users. In fact, MySpace continued to be the largest social network in the world until 2008 when Facebook finally overtook it.

The iPad was not the first tablet, nor was the iPod the first portable MP3 music player. Google wasn’t even the first web search engine.

What Facebook, the iPad and countless other products like them did was take something that had been done before, and did it better.

Facebook took the concept of online social networking, and added real meaning: your real identity, your real-life friends, and a completely new (and naturally addictive) way to share your life with your network. (It also managed to solve the hardware scaling problems that had hamstrung competition like Friendster).

The iPad took the long sought-after but elusive tablet computer and built a beautiful, functional and elegant device that refused to compromise. A device that rejected the assumption that a tablet was a normal PC with a touch-screen, and had the courage to create a whole new form factor.

The point is: it’s okay to be second. Or even third. New product opportunities often lie in re-thinking existing concepts or products: it’s about seeing what can be done better, and having the courage to take the next steps the others won’t.

Steve Jobs one famously quoted Picasso when he said: “Good artists copy. Great artists steal.”

As readers of this blog will know I’m a big fan of agile and lean software development principles and practices, but have you ever noticed how cliquey the agile scene is becoming? How almost cultish?

Here are five reasons the Agile scene is turning into a cult:

You’re either one of us, or you’re not.

You will read the bible, go to church and believe in God, or you will go to hell. Period.

You will use Scrum or Kanban and believe in Agile, or your software will be buggy, over-budget and crappy. Period.

You will respect, honour and awe the founding fathers.

You will honour, awe and respect the founding fathers. The Scientologists have, for example, loopy L. Ron Hubbard, the science fiction author-turned prophet who continues to convince millions of normal people that Earth is a colony founded by aliens. The followers of the People’s Temple in the 1970s honoured, respected and awed their founding father, Jim Jones. 909 of them swallowed poisoned Kool-Aid in 1978.

You will honour, awe and respect the agile founding fathers. The more often you can use this image in a presentation about agile the better.

You will respect the sacred parchment.

Cults always seem to have a sacred parchment, original manuscript or some other artifact that serves to both prove the validity and authenticity of their beliefs, and also lay down the groundrules for how your soul will be saved.

We have the Agile Manifesto…

You will follow the strange rituals.

Secret handshakes, rituals, traditions, sacred artifacts: these are the cornerstone of any self-respecting cult.

Standups, sprint reviews, sprint plannings, a 3-week lunar cycle…

You will read, follow and respect the rulebook.

The path to spiritual salvation is in the bible.

The path to software salvation is in the Scrum handbook.

What do you need to have a great and effective scrum master on a team?

The Scrum Master is, I think, one of the most misunderstood roles on the scrum team. It’s a critical role to ensure your team will perform at their best.

An effective Scrum Master is not just anyone who wears the Scrum Master hat for a few hours per week. I think an effective Scrum Master should have (at least) these three things:

1. An understanding of what it means to be a Scrum Master (it sounds obvious, but evidently sometimes it’s not). A Scrum Master course is the minimum here, I think. It also includes understanding the agile manifesto, understanding lean principles and the mechanics of software development.
2. An innate, natural desire to learn, improve and be better.
3. The support of colleagues, the team and the organisation to be able to do the job.

I’ve seen a lot of different kinds of scrum teams, and some common themes appear when thinking about under-performing Scrum Masters. Here are some sings that you might not have the most effective Scrum Master:

1. Your Scrum Master is responsible for 7 different teams.
2. Your Scrum Master is just one of the developers who has the responsibility to send the calendar invites to the standups and take notes in the retrospective.
3. Your Scrum Master is just someone from your QA team who puts cards for bugs on the story wall.
4. Your Scrum Master cannot describe the Agile Manifesto.
5. The only contact your Scrum Master has had with scrum or agile is the two-day CSM course (or worse, none at all).
6. Your Scrum Master is not able to realistically change the process within which your team works in order to respond to feedback in retrospectives or improve the way of working for the team.
7. The Product Owner or business owners ultimately responsible for the team and the product are the kind who want all the benefits, such as predictability, increased output and accountability, without changing any of their entrenched, old-school, waterfall processes.

I’m sure there are others, but if you see any of these in your scrum team, you might want to take a look at your setup. Note that these things are not always a problem with the person acting in the role, per se – many of these issues stem from organisational misunderstanding of the role as well.

Have you ever wished your life was a movie? In the movies, there’s always the right sound effect ready to roll for every moment. Sometimes our lives need a soundtrack too.

That’s why I created my first ever Windows 7 mobile application called Soundtrack: Life. You can install it on your Windows 7 phone here.

Soundtrack: Life is an application to let you give your life the soundtrack it deserves. With Soundtrack: Life, you always have the appropriate sound effect or musical score ready whenever your life needs it.

I chose Windows 7 Phone as the development platform mostly because that is now the standard platform for Nokia smart devices, and Nokia is gearing up to announce our first Windows 7 phones at Nokia World soon. I expect the numbers of Windows 7 Phone users to increase dramatically when Nokia starts bringing out great new Windows 7 devices.

Learning to program in .NET (had never used .NET or Silverlight before) was an interesting experience. It proved to me once again that learning something new is a hugely rewarding experience. I don’t much like letting my mind stay idle for too long, and little projects like this keep my energy and attention up.

I’ve got more Windows 7 apps on the way… stay tuned!

We all know it’s important to think of our users first, and that user feedback is important; however all of us have to deal with products, processes and systems in our day-to-day lives in which the user was likely at the bottom of a long list of other priorities during the design phase. Anyone who has been through customs in an American international airport as a non-US citizen can understand what I’m talking about.

In Beijing International Airport, however, they appear to value feedback from travelers. Attached to the booth under the window on every customs desk is a small box with 4 buttons. The text above the buttons reads: “You are welcome to comment on my work”, and you’ve invited to press “Greatly satisfied”, “Satisfied”, “Checking time too long” or “Poor customer service”. In full transparency the custom officer’s identification number is shown directly on the display.

Collecting user feedback at Beijing International Airport

It would be interesting to know what they do with the results: whether they use the outcome to performance manage the staff member, or to identify patterns of satisfaction across different demographics of traveler. Either way, it’s refreshing to see an area that appears to be traditionally nonchalant about user satisfaction take an interest in what people think for the purpose of making the system better.

We all want to get paid.

As ‘free’ continues to become the norm for data, information, apps and services, developers reach to advertising to fill the ‘P’ part of their profit and loss statements. Internet revenue hit $7.3 billion in Q1 this year, according to PwC – so someone must be clicking those ads.

With advertising, more clicks means more cash. We all want more cash – and the two most common ways to get high Click-Through Rates straight away seem to be:

1. annoy, trick, deceive, or
2. make the ad, and with it the experience, meaningful and contextually relevant (that is, give me ads that are relevant to what I am doing that might actually help me complete the task I am performing)

#1 might get you a higher CTR over the short term, but #2 has a much better chance of providing real value to your users and leading to a long-term, sustainable relationship.

When a visitor comes to your webpage, or a user interacts with your mobile app, you have been granted the ever-so-brief attention of a human being. This is a rare and important moment; this is an opportunity for you to build a meaningful relationship with them.

Don’t waste it.

Have you ever heard the question: “Are you doing Scrum? I mean, really doing scrum?” Or: “If I take the Scrum textbook practices, but change one or two things to suit my business, software or people, is that still Scrum?”

At the Agile Lean Europe Unconference in Berlin yesterday there was quite a bit of talk about what Scrum is, and what it actually means to ‘do’ scrum. There was an open space on the topic, where one of the participants said, in response to the above questions: “the answer should be, Who cares?”.

There’s a concept borrowed from Japanese Zen practices called ‘Mu‘. Mu is the third possible answer to a binary (yes/no) question.

“Are taxes good or bad?”

The answer is they are neither good nor bad. The real answer is larger than the context of the question that was asked. The answer is ‘Mu’. What Mu is really saying, is, “un-ask the question”.

Another example: think about a single bit in a read-only memory module in your computer. When the power is off, is the state of the bit 1 or 0? The answer is: it is neither. It is in a Mu-state.

Back to the original topic. “If I change this or that from Scrum, is it still Scrum?” The answer is Mu. It doesn’t matter if it is still scrum or not. What matters is if you are delivering high quality software. If you are measuring that software and iterating. If you avoid waste and decrease time-to-production. If your team is happy, self-organising and efficient. Who cares if it’s “scrum”?

* Note: Robert M. Pirsig speaks about Mu in his amazing 1974 book, “Zen and the art of motorcycle maintenance“.

My Atari 2600 never got a firmware update. Not a single one. Neither did any of the game cartridges that came with it.

In the early days of software, ‘soft’ware was really just a different kind of hardware. It was built, packaged and shipped exactly once. If you shipped it with a bug, that bug would stay there.

‘Softer’ storage types (tapes, floppy disks, etc) and better distribution allowed software companies to release new versions more often. Many years between major versions became one or two years, but updates to a specific version were uncommon.

The internet shortened the cycle even further – turning one or two years to months for many software products, and allowing automatic updates of existing versions to fix bugs, patch security holes, and so on.

Seamless and fully-integrated update and application management technology, like the App Store for Mac, can bring the cycle down even futher – changing months to weeks between updates.

What happens when the cycle is even shorter? Then you get web products. Sites like WordPress.com or Amazon can push an updates to production servers multiple times per day.

How fast are you?

My last post about User Stories and putting the value for the user first in any product decision generated some great discussion on Twitter. As with anything there are some varying views on the topic, and as one example I was pointed to Liz Keogh’s post on user stories.

Liz argues that User Stories should be better named “Stakeholder stories”, as the things you build are addressing the needs of varying groups of stakeholders, only some of which are the end user.

In the creation of any product there are of course many stakeholders who need to be satisfied: the CEO, shareholders, investors, marketing people, the legal department, and so on. In the design of the business, of course the internal stakeholders have the most important requirements. What sort of market are we going into? What segment will we serve? What problem or user need do we attempt to address with this product?

But when you start designing the product that the user will have in their hands, then the user needs to be at the heart of that design solution. Here, the user needs have to come first.

But what about all the stuff that you have to build into products that users don’t want, or even hate? Stuff like CAPTCHAs during registration processes, or advertisements? If the user’s needs come first, why does this stuff exist? To answer this, let’s take a step back and look at where user stories come from.

User Stories are not immaculate conceptions: they don’t just appear out of the blue, but they are thoughtfully created to address needs of the product and the business. On other words, they are derived out of the product vision and the surrounding business model.

If your business model involves monetisation through advertising, then you have a problem to solve: “how can I enable advertising in my product?” It’s clear that the user is not at the heart of the decision to enable advertising, but business models are complex and have to satisfy many stakeholders and solve many problems. At the business strategy level, the end-user is only one of multiple players, and the user doesn’t always come first.

So you have this problem: you have to enable advertising. How do you solve it? Do you slap a full-screen takeover banner for some random personal hygiene product on your start screen? Probably not. Do you enable Google AdWords to show advertisements relevant to the content in a meaningful way? Getting warmer. Do you study the user’s interaction on the page to determine where the advertisements should be placed and how they should be visually displayed to ensure that users understand what is a sponsored link and what is your own content, to avoid frustration and confusion from the end user and maximise the meaning and value they get when they interact with the advertising? Better still.

What is at the heart of each of these decisions? The user. This is where the user comes first – in the design of the solution to the problem. In the User Story.

User-centric design doesn’t absolve you (regrettably) of the need to be aware of the business context or the constraints of your business or industry: it merely proposes that the user is at the heart of how you solve your product problems and how you work with the constraints. Keeping the user at the centre of your user stories by insisting they start with “As a User…” helps you stay focussed on the people who will be interacting with the stuff you’re building.