Devoted Developer

How To Write Effective Emails

noreply@blogger.com (Magnus Nord) — Wed, 02 Jan 2013 15:28:00 +0000

Email has for many become the curse of today’s paperless office. They pile up faster than you can process them. The fact that many emails are impossible to understand, or completely pointless, doesn’t help.

This post lists five principles that will help you write more effective emails that benefit both you and the reader.

Paired with effective filtering and inbox management you stand a much better chance of persevering on the email battlefield.

Concise but Courteous

As people’s inboxes grow ever bigger, being concise and to the point becomes increasingly important to help people manage the mail flood.

An email that is too short might come across as rude and arrogant. You want to be brief and to the point, but a minimal level of courtesy is assumed and also makes conversations easier to follow.

Review the email before you hit the send button. Check spelling. Make sure you understand what you’re trying to say yourself. If it is an important email with many recipients, consider reading it out loud.

Here’s an example of a concise and courteous email:

John Doe <johndoe@devoteddeveloper.com>
to me

Jane,

Could you please send me the latest draft of the SoW?

Thanks,
John

Separation of Subjects

Only address one item in an email. If you have more things to cover, consider sending separate emails.

While this increases the total amount of emails, each one becomes easier to follow and process. Potentially, it also reduces the number of people included in topic threads.

Assist the Addressee

Make it as easy as possible for the reader to understand what she needs to do.

Start an informative email “FYI” (For Your Information) or “NO ACTION REQUIRED”. In a similar manner, state actions or requests clearly.

Make use of paragraphs and formatting such as highlighting.

Here’s an example:

John Doe <johndoe@devoteddeveloper.com>
to me

(NO ACTION REQUIRED)

I have talked to Jane about the plan, and she had some comments that we will discuss at the project meeting next week. Please note that the meeting tomorrow is cancelled.

BR
John

Carbon Copy Correctness

When sending an email to multiple recipients, make proper use of the CC (Carbon Copy) field.

Don’t put people that are main recipients in the CC field and vice versa. For example, don’t add people to the CC field if you delegate an action point to them.

As a general rule, treat the CC field as a FYI field.

Always start emails with the addressee’s name. Not only is it courteous and makes the email more personal: it also helps when you CC people. It is easy to overlook that you have only been copied. Stating the primary recipient clearly upfront helps recipients process the email appropriately.

Recipient Restraint

Show restraint when adding people to the recipient list.

Sometimes it is better to forward an email with “FYI” instead of copying people on the original email. For example when you predict a long conversation with someone abusing “reply to all” and you only want to inform a third party of the initial email content.

If people are added mid-conversation it might be helpful to state it in the email somehow. For example writing “+John” if John is added to the thread. Here’s an example of that:

John Doe <johndoe@devoteddeveloper.com>
to me, Aaron

Jane,

+Aaron (attended the last meeting)

Good to hear you make progress. Please share the document with both Aaron and me.

Thanks,
John

John,

We have started working on a draft for the SoW. We will share it with you when a first draft is ready.

BR
Jane

That’s all for now. Add a comment below if you have your own tips on how to write effect emails!

Make sure to check out the post about Zero Inbox and Gmail as well.

Zen of Scrum: The Sprint Setup

noreply@blogger.com (Magnus Nord) — Fri, 16 Nov 2012 20:16:00 +0000

In Scrum, you develop product increments in short iterations called sprints. The sprint is a very central concept in Scrum: everything revolves around it.

In this post I talk about sprint length, preconditions for a successful sprint, and what to do when a sprint falters.

Each sprint starts with a planning event which I covered in an earlier post. The sprint ends with two other meetings: the sprint review and the sprint retrospective. Those will be covered later. These three events are part of the sprint, and make out the sprint boundaries.

Sprint Length

The length of sprints is frequently debated.

Both long and short sprints have their merits, but a sprint should never extend more than four weeks. Longer than that, and it becomes difficult to oversee scope and prevent outsiders from changing priorities.

Three things affect the appropriate sprint length:

The complexity and type of product being built
How experienced the organization is with Scrum
How frequently priorities and scope change

Some people argue that shorter sprints cause too much overhead. However, shorter sprints means shorter meetings. For example, the rule of thumb for the sprint planning is sprint length in weeks x 2 hours. That is, a two week sprint equals a four hour meeting.

Whichever way you decide to go eventually, I strongly recommend shorter sprints for new Scrum teams. It gives you a chance to “go through the motions” more frequently.

Can you think of other benefits with shorter or longer sprints?

Sprint Rules

Once the team starts implementation no changes that affect the sprint goal should be made.

If the goal change it affects efficiency negatively. Do it often and it affects morale as well, and eventually developers will stop caring about commitments.

The same is true if the team composition changes. If someone is abruptly removed from the team, or works in two teams simultaneously, it hurts productivity.

Another very important rule is that the quality goals are not allowed to change in the middle of a sprint. A team that decides to skip quality to meet the target causes two major problems:

They risk introducing defects and other technical debt into the code base
They “lie” about their velocity and hence depicts the wrong image of progress to the product owner and other stakeholders

You often get objections about these rules from outsiders: stakeholders, project managers and sometimes product owners.

“The team should welcome change, that’s the whole point with agile, isn’t it?”

“We need John Doe to do this now, ok? It’s more important than this other project right now.”

I think these are signs of other organizational problems, rather than reflecting a true need.

I think these are signs of other organizational problems, rather than reflecting a true need. If management doesn’t have the two-four weeks foresight of a typical sprint, or lack the courage to hold back decisions during that time, it is a management issue – that should be addressed promptly.

That said, it’s perfectly fine to renegotiate scope during the sprint. To clarify and discuss stories as more knowledge is gained. It can even be ok to add new stories to a sprint if it makes sense, and other work of roughly the same size is removed.

It might also be ok, as a last resort, to cancel the sprint altogether. Before doing that, think it through carefully and consider the sprint emergency procedure, first worded by Jeff Sutherland.

The Emergency Procedure

Sometimes a sprint stops making sense: perhaps because nothing gets done, or because the sprint goal becomes obsolete or irrelevant. Other times the team simply realizes that they won’t be able to finish all the stories committed to.

The first thing to do if this happens is to look for impediments and try to remove them: to optimize the way the team works.

If that doesn’t work, perhaps it is possible to get help from outside the team. For example, if the team can’t solve a particular problem, perhaps an architect or a domain expert can help them get passed the hurdle.

The most common approach, however, is to reduce scope. This should be done in the light of the sprint goal: is it possible to do a delivery that is meaningful despite cutting some stories?

Don’t reduce the scope without first considering impediments and trying to get outside help. Removing impediments will help the team in future sprints as well. Getting outside help fosters collaboration and brings new insight to the team.

In the end, if nothing can be done to salvage the sprint, it might be better to cancel it and start over. If you do so, make sure that the new sprint is better planned with a more realistic goal.

That’s all I got about the sprint setup. Next time I’ll talk about the inner workings of the sprint: the daily scrum and the sprint backlog. Ciao!

Zen of Scrum: Backlog Grooming

noreply@blogger.com (Magnus Nord) — Sat, 20 Oct 2012 18:41:00 +0000

Last time I wrote about sprint planning which is one of four formal events prescribed by Scrum.

In this post I explain what product backlog grooming is, when it is performed, and how it is done.

Backlog grooming is often performed throughout the sprint. Perhaps this is one reason why it’s not considered a formal event.

However, many teams do backlog grooming as an explicit meeting, and some people think it should be incorporated as a formal meeting in the guide, too.

In fact, as pointed out at ScrumCrazy, different types of backlog grooming often takes place side by side.

What?

The goal of backlog grooming is to keep the backlog updated with enough “ready” items at the top.

For a story to be “ready” to be given to a team, I think it should at least fulfill the INVEST rule.

A good rule of thumb is to have at least 1.5 sprints worth of backlog items prepared before sprint planning.

For a multi-team configuration, it might be necessary to plan 2-3 sprints ahead to handle dependencies between teams.

As Angela Druckman points out in her article, it might also be a good idea to do long-range technical planning.

Some people mistakenly believe that doing Scrum means never focusing on anything but what is coming up in the next sprint. This is not true.

How?

The goal of a grooming session can vary, depending on the current needs. Some points worth considering are the ones outlined by Roman Pichler at All Things Product Owner:

1. Analyse the customer and user feedback
2. Integrate the learning
3. Decide what to do next
4. Create small stories
5. Get the stories ready

When?

Try to avoid doing backlog grooming at the very beginning or end of sprints.

Another post at ScrumCrazy discusses some good reasons why:

During the first 20% of the Sprint, the team is just getting started on this Sprint's work, so you'll want to give them some room to get a good start. During the last 20% of the Sprint, the team is working hard to get closure on the current sprint items, so that's not really an ideal time to do it either.

Whether you do backlog grooming as a specific meeting, or continuously throughout the sprint, is really up to you.

Most likely, though, you will find yourselves doing both informal grooming and a more formal weekly grooming. I find this meeting a good preparation for sprint planning. It highlights lurking ambiguities, which allows you to rework unclear stories in good time; keeping the planning session shorter and more effective.

That’s it for product backlog grooming. Next time I’ll cover the sprint: sprint rules, emergency procedures, and a little about the length of sprints.

Don’t forget to check out the Zen of Scrum slideshow over at SlideShare.net.

Gmail Zero Inbox Setup

noreply@blogger.com (Magnus Nord) — Sat, 20 Oct 2012 11:18:00 +0000

As I begun my new job, I moved to Gmail from Outlook. I also upped my daily email barrage.

Zero Inbox suddenly became very relevant again.

Setting up Gmail, I hade these three goals in mind:

Keep the inbox to zero while still using it as a dashboard for things to keep track of.
The ability to send emails to myself as reminders (imho, better than using a secondary todo application).
Make processing information as easy as possible

And this is the prize we’re after:

This is what the Inbox looks like with this setup (click the image for a larger version).

The Unread section is the “real” inbox. This, and the mandatory Everything else section, is empty after processing emails.

The other sections are more or less GTD contexts. One for conversations I need to follow up. Another for all other things that need my attention.

Configure Labels, Stars and Filters

Of course you want labels! Personally I have two types of labels:

Based on what I want to do with the message: @action, @follow (@waiting-for), @ref, @review. (I also use stars for some contexts, as I will explain later.)
Based on the context, project, and so on, where it belongs. For example specific to a team, forum, software release, and so on – depending on what makes sense.

Another lab feature gone mainstream in Gmail is custom stars. Instead of only a yellow star, you can use exclamation marks, question marks, different colored stars, and so on.

Enable this feature from the General tab in Settings. I use the stars in this way:

The exclamation mark for things that need my attention, for me to take action.
The information symbol for things I should review.
The question mark for things needing clarification, where I need to get more information (this is really just another action, and only using the exclamation is probably enough).
The yellow star as a “catch all” for things I want in the Starred section, but is related to a label.

The reason why I use stars instead of labels will become clear shortly.

I use filters in conjunction with the setup to accomplish two things:

Mark mails sent to myself as an action/todo: this will star it, add the label @Action and mark it as read.
Mark mails copied to me as a follow-up item: this will add the label @Follow and mark it as read.

Action Filter

Choose the drop-down arrow right to the search box to show the advanced search options and follow the steps below.

Fill in the From field with your own email address (if you have multiple aliases, make sure it’s the address being used as the from-address.)
Fill in the Doesn’t have field with your email address prefixed with “cc:”

cc:youraccount@gmail.com
Click the Create filter with this search link
Here, mark Mark as read, Star it and Apply the label: @Action
Click the Create filter button

Follow Filter

This is very similar to the action filter. So, from the drop-down arrow right to the search box:

Fill in the From field with your own email address (if you have multiple aliases, make sure it’s the address being used as the from-address.)
Fill in the Has the words field with your email address prefixed with “cc:”
cc:youraccount@gmail.com
Click the Create filter with this search link
Here, mark Mark as read and Apply the label: @Follow
Click the Create filter button

Set Up Prioritized Inbox

The prioritized inbox feature groups emails into configurable sections.

The only problem (Google: Fix!) is that the number of sections is limited to four. Otherwise you could, for example, set up one section per label.

This is the main reason why I use stars instead of labels.

The other two sections are “unread and important” and “everything else”.

By clicking the down arrow at the top right of the Everything else section, you can easily archive all items.

Enable Keyboard Shortcuts

This setting is also found under the General tab.

Once you learn the most important shortcuts, it will really speed up processing emails.

A complete list of the keyboard commands can be found here.

The keyboard commands can be displayed by pressing ? (question mark). So, that’s really the only shortcut you have to remember to start with.

So this is what my Gmail inbox setup looks like at the moment.

Please share your own ideas on how the setup could be improved by dropping a comment below.

Zen of Scrum: Sprint Planning

noreply@blogger.com (Magnus Nord) — Sun, 30 Sep 2012 20:33:00 +0000

Every sprint begins with a planning activity. This is when the Scrum team decides on the work to be done in the iteration ahead.

Sprint planning is divided into two parts.

During the first part user stories are analyzed, evaluated and estimated. After that, the developers determine a reasonable workload that they think they can commit to.

During the second part, selected stories are analyzed in more detail by the developers (remember, I use the term developer for everyone building the product, including coders, designers, testers, documenters, and so on).

How long the sprint planning takes is of course individual from team to team. A good rule of thumb is to timebox each part to the same amount of hours as the length of the sprint in weeks.

For example, a two week sprint would render a four hour meeting (two hours for story selection, and two for task break-down).

At the end, the developers commit to a number of stories and – equally important – to the sprint goal.

Part One: Selecting the Stories

So, during the first half stories are selected.

At the beginning of the sprint planning, the product backlog should already be ordered and contain enough stories that are sized correctly.

Selecting, in this context, means figuring out what the developers can commit to. The first step is to estimate the top priority stories.

It is possible, and perfectly all right, that the order of the user stories change during the meeting. Perhaps it turns out that one of the stories need to be analyzed further, or dependencies come to light as stories are discussed.

Preferably as many of these findings as possible are discovered during backlog grooming (which I will discuss in the next post).

Together with the team, the product owner can also decide if other work should be conducted, for example bug fixing or efforts to reduce technical debt.

The Scrum team should also formulate a sprint goal: a high-level goal that defines the success of the sprint. This can be pretty much anything, but I think it helps if it’s catchy and builds a “Let’s do this!” feeling.

Part Two: Identifying Tasks

During the second half of the meeting, developers work together to break stories down into tasks. At this point, the product owner does not have to attend but should still be available to answer any questions.

While user stories are fine for course-grained estimations, and for release planning, they usually don’t cut it in order for the team to commit to a sprint. Neither are they sufficient for monitoring sprint progress.

I think one reason why new teams resist task break-down is that they tend to overdo it.

Some teams think it’s unnecessary to break stories down into tasks.

While there might be many reasons for this, I think one is that new teams tend to overdo it.

It is important. However, don’t overanalyze each task or have everyone give an estimate for each.

One good approach is to do this in front of a whiteboard, with post-its. Have everyone add and estimate tasks, pretty much like a brainstorming session. If someone thinks an estimate is off, discuss that task: either as a pair, or the whole team.

When estimating tasks, I find it effective to use a scale the same way as with user stories. For example, tasks can be estimated to 0, 1, 2, 4 or 8 ideal hours. Estimate effort, not calendar time!

Another approach could be to estimate tasks in pair. However, I like to involve the whole team as long as it doesn’t mean overanalyzing or extended discussions about estimates.

Preferably one task shouldn’t take more than one work day to complete. If you keep the tasks small, most of them are completed by the next daily stand-up. Progress becomes tangible which, if nothing else, is motivating for the team.

Another point to remember is that tasks may very well be added, or broken-down further, during the sprint.

At the end of the second half, the team should have a sprint backlog (a number of user stories, tasks for each story, and a sprint goal) that they can commit to.

That’s the sprint planning.

Next time I’ll write about product backlog grooming. In the meanwhile, don’t forget to checkout the slideshow at SlideShare.net.

Zen of Scrum: When Estimating, Size Matters

noreply@blogger.com (Magnus Nord) — Mon, 17 Sep 2012 21:00:00 +0000

“Time is what we want most, but what we use worst.” –William Penn.

Never is it more true than when it comes to estimating.

Indeed, to most people estimating effort is tightly coupled to time. How long will it take? When will it be ready?

This is futile: time is a moving target and calendar time, in particular, next to impossible to predict.

A better approach is to estimate the size, or complexity, of work, and to derive duration based on velocity.

Agile Estimating

There are three keys to agile estimating:

Items are estimated relative to each other, rather than absolutely.
Duration is derived rather than estimated directly.
Estimating is an ongoing activity, not an isolated task at the beginning of the project.

These points are described in the sections below.

Relative Estimations

Think about painting a house.

If asked “How long does it take to paint this house?” you might start by looking at one room and say “This room will take about one hour to paint.” Then you move on to the next room “…and this one will probably take two hours.” And so on.

When you start to work, it turns out the paint is not as easy to apply as first thought. It will take much longer, and you are forced to do a new estimation for each room.

Now, if you would have started by estimating size instead, comparing the rooms to each other, it might have sounded something like this:

“Let’s say this room is a three.”

“This room is a little bit smaller, let’s say two.”

“Now, this is twice the size of the first room. Let’s call it a five.”

And so on.

You haven’t said anything about how long it will take to paint the house.

Now, when you start to paint and finish the first room in X hours, you can easily derive how long it will take to paint the whole house: simply add up the sizes of all the rooms and multiply by the time it took to paint one unit.

Project Velocity

In a similar fashion as the example above, you can calculate the project velocity by looking at how much work the teams can finish each iteration.

Using the velocity you can predict when all the estimated work will be done.

Estimate What You Know

In traditional project models you estimate all the work upfront, in the planning phase. This might work in a well known and predictable environment. Alas, software projects rarely fit that description.

In fact, the beginning of the project is when you know the least, and as a consequence, the accuracy of the estimations are poor. This is expressed in the cone of uncertainty.

Agile methods acknowledge the difficulty of doing accurate estimations upfront.

While work in the near future is estimated in detail, work further away is only estimated roughly.

User Stories and Epics

In the previous post, I wrote about user stories as one possible type of backlog item. User stories are often estimated using story points. However, other backlog items can also be estimated using story points.

Story points can be pretty much anything. Many people use the Fibonacci series (0, 1, 2, 3, 5, 8, 13, …) while others multiply numbers by two (0, 1, 2, 4, 8, 16).

You can also use T-shirt sizes or something else.

It should be a predefined set, though, and you shouldn’t depart from it.

It’s a good idea to have larger gaps between the numbers as they grow, as it’s more difficult – and less meaningful – to make accurate estimations of larger items.

Planning Poker

Planning poker is one way to quickly estimate backlog items accurately.

When playing planning poker, many teams start with long discussions about the stories.

I don’t think that’s the best approach.

Instead, start by giving a first estimate right off the bat: don’t discuss the story at all. If everyone’s estimate converge the story is probably pretty well understood, and you don’t have to discuss it further there and then.

Remember, once you’ve done the task breakdown (that typically follows estimating stories during sprint planning) you can always go back to the Product Owner and re-negotiate any commitment.

You will find, though, that you seldom have to.

Another benefit of this approach is that team members do a first estimate without being affected by others.

Story Splitting

Sometimes it is necessary to split stories into more manageable sizes. Epics, for example, typically need to be broken down as they are about to be implemented.

Stories can be split in many different ways, but don’t forget about the INVEST mnemonic from the previous post. Some ways to split stories are:

Across boundaries, for example operational, data and interface boundaries
By removing cross-cutting concerns such as logging and exception handling
Into functional and non-functional aspects

When unsure of a technical implementation or when you feel further analysis is needed to correctly estimate a story, consider a spike.

Next time I’ll write about the sprint planning.

2 Steps Towards Productivity Bliss: Wrap-Up

noreply@blogger.com (Magnus Nord) — Sun, 09 Sep 2012 19:19:00 +0000

In two previous posts, I have described what I think is necessary to become productive: getting organized and stopping procrastination.

It’s time to wrap it up with a summary. I will also offer a bonus tip that, while it may not be necessary, certainly helps gather the strength and energy to stay productive.

But let’s start with a summary.

Summary

Getting organized and stopping procrastination boils down to three key parts:

Collect. Retrieve and store incoming information in a system you are comfortable with. The system should be as simple as possible while still being able to collect all the stuff coming your way.
Process. Once you have the data in a system, you need to process it. This is not a one-time task: it needs to be done continuously. It is best done at different levels and intervals. You probably want to go over the things closest at hand daily, and also check your email and so on for new input. Weekly, perhaps, it is wise to process new, and review existing, information.
Focus. To work efficiently you need to be able to focus on the task at hand. This means minimizing interruptions and stopping procrastination. It also means taking deliberate breaks regularly to regain energy and clear the mind.

Where to start depends on the kind of work, and is situation-dependent.

If you mainly work on a few big tasks or, for example, in a development team, and you feel the problem is mostly related to interruptions, whether they are internal or external, it is more worthwhile to start looking at how to improve the ability to focus.

If you have a lot of projects going on and procrastinate because you don’t know where to start, it may be a better strategy to start top-down and collect all the information and figure out the next steps for each project. Then try to get the ball moving by picking off one actionable item at a time.

I’ve summarized the process in the graphics below. Click on it for a larger view.

The Bonus Tip

Chances are you’re not going to like this.

There is one infallible way to be more productive and efficient. In addition, it will give you years of extra time doing stuff.

Running.

Running has at least two strong arguments going for it:

One study has shown that the sedentary work most of us do in front of computers is as harmful as smoking (you knew smoking was bad, didn’t you?)
Another study showed that running adds an extra six years to your life. You will also stay healthier longer.

Now, here’s something where many of us shine when it comes to procrastination!

“I think I’m about to get a cold.”

“I don’t have the time tonight.”

“I’ll start next week.”

If you don’t already exercise, make it your first goal. You don’t have to pick up running, but doing some kind of regular exercise will give you the energy to face other things you want to do.

2 Steps Towards Productivity Bliss: Stop Procrastinating

noreply@blogger.com (Magnus Nord) — Fri, 31 Aug 2012 20:12:00 +0000

“It’s the job that’s never started that takes the longest to finish. ” Sam said in The Fellowship of the Ring.

I think that summarizes procrastination pretty well, which is the second way towards productivity: stop procrastinating.

In the previous post I wrote about setting up a system to get organized. Being organized doesn’t help much if you procrastinate though.

So, why do people procrastinate?

Some reasons why people procrastinate are personal: maybe they’re going through a rough patch, maybe they are about to move.

Usually these causes are temporary. Perhaps you can continue working efficiently in the meantime. Other times you – and your surroundings – need to accept that you’re a bit off.

Other reasons are related to the work itself. Having an excessive workload can cause paralysis.

When tasks are too big you might not know where to start and start procrastinating instead. The same is true when you get stuck on a task.

The environment affects the ability to focus. Noise and constant interruptions are good examples.

TRY IT! Think about why you procrastinate. Are there times when you are more effective? What are the preconditions for that to happen? What kind of tasks are you working on then?

How To Stop Procrastinating

How to stop procrastinating is tackled differently by productivity methods, and relates to what causes are targeted.

Task Breakdown

This is an excellent way to come to terms with many work related issues.

By splitting tasks into smaller more manageable chunks work does not seem so overwhelming and it is easier to see where to start.

In GTD (Getting Things Done) the resulting smaller tasks are called next actions. Each action should be something you can finish without dependencies (otherwise it wouldn’t be the next action, would it?)

As an example, consider writing a report. This might at a first glance seem like a daunting task. If you treat it as a number of smaller tasks, it becomes much more manageable. “Write a draft outline.” “Write an introduction.” “Come up with a title.” and so on.

Focused Work in Iterations

This approach helps to avoid both external interruptions and when your mind wanders.

The first thing to do is to define goals, the things to work on. For example, you can start by setting up daily goals.

The workday is then split into short iterations with subsequent short breaks.

In each iteration, the goal is to concentrate on one of the tasks planned for that day.

The Pomodoro Technique is one method centered around this approach. It comprises strategies to deal with both lack of focus and interruptions.

Supportive Environment

You need the right tools to do the work well and not get distracted by annoyances or delays caused by, for example, non-functioning software.

To focus, and to get things done, you have to create a supportive working environment.

You need the right tools to do the work well and not get distracted by annoyances or delays caused by, for example, non-functioning software.

Examples of other distractions are unacceptable noise levels and interruptions by other people.

TRY IT! Think about if any of the strategies mentioned above might help you concentrate more and become more productive.

Method of Choice

The method of choice depends on the type of work.

If you mostly do large complex tasks that consist of many small steps and interactions, for example coordinating a workshop or managing a project, GTD might work better.

If you work continuously on something, for example reviewing or writing reports, or developing software, the Pomodoro Technique might be preferable.

A common question related to GTD seems to be how to handle a bigger coherent task, for example reading a book. My answer is to divide the workday into short iterations (Pomodoros if you like) and dedicate some to the task list (next actions, processing email, or whatever) and others to coding, reading and other longer tasks you need to do.

Let me know if you think there are other reasons why people procrastinate, and other strategies to stop procrastinating. Drop a comment below!

This was the second post of three in a series about how to attain productivity bliss. Next time I’ll sum up the series and share some further tips and ideas.

Productivity How-To Infographics

Shows the three steps to becoming organized and productive.

1. Collect all the incoming data into a reliable system
2. Process and review the information regularly
3. Select the tasks to work on and focus

Click image for a larger view

2 Steps Towards Productivity Bliss: Get Organized

noreply@blogger.com (Magnus Nord) — Mon, 27 Aug 2012 12:46:00 +0000

Ever wondered why some people seem to get more work done, and in less time, too?

Ever found yourself sitting at the desk with work piling up and 100+ emails in the inbox, not knowing where to start?

This series will help you get underway to become more productive and get work done in time for Friday night at the local pub.

You see, being productive doesn’t happen by chance, or to put it in the words of Paul J. Meyer:

Productivity is never an accident. It is always the result of a commitment to excellence, intelligent planning, and focused effort.

I think there are three prerequisites to become productive:

Get organized
Stop procrastinating
Communicate effectively

In this post I focus on getting organized. In the next post I’ll write about how to stop procrastinating. For some tips on how to communicate effectively, please read the previous post: Three Tips for Effective Communication.

How To Get Organized

A key characteristic of any system or method is capturing all incoming information: conversations, actions, ideas, appointments, and so on.

Some people prefer more hands-on stuff like a pen and notebook for this while others prefer some kind of power chord wizardry. I belong to the latter group.

Once information is collected, it needs to be processed. High priority things need to be identified, deadlines need to be checked, and so on. Equally important, things that are not important or downright irrelevant needs to be archived, deleted or postponed.

Finally, new information as well as stuff already “in the system” needs to be reviewed regularly.

To avoid information overload (and being able to focus) a system needs to:

Hide information that is irrelevant at the moment.
Be as simple as possible, yet capable of capturing everything.
Be easily accessible.

Once you have a working system, the real trick is to avoid returning to old ways. When – not if – this happens, remember that you have a system, and that you know how to get back on track using it. (How else did you start using it in the first place?)

I base the system around my smartphone and RTM (Remember The Milk) as described in this post.

Email

For many people, the biggest source of incoming information is the email inbox. Gaining control of the inbox can therefore be key to succeed.

I like to keep my email setup as simple as possible.

I process emails regularly, but don’t let it interrupt other work.

For things that are actionable, I categorize and flag the email, converting it to a task or calendar item. I then move the email to a folder appropriately named archive.

I delete or archive irrelevant/unimportant emails immediately, too. You can also try setting up filters to automatically archive certain irrelevant emails.

Admittedly a bit drastic, some people suffering from inbox overload automatically archive emails they have been CC’d.

Here’s a great video about Inbox Zero.

Look at it!

Finding a System That Works (for You)

I would recommend starting by looking at some well proven method, for example GTD (Getting Things Done). As you start implementing whatever system you choose: adapt it to best fit your needs.

Whether or not it’s a good idea to include everything in the system from the beginning, or to adopt a divide and conquer approach, I don’t know.

If you feel that email is the biggest issue, it might be a good idea to start there.

On the other hand, if you leave some parts out of the system, the benefits might be negligible at the same time as the risk of reverting to old habits increase.

Do you have any suggestions on how to go about getting your stuff in order? Please drop a comment below!

This was the first post of three in a series about how to attain productivity bliss. The topic for the next post is Stop Procrastinating.

How to Handle a Bad Career Move

noreply@blogger.com (Magnus Nord) — Sat, 18 Aug 2012 19:05:00 +0000

I recently talked to a friend that felt he had done a bad career move lately. When that happens it can be really frustrating, and it made me think about what to do in situations like that.

When lost in the wilderness, you might want to remember the STOP acronym which stands for Stop, Think, Observe and Plan.

As it turns out, this acronym works well in other contexts, too. Being lost in your career is no exception. Though some other tips like "make a fire" and "look for shelter" might not be relevant.

1. Stop

If you find yourself on a job where you feel you stagnate or that doesn't move your career forward, the first thing to do is to slow down. I don't mean stop working, but don't make any rushed decisions.

Rushing things can put you in an even worse position.

You can probably still learn and benefit from your current job, and you should always strive to make an effort. Not only because it’s the right thing to do with regard to your employer, but also to retain business relations and to feel better about yourself. It is easier to go to work when you get involved and have a positive mindset.

2. Think

Contemplate the current situation, and your options to get back on track.

How did you get here? Why don't you like it? What is missing? Where do you want to be? This is important to carry out the next two steps: observe and plan.

3. Observe

Once you've settled on some career goals, observe the world around you.

Perhaps there are job openings available at your current company, that you haven't thought about.

Go over your network, and start browsing for job offerings.

What can you do, based on where you're at right now, to help you move in the right direction? Is there any training to take? What tasks should you get involved in that will move your career forward?

4. Plan

Finally, make a plan on how to reach your career goals. Update your CV and social network profiles. Attend training if appropriate.

Once its time to go to an interview, make sure you’re prepared. You can find a lot of great resources and tips over at theundercoverrecruiter.com, for example this post: Top 10 Job Interview Tips and Tricks

If you don’t know where you’re going you’re bound to end up in places you don’t want to be. If you do, stay positive and consider it a learning experience.

Do you have other suggestions on how to get your career back on track? Drop a comment!

What Should a Software Testing Plan Include?

noreply@blogger.com (Magnus Nord) — Thu, 16 Aug 2012 19:21:00 +0000

A software testing plan provides the backbone of the entire software design, development and installation process. Carefully considering all the aspects of a testing plan will help ensure success when starting the software design process, giving a clear direction and path. The testing plan provides information as to how success is defined and how it will be achieved – these are key aspects to making sure the product designed will address the actual needs of the internal or external client.

Defining Resource Requirements

Hardware needs are the first consideration. Having the correct hardware and understanding the capabilities of the system that you are incorporating may necessitate additional hardware purchase. It is also critical to consider the software needs of your new system and whether software will have to be purchased or is available in an open source form. In addition to the software needs of your new system, remember to consider testing tools – which may require additional software or hardware investment – as part of your requirements package. Finally, remember that the new technology will still require staff to implement it. Carefully consider the responsibilities of the staff and whether they will need additional training or not to perform their duties.

Defining Success

Part of having a successful software testing plan is to know what should be tested and what does not need to be tested.

Part of having a successful software testing plan is to know what should be tested and what does not need to be tested. Keeping those factors in mind will help you to define the scope of the project and what actually does need to be done. In addition to having information on what features will and won't be tested, it is critical to understand exactly what you and your team is responsible for. The benefit to having the scope defined on the front end of the project is that it promotes clarity and understanding as the project moves forward.

Exit Criteria

As important as it is to know what you are responsible for before the process ever starts, it is equally critical to understand what milestones constitute the end of the project. Having a fully developed software testing plan will solve many of these issues. Make sure that exit criteria are defined in a way that is measurable in both performance and timing. Having a clear idea as to what is expected – for instance, fixing a particular defect or researching a possible solution – and when it needs to be completed by gives your team and your management the feeling of direction and success as well as clarity as to when the exit is appropriate.

Conclusion of Testing Plans

Trying to determine when it is time to end software testing is more than just completing the exit criteria. While every IT professional wants their system to function perfectly, that may not be the case. Testing may be ended when the situation no longer warrants it. That may be because deadlines have passed or the budget is no longer available to support testing procedures. Either way, the decision will have to be made at some point to end testing.

Creating a software testing plan can be the foundation of success for any software project. Knowing the requirements up front as well as having measurable criteria for success, exit and end of testing make the process clear and understandable to all.

Article by Ryan Sauer

Ryan Sauer is a writer and editor in association with University Alliance. He actively writes about project management in different industries and strives to help professionals succeed in their project management training. Through the University Alliance, Ryan writes to help enable professionals obtain their PMP certification.

Zen of Scrum: Product Backlog and The Story Behind

noreply@blogger.com (Magnus Nord) — Mon, 13 Aug 2012 19:41:00 +0000

The product backlog is the bucket from which you pull work. It’s a list of all items that potentially make it into the product. It’s the single source of requirements. That sounds easy enough. Perhaps it is, too. Yet sometimes it isn’t obvious what to put in the backlog, and how to select what items to work on next.

One challenge is to manage non-features such as technical items and bugs (in the rare case you have any, of course). People have different strategies to deal with the not-so-obvious stuff.

It can also be overwhelming to add “everything that goes into the product”. However, don’t interpret that the wrong way: the backlog is dynamic, and evolves alongside the product. As more is learned and business requirements change, so does the backlog.

The Product Backlog Should be DEEP

Characteristics of a good product backlog is summarized by the DEEP acronym.

Detailed enough. Don’t specify more than necessary. Future items can be described in less detail.
Estimated. Items in the backlog should be estimated, or at least estimable.
Emergent. The backlog is dynamic. It changes to reflect new requirements and knowledge gained as the product is developed.
Prioritized or ordered. The backlog should be ordered so that items that will be worked on next are located first.

Backlog Items

The product backlog is made up of backlog items. Backlog items can be pretty much anything describing stuff that comprise the product. For example a requirement specification. However, most people use user stories.

A user story is a short description of a value-adding feature. It is often written in the form below. The idea is to put emphasis on who (as a…) the feature is for, and the reasons (so that…) for it.

Writing stories in this form can be difficult, especially when you’re not used to it. For example, it is not always obvious who the target user is.

Chances are also that you’re implementing something for another sub-component or to meet an external requirement. Even so, I think it’s feasible to write meaningful stories in this way. For example: “The database subsystem wants time to be specified in UTC so that data is consistent independent of local time.”

Including why the feature is needed (the business value) enables developers to make informed choices and give suggestions on alternatives.

INVEST in the Stories

To remember how to write good user stories, you may want to remember the INVEST acronym.

Independent. The story should add value to the product independent of other stories.
Negotiable. The story should be negotiable. It is not an absolute requirement.
Valuable. The story should by itself add value to the product.
Estimable. It should be possible to give an estimate for the story.
Sized right. The story should be sized right. For example small enough to be implemented in one iteration.
Testable. It should be possible to verify that the story has been implemented as intended.

Independent relates to value, not implementation. The story should add value independent of other stories. However, one backlog item may very well require some other bit of functionality before it can be implemented.

Final Thoughts

Don’t overdo it. Keep in mind the agile principle of simplicity: the art of maximizing the amount of work not done. In my experience you can become crippled when trying to add everything at once. Remember that the backlog is dynamic.

For more on the product backlog, I recommend this article over at Agile Bench.

Next time I’ll write about estimating the items in the product backlog.

Zen of Scrum: Definition of Done

noreply@blogger.com (Magnus Nord) — Tue, 17 Jul 2012 14:02:00 +0000

A common reason for disagreements is differing definitions. I once had a discussion with a friend about egoism and people’s ability to do truly altruistic acts. After an hour though, we suddenly couldn’t agree more. That was when we decided to define egoism.

Defining what done means is essential of exactly this reason. If you don't know what people mean by "done", how do you have meaningful conversations about progress and the state of work? How can you be confident when asking for estimates?

This post is related to the free
Scrum presentation Zen of Scrum.

The Purpose of a Definition of Done

The DoD (Definition of Done) serves three purposes:

Enable time estimations. If you don't know what people mean by done asking them for an estimate is pointless.
Avoid misunderstandings. When having conversations about progress, work being done, and so on, shared definitions help avoid misunderstandings and disagreements.
Assure quality. The DoD ensures quality and helps avoid technical debt by including test cases, refactoring, code documentation, and so on.

The DoD also helps finishing stuff and right shift them to the Done column. With no definition of what done means, it's easy to end up with the five more minutes syndrome, and gold plating.

As the DoD evolves it can also help improve how backlog items are written. If, for example, the DoD states that the acceptance test shall pass, you're going to need a well defined such test, right?

Properties

The DoD is dynamic. It should evolve as teams learn more. It should also be shared with stakeholders and other teams. This ensures transparency and simplifies communication.

A lowest common denominator of the DoD can even be the same across teams, if not the complete definition. The level of sharing also depends on at what level the DoD is used.

Different Definitions at Different Levels

It is possible to have different definitions of done for backlog items, sprints and releases.

For example, a DoD for backlog items might include unit testing and source control management while the release DoD might include updated manuals and performance testing.

Mitch Lacey includes some examples of DoD's at different levels in his article "How Do We Know When We Are Done?".

In the article "What is Definition of Done (DoD)?" Dhaval Panchal makes a good point about at what level to place different activities:

Ultimately, the decision rests on the answer to the following three questions:
1. Can we do this activity for each feature? If not, then
2. Can we do this activity for each sprint? If not, then
3. We have to do this activity for our release!

That’s it for now, as I’m off for a week of hiking in the Swedish mountains (fjällen).

The next post in the Zen of Scrum series will cover the product backlog and user stories.

Three Tips for Effective Communication

noreply@blogger.com (Magnus Nord) — Thu, 05 Jul 2012 21:17:00 +0000

Communicating is inevitable at work, and good communication skills are key to happiness and success.

Only one thing is more difficult than being good at giving constructive criticism: being good at receiving it.

Being able to say no is not always easy either. Have you ever accepted a deadline or yielded on a time estimate although you know it’s impossible?

Here are three techniques/mnemonic rules that can help you communicate more efficiently.

Hamburger Rule: How To Give Criticism

It is not easy to give constructive criticism. It is often better to offer positive suggestions instead, as suggested by Leo Babauta over at Zen Habits.

Instead of criticizing, which is rarely taken well, offer a specific, positive suggestion.

The hamburger rule (also known as the feedback sandwich but if you know me, you know I prefer burgers) – embed criticism in between two compliments – has gotten some criticism, for example in this article by Nagesh Belludi.

Nonetheless, what you can certainly take away from this rule is to remember giving positive feedback more often than negative.

Inform, Negotiate, Call: How To Be Assertive

While studying the Pomodoro Technique® and specifically the strategy suggested to deal with interruptions, I was reminded about a course in leadership at the university where they taught assertive communication.

To me, the essence of assertiveness is respecting and being honest to yourself and others.

While the inform, negotiate and call strategy (which I like to illustrate as a traffic light) is mostly associated with the Pomodoro Technique®, I think it boils down to assertive communication, and hence, works well in other contexts.

	Inform about the situation. For example that you’re busy working on something else.
	Negotiate and agree on how to move forward. For example, how to prioritize conflicting interests or solve a problem.
	Call or take appropriate actions based on the previous step: negotiate. For example, get back to the other party on the time agreed.

H.O.T. Communication: How To Communicate Efficiently

This acronym has nothing to do with flame wars in forums. It’s a recipe for good communication. Dan Oswald writes:

I’ve been thinking about what makes for good, effective communication and how it can be a powerful force within any organization. I’ve decided that good communication must be H.O.T.

H.O.T. stands for Honest, Open and Two-Way.

Honest. Don’t try to candy coat information. In the end, the truth will be out in the open anyway.
Open. Don’t hide information, it only fosters suspicion and mistrust. Trust your co-workers.
Two-way. It is wise to use your ears more than your mouth. Letting people respond also helps enact the first two principles.

Though Dan writes about this from an organization perspective, I think it’s equally valid in personal communication: Be honest about your intentions and feelings. Be open about what you know. Be an active listener.

Zen of Scrum: Roles and Teams

noreply@blogger.com (Magnus Nord) — Fri, 29 Jun 2012 11:25:00 +0000

The agile team concept is one of the Scrum practices that might be difficult to fully grasp. For me at least,this is a continuous learning experience.

It is also one of the most important things to get right: and where many agile transitions go wrong. Cross-functional, self-organizing teams runs counter to the classical matrix management structure with project teams.

Many organizations do sprints, Scrum boards, burndowns, and so on, but don’t change their mindset much.

This post is related to the free Scrum presentation Zen of Scrum (the previous post gave an overview of Scrum).

Scrum Roles

Scrum defines three roles. The number is intentionally kept low as more roles create overhead and complicates communication.

The Product Owner (PO) is the glue between the team and the customer and other stakeholders. The PO ensures the greatest possible value is delivered.
The Scrum Master (SM) is the "agile enabler" or "Scrum catalyst". This person helps the organization understand and apply Scrum in a good way.
The Team (Developers) is a cross-functional, self-organizing feature team. A feature team is a long-lived entity capable of delivering product value as a stand-alone unit.

I personally think it’s confusing to use the word Team to describe the third Scrum role when the term Scrum Team is used to describe the whole team, including the Product Owner and Scrum Master.

The idea is to emphasize the importance of team collaboration in contrast to different specialist roles such as coder, tester, analyst, documenter, and so on.

Nonetheless, I prefer to use Developers as the term for different specialist roles involved in product development. There’s still no distinction between specialists: they are all involved in developing the product.

Mapping to Traditional Roles

When changing to Scrum, one mistake that is often made is to let the project manager become scrum master. I think this is bad of two reasons:

A traditional project manager role involves communication with stakeholders and the customer, prioritizing work, making up release plans, and so on. This maps much better to the Product Owner role.
The project manager is a management role and this person often has a special position in the team. This inhibits self-organization, especially when the whole team transits to Scrum: the project manager continues managing the team.

I think it’s better to let the project manager become product owner. The product owner role has more focus towards communicating and prioritizing work, focusing on maximizing ROI (Revenue of Interest).

However, make sure the Product Owner doesn’t revert to detailed planning and managing the team.

Transitioning to Feature Teams

While transition for individuals can be tricky, a bigger challenge is changing the mindset of the organization.

An organizational shift towards feature teams, away from traditional line/project matrix structures, is not accomplished over night. It might challenge set ways, and requires real ambition to change.

This is expressed another way in an excellent article about feature teams by By Craig Larman and Bas Vodde:

people may incorrectly think they are doing Scrum or agile development simply because they are doing mini-waterfalls in a shorter and iterative cycle. But mini-waterfalls are not lean and agile development; rather, we want real concurrent engineering.

That’s it for this post. Next time I will write about the Definition of Done.

Task Lists for DOERS

noreply@blogger.com (Magnus Nord) — Mon, 25 Jun 2012 21:04:00 +0000

In an attempt to ride the wave of backronyms like INVEST in your user stories and DEEP product backlogs (though they are now supposedly DEEO ;-)), here's my rule to create task lists for doers.

I am childishly pleased with the backronym, but I'm pretty sure it's not foolproof: can you think of other characteristics that make a good task list? Let me know! Anyhow, here goes…

A task list needs to be:

Delegated
Ordered
Exclusive
Relevant
Shared

Delegated

Each item in the task list should be delegated to one person.

This does not necessarily imply the person is solely responsible, but someone needs to be appointed to ensure task completion.

Ordered

The task list should be ordered, or rather: it should be possible to order, group and sort items in different ways.

For example, it is often very useful to group tasks by owner and perhaps filter out tasks in progress.

Exclusive

The task list should be exclusive: information should not be spread across different documents or media.

When information is kept in multiple places, it soon becomes difficult to ensure data is properly updated.

This is also called known as the DRY (Don't Repeat Yourself) principle. Hey! Another acro…. backro… whatever-nym.

Relevant

The task list should be relevant.

Stale information and obsolete tasks of no interest should be deleted or moved to an archive.

Shared

The task list should be shared.

What I mean by this is that it should be accessible by everyone involved, and everyone should be able to add and update items in the list.

Zen of Scrum: Scrum Distilled

noreply@blogger.com (Magnus Nord) — Sun, 24 Jun 2012 18:14:00 +0000

This is the third post in a series related to the Zen of Scrum presentation available on SlideShare.net.

In the previous post I wrote about Scrum's five values. Now it's time to list the roles, events and artifacts defined by Scrum.

Some of the things associated with Scrum is actually XP practices and not dictated by Scrum at all, though they have become de-facto standards and considered best practice by many.

The Scrum guide, the Scrum guidance document, is regularly revised. This is to be expected, of course, as Scrum adheres to agile principles of which continuous improvement is one.

For example, burndown charts were recently removed giving teams more freedom to decide how to visualize progress (remaining work) in sprints.

Scrum defines three roles, four meetings (ceremonies) and three artifacts. These are listed below but only described briefly as I plan to write about them in more detail in coming posts.

Roles

The number of roles is deliberately held to a minimum: more roles has a negative impact on communication.

Scrum defines three roles:

Product Owner, responsible for the product backlog and to maximize ROI (Return On Investment).
Scrum Master, ensuring Scrum is understood and enacted.
Team, which is self-organizing and cross-functional.

Meetings

Scrum defines four meetings:

Sprint planning, whose purpose is to select and estimate work for the coming iteration.
Daily scrum, which is a short stand-up meeting to synchronize the team.
Sprint review, where the team demonstrates what has been done, and talk about what is planned next.
Retrospective, to inspect and adapt the process; improving how the team applies agile and Scrum.

Artifacts

Scrum defines three artifacts:

The product backlog, an ordered list of everything that might go into the product.
The sprint backlog, which is the work forecasted by the team to be completed in the next sprint.
Product increment, the result of the efforts up to the current sprint.

Zen of Scrum: The Five Values

noreply@blogger.com (Magnus Nord) — Mon, 18 Jun 2012 20:36:00 +0000

While most people know about daily scrums, sprints and poker planning, and others only associate Scrum with post-its scattered on a whiteboard, few are aware of the five Scrum values. Do you know them?

This is the second post in a series related to the Zen of Scrum presentation (available on SlideShare.net). In the previous post I wrote about the agile manifesto where the five values are rooted.

Here's a good post about Scrum's five values and why they matter. Mik writes

I believe that the Five Scrum Values address the human aspect of Scrum, in a way that the Scrum processes, ceremonies and roles do not. It provides a framework for how we can interact effectively as a team, on a human level.

I agree. I think many organizations apply Scrum processes and events without understanding or caring about underlying principles.

In fact, at the top of Craig Larman and Bas Voddle's list of organizational impediments is superficial adoption.

This, in turn, fosters the belief that meaningful problems can be solved by saying "we do agile" and going through the motions of doing so, with no deep understanding or change by the leadership team.

So, don’t forget about why you adopt agile. Make sure people get proper training before you dive in: and don’t forget about management.

In the next post I'll write about the roles, processes and events (or ceremonies) defined by Scrum.

Three Things Everyone Can Pickup from Scrum

noreply@blogger.com (Magnus Nord) — Sun, 17 Jun 2012 20:06:00 +0000

To use Scrum, you arguably need to apply it wholly. However, some practices are not unique to Scrum: practices all teams can benefit from.

It might also be an eye-opener for people, making them more inclined to turn fully agile. I recently switched from a project doing Scrum to a team with no clear project methodology or framework: the change in the level of communication and willingness to change and improve was striking. I think these three things alone would go a long way to improve the situation.

So, here is my list of three things I believe all teams can apply successfully.

1. Synchronization Stand-Ups

Holding these meetings daily help nurture face-to-face communication.

One Scrum trademark is the daily stand-up. A 15 minute meeting where team members share what they've been working on, what they plan to do next, and if anything stops them from doing their job.

All teams benefit from daily synchronize stand-ups: not only Scrum teams. Daily synchronization meetings help

Focus on relevant, prioritized work
Spread knowledge and avoid duplicated work
Raise and solve problems together

Additionally, holding these meetings daily help nurture face-to-face communication. Standing up is key to stand any chance (no pun intended) of keeping the 15 minute timebox.

2. Regular Retrospectives

In many projects lessons learned sessions are held sporadically or at the bitter end. This is too seldom.

One risk of waiting too long between retrospectives is that the list of potential improvements has grown to an undefeatable beast that is banished to the archives.

Another risk is that project members never have a chance to implement changes, and experience the effects.

3. Abstract Assessments

It is easier to relatively compare things than to give accurate absolute estimates.

Estimating in abstract units such as story points effectively separate what from when: two different questions altogether.

It is easier to relatively compare things (A is roughly twice as big as B) than to give accurate absolute estimates (A is 20 hours and B is 35).

When you are asked to give an ETC (Estimated Time of Completion), no matter how futile, you're as bad off estimating relative size. However, as you learn more and go about refining estimates you're better off.

With relative estimates you don't have to start from scratch. For example, if you find out that all tasks take longer than you first expected (a systematic error) your estimates are still valid. You only need to change the ETC.

Zen of Scrum: The Beginnings

noreply@blogger.com (Magnus Nord) — Wed, 13 Jun 2012 18:17:00 +0000

Zen values simplicity, so does agile development. Zen means introspection, a key component of Scrum as well. Additionally, Zen is the attainment of enlightenment: very similar to the feeling when you first get agile.

As promised, here's the first post in a series about the free presentation Zen of Scrum available at SlideShare.net. (It is also available as PDF here.)

Why did I name the slideshow Zen of Scrum¹? In addition to the things mentioned above, Zen is a state of complete awareness where you are in perfect tune with your surroundings, ready for anything. This is a goal of Scrum, too: you should always be prepared for, and welcome, changes.

Agile Manifesto

Scrum is founded on the agile manifesto and its underlying principles.

The way the agile manifesto is formulated leads to the occasional misconception that planning, processes, documentation and contracts are neglected. That's not true. It’s important to remember the last sentence.

That is, while there is value in the items on the right, we value the items on the left more.

Scrum Goals

Scrum is a product development framework that is based on empirical control process theory.

What does that mean? A framework is a collection of practices that are designed to work together to handle a particular type of problem. Empirical control process theory is based on iterative development where you evaluate the process, and adapt accordingly, after each iteration. The process is transparent and can be observed from the outside.

In Scrum, transparency means visibility to stakeholders and the use of a common vocabulary and definitions.

The word Scrum comes from Rugby, and was first mentioned XXXX. In Rugby, Scrum is defined in the rules.

The purpose of the scrum is to restart play quickly, safely and fairly after a minor infringement or a stoppage.

In the next post I will write about the five Scrum values and the four pillars of Scrum.

“Zen of Scrum” does not feel as original now as when I named the presentation. Zen is used in a lot of other contexts related to Scrum and agile, for example by AgileZen. Additionally, David Allen talks about the state of Zen in association with GTD. ↩

Three Characteristics of Great Visions

noreply@blogger.com (Magnus Nord) — Mon, 11 Jun 2012 20:21:00 +0000

Ideally, any business or project is be based on the principle to change the world for the better. Any change, in turn, needs a vision and a purpose.

A vision needs to fulfill three criteria to set it apart as really great: it needs to be inspiring, larger than shareholders, and.. uhum... visionary. The last one might seem a bit obvious, but it really isn't.

Inspiring

It is what makes employees wake up with a smile as they get up for work on Mondays.

A vision statement defines the company. It is the purpose, and the soul, of the company.

An inspiring vision that enthuses people can help conceive new business. It can assist in recruiting new talent. It is what makes employees wake up with a smile as they get up for work on Mondays, instead of dragging their feet out of bed.

Visionary

I hear you say: "kind of obvious, huh?" I don't think it is, though. In fact, I believe this is what - more than anything - sets great visions apart from the rest.

A visionary thought is a new and insightful idea. It is thought-provoking and intriguing.

Business oriented goals that you often find in mission statements are usually not visionary. There's nothing original about creating the best product, making the largest profit, or gaining market shares.

Larger Than Shareholders

The vision needs to be larger than economics.

If the company vision is rooted in finances and related to profits it won't be the least bit inspiring. At least not to non-shareholders: customers, most employees, and so on.

Pomodoro Technique® and Scrum: Objective VI

noreply@blogger.com (Magnus Nord) — Wed, 06 Jun 2012 19:14:00 +0000

The final article in the series about the Pomodoro Technique® and Scrum covers objective VI: Other Possible Objectives which, I admit, is a bit fuzzy.

One goal of Scrum is to continuously improve. This is formalized in the sprint retrospective. Identifying and implementing potential improvements is part of the agenda, and second nature to agile practitioners.

Other Articles in the Series
Find out how much effort an activity requires
Cut down on interruptions
Estimate the effort for activities
Make the Pomodoro more effective
Set up a timetable
Other possible objectives

Mostly these improvements have nothing to do with how team members apply the Pomodoro Technique® but "other possible objectives" could very well be the product of a retrospective.

However, I have chosen two other objectives that I will mention briefly.

Using the Pomodoro Technique® in Meetings

Two characteristics of effective meetings are

They have an agenda
They are timeboxed

For discussion oriented meetings it is often useful to timebox each item on the agenda. Pomodoros could be used as an alternative, perhaps with adjusted durations and cycle between longer breaks.

A big time thief in meetings are off-topic discussions. The technique used to deal with internal interruptions in Pomodoros work very well here: stop the discussion, make a note of the interruption and write down the topic so that it can be picked up later.

You could also consider treating the agenda as a Pomodoro TODO sheet and make notes of all interruptions: internal and external. At the end of the meeting, take a minute to reflect on how the meeting went and how to improve the next meeting.

It might be an eye opener to people.

Expanding the Pomodoro Technique® to the Team

I think expanding the Pomodoro Technique® to a whole team can prove very difficult. Probably it's not even desirable.

How you work most efficient is very individual, but to be productive I think you have to feel comfortable about, and like, the way you work.

If you want to "spread the word" the best way is probably to keep using the Pomodoro Technique® yourself. Perhaps people will become curious and like to try it for themselves.

If people on your team are open-minded and willing to embrace new ideas they might agree to try this as well as other techniques on a team level. In that case you could, as an example, try estimating tasks in Pomodoros instead of hours.

Conclusion

The Pomodoro Technique® can be an excellent way to focus. Not only to concentrate on the task at hand, but also to work on the right things and avoid overworking stuff.

Whether you choose to use the Pomodoro Technique® or not, it is invaluable to have a toolbox with techniques that you can apply if need be. As always, pick the bits and pieces you find useful and skip the rest. Maybe Pomodoros are not for you, but the negotiate, inform and call strategy work wonders.

Three Types of Teams That Don't Scrum

noreply@blogger.com (Magnus Nord) — Tue, 29 May 2012 19:27:00 +0000

People might not like the idea of Scrum for many reasons. Three types of teams that don’t Scrum though they might have heard of it are:

1. Teams that are productive
2. Teams that think they are productive
3. Teams that don't want to be productive.

So before shifting to Scrum, think about your reasons behind migrating and if it is a good idea to start with. If you go through with it, consider how teams will react to the change and formulate a transition plan accordingly.

Teams That Are Productive

Not for me! Not for me!

- From the movie "Pitch Black"

Scrum is not right for everyone, though you might think so considering the last years’ massive move towards agile methodologies. You can have great success with other techniques as well.

Perhaps the environment is plain and predictable. Maybe the team is more agile than they think. Organizations claiming to be agile are sometimes less so than companies never having heard of Lean, Scrum and XP.

In short, the success of projects is more about common sense and less about the methodologies and principles applied.

Teams That Think They Are Productive

What we've got here is... failure to communicate. Some men you just can't reach. So you get what we had here last week, which is the way he wants it... well, he gets it. I don't like it any more than you men.

- From the movie "Cool Hand Luke"

People might think they are productive: most likely because they have never been in really productive environments.

Sometimes you have a nagging feeling that you aren't doing things right, but you can’t put your finger on what it is. Other times you see more clearly what needs to be done but don't know how to bring about the change.

However, it's not certain people realize things could be different. They live in a bubble with no knowledge or desire to change or embrace new thoughts and good advice.

Teams That Don't Want to be Productive

Bob Porter: Looks like you've been missing a lot of work lately.
Peter Gibbons: I wouldn't say I've been missing it, Bob.

- From the movie "Office Space"

Sometimes you run across people with no desire to be productive, and there can be many reasons behind this.

You have to feel important to your employer to be motivated: the work you do needs to be meaningful; at least to someone. If this isn’t the case, people eventually alienate themselves from the work, becoming less and less productive.

Some people never care much for work at all. Work is what you endure to get money for things that really matter. What they don’t seem to realize is that work is much more fun if you engage yourself and try to improve and contribute. It is also more respectful to your colleagues.

Some people are not productive from the team’s point of view; they work according to an own agenda. In their minds what they do is more important than what the team does.

Three Things Not To Do in Meetings

noreply@blogger.com (Magnus Nord) — Tue, 22 May 2012 15:34:00 +0000

Nothing is more annoying than unproductive meetings. Some things irritate me in particular: people answering phone calls, people working on their laptops, and off-topic discussions.

You would think it goes without saying that you don’t do these things in meetings. However, it doesn’t seem to be so natural. Hmm… Come to think of it, I might be guilty of the last one myself occasionally.

1. Don’t Answer the Phone

Once in a while (like, once a year or something) you receive a phone call that cannot wait. This type of calls fall under one of three categories: planned, predicted or emergencies.

You deal with planned and predicted phone calls by clearly stating that you expect a call you need to pick up - preferably also what it's about - and that you will step out of the meeting then. Perhaps your wife is pregnant and the child is expected any time now.

Other than for emergencies, you shouldn't answer unplanned phone calls. This is the key point, and where people fail the most. Whether it's because they don't understand the concept of an emergency or if they don't realize why interrupting meetings is bad, I don't know.

A family member in the hospital is an emergency, someone calling about lunch is not. Calls from customers are usually not emergencies. You will know if it’s urgent by repeated call-ups even as you reject them.

2. Don’t Use Your Laptop

There was a time when there weren't any cell phones or laptops ... I imagine meetings must have been so much more efficient back then!

There was a time when there weren’t any cell phones or laptops. No mobile nothing. Not even pagers. I imagine meetings must have been so much more efficient back then! Or, maybe they weren’t? Either way, it feels like people can’t handle the responsibility that comes with mobile tech. Like for example, bringing your laptop and using it in meetings.

Unless you're taking the minutes, or holding a presentation, put away the laptop. Not only is it rude and disrespectful. You will most likely miss important discussions, too.

If you feel you're better off working with other stuff. Do one of three things:

If you’re only involved in a couple of items and actually have more important things to do: try to rearrange the agenda and move those items to the top. Alternatively leave and rejoin the meeting later.
To resist the urge to work on other stuff during meetings: help ensure meetings are focused and effective. Don't make things worse by being part of the problem.
Consider if you really have to attend the meeting.

3. Don’t Engage in Off-Topic Discussions

The number one reason why meetings drag on and fail to respect the schedule is off-topic discussions that don't drive the meeting towards the goal.

You know you do it! It can be tough to resist saying just one more thing. All of a sudden, you've spent 30 minutes talking about whether or not it’s a good idea to add comments at the end of code blocks. (Which, by the way, it isn't.)

Bring a notebook and write down whatever you feel the need to say. Talk to people about it during recess, or after the meeting. Maybe you realize that it wasn’t that important after all.

The more people realizing off-topic discussions is a meeting anti-pattern the more likely you are to have effective to-the-point meetings where scope and time are respected.

Pomodoro Technique® and Scrum: Objective V

noreply@blogger.com (Magnus Nord) — Fri, 11 May 2012 11:44:00 +0000

This post is about the Pomodoro Technique® objective V: Set up a timetable. Instead of writing about how setting up a timetable and respecting work hours helps you keep a sustainable pace and uphold productivity (curiously enough a key XP practice as well :-)), I will focus on the similarities between objective V and a Scrum Sprint.

I think it's striking how well the fifth Pomodoro objective correspond to the essence of iterative development and Sprints.

In the Pomodoro book, Francesco Cirillo makes a couple of points.

A timetable measures the results of the day ... our goal is to carry out the activities listed on it with the highest possible quality within the set timeframe.

The goal of a Sprint is to finish the work items the team has committed to while preserving quality.

If time runs out and these activities aren't done, we try to understand what went wrong.

Well, that sounds like a Sprint retrospective to me.

Francesco goes on explaining that concentrating on the time wasted isn't important: how much work we actually do is. The amount of work completed is carried over to the next iteration.

The same is true for sprints: you review past progress to get an idea about how much is reasonable to put into the next iteration.

Focusing on what has not been done is also bad for morale. Instead, look at what you have achieved, learn from that and think of ways to increase velocity.

However, The strongest point Francesco makes, that Scrum teams can learn from, is this:

The main risk with the timetable is in underestimating how important it is.

I've been on Scrum teams where too much work is systematically put into sprints. Consistently, the team fails to finish the scheduled work. Eventually the sprint loses its purpose: productivity declines alongside people's spirits.

Conclusions

In order to maintain a sustainable pace you need to respect the timeboxes. This is true at all levels:

Individual Pomodoros
Daily Timetables
Development iterations (sprints)

If you don't do this, you partially undermine the purpose of working in short iterations, whether a Pomodoro or Sprint.