Around Here Wiki: put your surroundings on the map

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.

Around Here Wiki - Screenshot 1Around Here Wiki - Screenshot 1

Around Here Wiki - Screenshot 1Around Here Wiki - Screenshot 1

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

It’s ok to be second

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.”

5 reasons Agile is like a cult

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.

Agile is like a cult - you have to believe.

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.

Agile is like a cult - the founders will be honoured.

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.

Agile is like a cult - you will have faith in the sacred document.

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.

Agile is like a cult - there are strange rituals and secret handshakes.

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.

Agile is like a cult - you will follow the rulebook.

The path to spiritual salvation is in the bible.

The path to software salvation is in the Scrum handbook.

7 reasons your Scrum Master may be underperforming

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.