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.

Posted in Agile, Scrum | Tagged , , , , | 4 Comments

Soundtrack: Life – give your life a soundtrack

Soundtrack: Life - give your life a soundtrack

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.

Soundtrack: Life - give your life a soundtrack
Soundtrack: Life - give your life a soundtrack

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!

Posted in Mobile, Windows Phone | Tagged , , , , , | Leave a comment

Customer Feedback is important

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

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.

Posted in Agile, Product Design, Product Management | Tagged , , , | 1 Comment

Advertising – the good and the bad

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.

Posted in Product Design, Product Management, Software management | Tagged | Leave a comment

Who cares if you’re doing scrum or not?

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

Posted in Agile, Scrum, Software management | Tagged , , , | 2 Comments

Software update cycle: faster every day

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?

Posted in Agile, Continuous delivery, Software management | Tagged , , , | Leave a comment

SCRUM User Stories, Part 2: User value over business value?

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.

Posted in Agile, Product Design, Product Management, Software management | Tagged , , | 3 Comments