Devoted Developer

The Pomodoro Technique® and Scrum: Objective I

noreply@blogger.com (Magnus Nord) — Tue, 21 Feb 2012 21:01:00 +0000

This is the first post in a series about applying the Pomodoro Technique® to Scrum and for development.

Each post covers one of the Pomodoro Technique® objectives. The first objective is to find out how much effort an activity requires.

I started using the Pomodoro Technique® a couple of weeks ago. At first simply trying to work focused for 25 minutes with 5 minute breaks. I didn’t do this all the time, though, as I didn’t feel my working environment allowed it.

Today, I primarily use the Pomodoros when developing. When I get a chance, I will definitely apply it to other tasks as well, such as writing and studying.

Development Pomodoros

I write down the tasks I have committed to at the daily standup on my Pomodoro To Do Sheet. This helps me focus on these tasks and contribute more to the Sprint progress.

...it gives you natural slack for refactoring and improving design.

The greatest advantage of the Pomodoro Technique® in the context of Scrum is that it gives you natural slack for refactoring and improving design. This is supposed to be done throughout sprints, but is in reality often overlooked.

When you finish a task before a Pomodoro has ended, the technique dictates that you overlearn. For development Pomodoros I suggest refactoring is equally – if not more – beneficial.

Using the technique makes it easier to focus on one task at a time – instead of working on several things simultaneously. One difficulty was how to deal with code related side tracks, for example browsing for documentation or learning how an API works in more detail. Now I use common sense: either marking the task as an unplanned activity, or following up on it if I feel it is important in order to finish the current task in a satisfactory manner.

Another advantage of the increased focus on the task at hand is that it becomes easier to commit code as coherent entities. Checkouts are not cluttered with files from different contexts. This is admittedly something you should take care to accomplish anyway, but if you’re anything like me and slip from time to time, the Pomodoro Technique® helps.

The Five Minute Break

I initially found it difficult to stop working immediately as the buzzer rang. I still don’t stop typing immediately. At the very least I finish the word or statement I’m writing. I don’t want to leave the file in a non-compilable state.

Some of things I do in the five minute break:

Get a cup of coffee
Walk around
Get some air
Talk to a colleague (who’s not in the middle of a Pomodoro :-))

It’s amazing how much you can do in five minutes. I have no problems going to the men’s room and getting a cup of coffee.

Daily Standups

I review the To Do Sheet before the daily standup meeting.

So far, I don’t record the Pomodoros at the end of the day. Instead, I review the To Do Sheet before the daily standup meeting.

Looking back at the Pomodoros finished from the day before gives you a good overview of what you have done, and how much time you spent doing it – very much in line with the first objective of the Pomodoro Technique®. You also get hints about any problems you’ve had and unplanned tasks that have popped up (and can be addressed as a problem, or should be added to the Scrum board as unplanned items).

Conclusions

When developing, as Pomodoros are indivisible, you automatically get small buffers for refactoring and improving design.

Using Pomodoros help in giving accurate feedback at the daily standup. The technique also helps to focus on technical tasks committed to at the daily standup.

In the next post I will write about the second objective: cut down on interruptions.

The Eternal Triangle

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

The project management triangle is an illustration of how a project’s constraints correlate.

It is a useful tool to help stakeholders and customers understand that they can’t get everything (“pick any two”). It can also be the starting-point for discussions about a project’s relative priorities.

The project management triangle is usually shown as in the figure below. The sides show three constraints in project management: time, cost and scope. Quality is put in the middle to illustrate how it relates to the three constraints.

Variants

The project management triangle comes in many shapes and forms. Not even necessarily as a triangle. The labels also differ slightly. Scope may be replaced by features or functionality. Cost by resources or budget. Time by timeline or schedule. The meaning is the same, though.

Sometimes the labels are put on the corners instead of the sides, as in the figure below.

The project triangle can also be shown as a trilemma. The labels are then replaced by fast, good and cheap. It is in this context you say “pick any two”. The remaining constraint depends on the other two – and cannot be controlled. For example, you can build something fast and cheap, but it will probably not be very good.

There are also other versions, for example the project diamond and PMIs point star (two inverted triangles where the second one depicts risk, quality and resources).

While these and other “evolved” versions of the project management triangle may better depict the real complexity of projects, they lose some of the simplistic beauty of the traditional triangle.

Possible Use

As the project triangle shows a simplified picture of a project, it works best as the basis for discussions and to illustrate a point.

As an example: in a previous post called Fixed Price Contracts - A False Sense of Security? I write about how fixed prices “lock” all sides of the triangle and significantly increase the risk of project failure. In other words, in the context of a fixed price contract, the project triangle shows how quality is the only factor workable by the contractor.

Scrum and the Project Management Triangle

It might seem like Scrum disregard the basic idea of the project management triangle. Sprints have locked time, cost and functionality. The time of a sprint is always the same. The team should not change. The team has also committed to finishing a set number of user stories, or features.

The truth is that while a sprint seemingly violates the prerequisites of the project triangle, quality is never supposed to be jeopardized.

Using the concept of velocity, Scrum teams adapt the scope iteratively after each completed sprint. It is ok not to finish all the user stories in a sprint. Sprints even have built-in quality assurance in the form of the definition of done.

As the definition of done is continuously worked on and improved, the Scrum team also assures quality of delivered code improves.

5 Reasons to Refrain from a Startup Job Offering

noreply@blogger.com (Magnus Nord) — Wed, 15 Feb 2012 19:42:00 +0000

Working for a small company has a lot of benefits. It is easier to make your voice heard and get recognition for your work. Smaller companies sometimes take better care of their employees and offer benefits not available in larger corporations. Most of all, though, it’s a lot of fun!

Working in a startup is also associated with greater uncertainty. If the company is in a decisive period and management fails to make the right decisions, your job security is jeopardized.

Here are five things that you should ponder before accepting a job offer from a startup or small IT company.

1. Poor Management

Management is important. Poor management is disastrous.

Management is important. Poor management is disastrous. The problem is that new and small companies have inexperienced managers to a greater extent.

The first sign of poor management is a non-serious hiring process. This may indicate how other things are conducted as well. If you meet with the CEO and he/she is late or come ill-prepared, this is clearly not a good first impression.

2. No Business Plan

Ask to see the business plan, or at least ask about the company’s vision and the way they plan to get there.

The business plan is one of the things venture capitalists evaluate before investing. The business plan contains the company’s vision and goals. It should also cover potential customers, target markets and how the company expects to grow. All companies should have a business plan. If not a formal one, at least clearly stated visions and goals.

In addition to a business plan, they should also have a very clear idea of why they hire you. Ask for a written job description – this is especially important if you are hired for a key position or management role.

3. A Lot of Hot Air

Any talk about “90% there” is a bad sign. It pretty much just means they are not there at all. The old cliché if it sounds to good to be true, it probably is fits well here. If they promise you milk and honey, expect water and bread :-)

Having a vision and being able to sell the business is essential for success.

Personally, and from own experiences, I find realistic down to earth people more trustworthy. There is a trade-off here, though. Having a vision and being able to sell the business is essential for success. However, there is a fine line between being visionary and optimistic, and naïve and manipulating.

4. Inadequate Organization

An inadequate organization can cause problems. Holding several positions (being an owner, sitting on the board, and/or being part of operational management) cause intrapersonal conflicts which leads to bad decision making. Investigate the ownership structure.

5. Insufficient Capital

It takes money to make money. In Sweden, at least, you can get a credit report for a business as a private person. If you feel the least bit hesitant about the company’s financial situation, look it up. Companies won’t think twice about doing a background check on you.

Purposeful Branching

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

Version control, also known as revision control or source control, is an integral part of software development. Like chess, it is easy to learn the basic principles but takes a lifetime to master. Many teams end up in an impenetrable jungle of branches and merging.

Having a well thought-out branching strategy is crucial. This article covers the basics of branching, and suggests a branching strategy to use: branch by purpose.

Introduction

Table of Content
Introduction
What Is a Branch?
Merging: What Goes Up Must Come Down
Branching Strategies
Wrap-Up

Version control is important of several reasons. It allows sharing of the codebase within and between teams. It gives the ability to go back to earlier versions associated with specific releases, etc. It enables parallel development. And so on.

Version control, used properly, can also help keeping code tidy. For example, instead of commenting out blocks of code that “might come in handy” code can safely be deleted and brought back from the repository if need be.

Don’t keep blocks of code that are commented out
Code that is commented out is only confusing for others that read the code, and others won’t dare to delete it. Clean it up!

As a project grows in complexity, the importance of maintaining control of software versions increases as well.

What is a Branch?

What a branch is technically depends on the version control software being used. Generally speaking, when branching, two separate codelines are created. This allows developers to work on different versions of the code simultaneously. Or, as Wikipedia puts it:

Branching, in revision control and software configuration management, is the duplication of an object under revision control (such as a source code file, or a directory tree) so that modifications can happen in parallel along both branches.

You always start out with a single master branch, also called trunk. From this multiple child branches can be created. These, in turn, can have their own children.

In most version control systems the codebase can also be tagged. The technical meaning of this also varies between products. For example, Subversion makes no difference between branches and tags.

Conceptually, a tag is just a label connected to a specific commit. Tags make it easy to bookmark and find points in the code’s history, for example releases.

Branches are depicted in branch diagrams. The figure below illustrates such a diagram with two branches (named “trunk” and “branch”) and a tag (named “tag” – imagine that). The diagram also shows a merge (the green dashed arrow) from “branch” to “trunk”.

Branches can be created for several reasons. For example when a team works on a specific feature, or when the code enters a release cycle.

I divide branches into two main categories: Temporary and permanent. The former is temporary in the sense that it will eventually be merged back to the parent branch and then deleted. The latter, though permanent, is often involved in merge operations as well.

Merging: What Goes Up Must Come Down

Merging is the process of integrating two branches. The changes from one branch are incorporated into another branch.

While it is easy to create a branch (maybe too easy sometimes), merging on the other hand, can be tricky, cause headaches, and leave the resulting codebase in a volatile state. People can even get afraid of, and postpone, merging, so called “merge paranoia”. To quote Martin Fowler, one of the persons behind the agile manifesto, in his article about continuous integration:

One of the features of version control systems is that they allow you to create multiple branches, to handle different streams of development. This is a useful, nay essential, feature - but it's frequently overused and gets people into trouble. Keep your use of branches to a minimum.

As he points out, creating branches is an essential feature of version control systems, but you shouldn’t overuse it. On the other hand, some people may just accuse Mr. Fowler of suffering from a bad case of merge paranoia :-) Nevertheless, don’t create branches unnecessarily.

Don’t create a branch unless you’re willing to take care of it.
Orphan branches and branches that are not properly maintained will sooner or later cause problems.

One way to ease merging operations is to merge often. For example, in a temporary branch as the one below; merge regularly from the parent branch to the child. Then, right before assimilating the child branch (we are the Borg!); do a final merge to the child branch. In other words, the integration should be done in the child branch. You probably don’t want to break the parent codeline.

Branching Strategies

As mentioned, branches are created for many reasons. For example:

The code enters a release cycle.
A team is working on a feature that will take a long time to finish.
Custom changes for a customer.
To fix a bug.
Personal branches to work on different problems.
Experimental code and to try out ideas

In my opinion, these branches are not always justified and you risk ending up in “branch mania”. For example, it is better to incorporate customer specific changes in the main codeline. If you feel you can’t – the argument often being time related – you’re going down a dangerous path. But that’s a whole other story.

While the examples above may need to be covered, I wouldn’t call them branching strategies in their own rights. I prefer using the term branching strategy for the overall picture:

Rules for creating and maintaining branches.
Types of branches used.
Naming conventions.
Best practices and guidelines.

The branching strategy should contain information on how to handle releases, when it is appropriate to create temporary codelines and the rules for committing code. For example, in some branches (such as the branch used for normal development) it is ok to commit code as long as it builds and is tested while other branches may only allow approved changes.

I think a good branching strategy should have at least these three characteristics:

Make life as easy as possible for users.
Keep branches to a minimum.
Ensure parallel development is supported.

I will now briefly describe two strategies for release branching: branch by release and branch by purpose, of which I advocate the latter. Partly because it works well with agile development. Feel free to disagree and convince me why some other strategy is better :-) Both models work in conjunction with other temporary branches, and a branching strategy needs to describe these types as well to be complete. However, I will not cover that here.

Branch by Release

In this model, a new branch is created for the next release (see figure below) while the parent branch follows the lifecycle of the current release. Development continues in the new branch, while the old branch contains the released version. This means developers need to switch branch when a new version of the software is released.

When a maintenance release is required, bugs are fixed in the branch belonging to the release in question. These fixes then need to be propagated to subsequent branches.

Another important point is that all checked out code needs to be committed before the codebase is branched off – otherwise developers risk committing code to a branch that has changed purpose and is now staging area for a release. (This is because you have to commit code to the branch from where it was checked out.) Not very user friendly in my opinion.

Branch by Purpose

With this model, the purpose of a branch never changes. Instead a new branch is created to host changed requirements (see figure below).

One of the big advantages of this strategy is that normal development is always done in the master branch (trunk). This makes life easy for developers. It also works very well with continuous integration. Martin Fowler again:

In particular have a mainline: a single branch of the project currently under development. Pretty much everyone should work off this mainline most of the time. (Reasonable branches are bug fixes of prior production releases and temporary experiments.)

When using branch by purpose, it may be necessary to introduce a feature freeze period during which no new functionality is added. Only fixes and unfinished work are done after this point. When the code is deemed ready for release a branch is created and handed over to release management.

To support parallel development, a bridge branch may be created where teams can start working on the next release (see figure below).

Another solution is to branch off immediately when all features are done. This, however, somewhat breaks the branch by purpose paradigm, as it means fixes that could be considered part of normal development are carried out in the release candidate branch. If there are a lot of fixes initially, this also means a lot of merging back down to the master branch (see figure below).

Wrap-Up

Mastering version control management is important to successfully develop code together. Outlining how to manage branches – and choosing a strategy that aids users and facilitates parallel development – becomes increasingly important as a project’s complexity grows.

Finally, branch by purpose is a great model that fulfills the requirements mentioned. Normal development is always done in the same branch. Parallel development is supported across release cycles.

And remember, merge often and merge well! Don’t create branches unless you are willing to maintain them.

Agile Roadblocks: Lost in Translation

noreply@blogger.com (Magnus Nord) — Mon, 06 Feb 2012 20:13:00 +0000

In the series about agile roadblocks: obstructions for implementing agile processes in an organization, the time has come to “Lost in Translation”. (Please read the previous posts about stray team members and drowned by waterfalls as well.)

People are eager to migrate to agile processes such as Scrum. There’s a lot of talk about sprints, scrum boards and retrospectives. One thing that is overlooked is understanding why agile works and the rationale behind it.

Description

I am convinced that you cannot truly succeed with agile software development unless you understand the principles behind. It is not enough to merely apply the methodology. You have to understand why you do things, and why – if so – agile may actually work in your organization.

Knowing the reasons, and motivation, behind agile processes assist in evaluating and fine-tuning the process. Without the bigger picture, decisions may be contra-dictionary and the expected increase in productivity won’t happen.

Effects

The full effect of migrating to agile may not happen.
Agile practices are met with skepticism and suspicion.
Decisions are made that counter the benefits of agile development.

Detours

Educate everyone on why agile development may be successful. There are tons of useful resources online. If you are using Scrum, for example, start by reading the Scrum guide and this excellent blog post about the origins of Scrum by Ken Schwaber, one of the founders of Scrum.
Try to remember the big picture when making decisions. Ask yourself questions like “Will this lead us to a more effective implementation of agile?”
Formulate a vision and long-term goals. Evaluate progress.

10 Things Developers Do Except Code

noreply@blogger.com (Magnus Nord) — Wed, 01 Feb 2012 21:28:00 +0000

This blog is all about being an IT consultant and software developer. It covers everything. Everything except code. So, what fills a developer’s day other than coding? Here is a list with work day stuffing.

1. Meet

A lot of time is spent in meetings. Many meetings are directly related to actual work. There are also project meetings, organizational meetings, customer meetings, and so on.

2. Communicate

Phone calls, instant messages, e-mail. I’ve even heard some people still see each other in person.

3. Read

Participating in a software development project usually means reading. A lot of reading: Documentation, specifications, manuals, books about development, test cases, reports. The list goes on.

4. Write

As if it wasn’t enough to write the code, you have to document it as well ;-)

5. Supplementary training

In-house training and external courses are necessary to keep on top of an ever changing industry.

6. Tutor

Teaching others, for example new team members and customers.

7. Presentations

Preparing and holding presentations for management, colleagues, customers.

8. Wait

Wait for code to compile. Wait for meetings to begin. Wait in line for the coffee machine. Wait, wait, wait.

9. Configuration management

Maybe you’re not involved in setting up servers, configuring version control etc., but you are often responsible for setting up your own environment.

10. Socialize

In Sweden it is called “fika”. I think they say “tea” in England. I’m talking about coffee breaks.

Fixed Price Contracts: A False Sense of Security?

noreply@blogger.com (Magnus Nord) — Sat, 28 Jan 2012 20:17:00 +0000

Many customers prefer fixed price contracts. It makes them feel secure. They know what they will get, when they will get it, and how much it will cost. Or do they?

Pitching contractors against each other on a fixed price may seem like a good idea, but what effects does this have on bids, the project, and – consequently – the final result?

Saying no to a contract is difficult, especially for a small company. Estimated times and costs may therefore be questioned internally. The persons responsible for the estimates feel pressured to adjust them.

Eventually, the only thing left to change is quality: all other variables are locked in a fixed price contract.

Project Triangle: Only two things/sides can be changed without affecting quality

Probably the contractor doesn’t influence quality deliberately. Quality is, however, very difficult to measure. The project may deliver according to specs, passing all acceptance tests. Years later, however, when new features or integrations are required, technical debt may become a big issue.

Preconditions for a Fixed Price Contract

For a fixed price to even be legitimate, the following must be true:

Adequate requirement specifications.
A well defined change request process.
A thorough risk analysis. (This is true for all projects, but especially so for fixed price contracts.)
Agreed acceptance criteria: well-defined acceptance tests.
Working with a well-known technology in a proven environment.

If these preconditions aren’t fulfilled, the contractor should think twice before settling for a fixed price contract.

The nature of software development means you are always – more or less – working in a volatile environment. Of course, contractors compensate for this when bidding for a fixed price by introducing safety buffers.

Customer Risks

Pushing too hard for a knockdown price have implications. The customer faces at least three apparent risks:

Degraded quality
The project runs late
Collaboration suffers

Quality is controlled by the requirement specification and acceptance criteria. This only works to a certain degree. It is impossible to cover all aspects of quality through these mechanisms alone.

The quality of a project is affected in many ways. It can be difficult to spot exactly when and why quality degenerates. Some things that may be overlooked when on a tight schedule, that eventually affects quality, are:

Code is not refactored
Code is not commented
Insufficient tests

Contract regulations, requirement specifications, and so on, ultimately affects collaboration. The atmosphere becomes competitive and the parties start to blame each other instead of solving problems together. The customer becomes detached and hands over all responsibility to the contractor.

Conclusion

In my experience the customer and contractor both lose out on a fixed price contract. Obviously the contractor takes a big risk. While it might seem like the customer has nothing to lose, to get the most value out of the investment, it is better to choose another contract form.

As a customer, if you are not 100% sure there won’t be any changes, a fixed price can be a costly affair. Not only will you have to pay for any changes. There is also an overhead in terms of administration and contract negotiation. You also draw attention away from producing a high quality product maximizing business value.

Agile Roadblocks: Drowned by Waterfalls

noreply@blogger.com (Magnus Nord) — Mon, 23 Jan 2012 12:18:00 +0000

In the series about agile roadblocks: obstructions for implementing agile processes in an organization, the time has come to “Drowned by Waterfalls”. (Read the previous post about stray team members as well.)

Often agile processes slowly make their way into larger organizations. Parts of management may not even be aware of any changes. Others may be too rooted in existing processes and methodologies. They consider any change an annoyance that will eventually go away if you just ignore it.

So, how do you apply an agile development process when drowned by waterfalls?

Description

Development teams may be asked to use Scrum or other agile processes, although the customer and/or management uses traditional models or demand a fixed price contract.

Some argue, rightfully so, that you have to apply a methodology in full to achieve its full potential. Sometimes, however, you don’t have a choice.

While you will not be as successful applying agile, hopefully you can get some benefits from it. In any case, you have to relate to it somehow.

Effects

Resistance from managers to apply or recognize agile practices they are not familiar with, for example estimating in story points.
Mismatch between responsibilities of project managers, product owners and other key roles.
Failure to get the full effect from agile methods. Which, in a longer perspective, may lead to mistrust of agile development altogether.
Project managers may have difficulties when agile methods clash with traditional project management and processes.

Detours

A lot of agile principles are nothing more than common sense, and works well in traditional project models as well. For example daily stand-ups and estimation in size rather than calendar time.
The main reason why customers like fixed price contracts is that they think they know what they will get, and at what price. Try to offer them the same feeling of safety with other price models.
Make your case with management. Explain why you have to adopt all practices to be successful with agile development.
Get people on your team that have experience with Scrum/agile development.

4 Ways to Deal with Ineffective Meetings

noreply@blogger.com (Magnus Nord) — Sat, 21 Jan 2012 18:56:00 +0000

In a previous post, I discussed how to conduct effective meetings. However, if you repeatedly find yourself in inefficient meetings, you need strategies to deal with it.

Although this can be difficult, obviously you should first try to change the meetings culture of your company. In the meanwhile, or as a last resort, consider the following four ways to deal with ineffective meetings.

Enforce your own time box. If you know meetings tend to drag on: point out in the beginning of the meeting that you have to leave at a specific time. Refer to a prior engagement. If the time draws near and the meeting’s purpose has not yet been achieved, remind everyone that you are going to leave soon. This may help push the meeting in the right direction.
Limit attendance. It is often stressful to sit in meetings when discussions derail and become irrelevant, especially when you have a bunch of more important tasks waiting at your desk. Ask if you can be called in for items relevant to you. If there aren’t any more items on the agenda where you are required; excuse yourself and leave the meeting.
Question the purpose. If you are called to a meeting without an expressed purpose or agenda, ask the person summoning the meeting what the purpose is. Ask why your attendance is required.
Come well prepared. If you think there will be discussions about certain decisions: talk to people before the meeting. If you know what you want: prepare a statement and think about your arguments before the meeting. If others are not as well prepared, it is likely your proposal is approved. Unless, of course, it’s completely ludicrous :-)

As a final advice, think twice before bringing your own work to a meeting. This might be ok. On the other hand, it may very well be considered disrespectful and self-centered. You can even miss important discussions and decisions and really make yourself look like a jerk. In other words: be selective in what meetings you attend, but when you do, concentrate on the meeting.

Five Books All Developers Should Read

noreply@blogger.com (Magnus Nord) — Tue, 17 Jan 2012 12:47:00 +0000

Amidst the myriad of books out there, here are five I find worthwhile for all developers. These books do not cover a specific language or technique. Instead they provide a broader spectrum of good advice. If I had to pick one of them, it would definitely be The Pragmatic Programmer – From Journeyman to Master. This book offers some great insights into what the programming profession is really all about, and how to excel as a developer.

The Pragmatic Programmer

From Journeyman to Master

By Andrew Hunt and David Thomas

Because more important than knowing this or that programming language, is to learn how to think, act and become a passionate (devoted if you like) developer. If you don’t, you will never truly succeed at – or at least not enjoy – work.

This book covers practices like DRY (Don’t Repeat Yourself), debugging, testing and prototyping. It explains the benefits of mastering a shell and the editor you use. It also discusses project and team aspects of development.

Read it. Then read it again.

Design Patterns

Elements of Reusable Object-Oriented Software

By Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

Because it is the book about design patterns, and design patterns is something all developers should know. The authors are also known as the Gang of Four (GoF), a well known name in design pattern circles.

This book includes a catalog with 23 design patterns divided into creational, structural and behavioral patterns. Each pattern is listed with its intent and motivation, structure, consequences as well as sample code and known uses.

Clean Code

A handbook of Agile Software Craftsmanship

By Robert C. Martin

Because writing neat, readable code may very well imply less use of the next book.

This book is all about writing good code. Chances are you read much more code than you write, and writing clean, readable code is perhaps the best way to cut down technical debt. The book covers everything from meaningful names of classes and methods to how to write comments, exceptions and unit tests.

Working Effectively with Legacy Code

By Michael C. Feathers

Because technical debt is a problem that’s not going away. The book is especially useful for consultants working a lot with other people’s ~~mess~~ code.

This book defines “legacy code” as any code that without tests in place. This book covers things like how to get code into a test harness, and how to write tests without affecting existing functionality.

Johnathan Strange & Mr Norrell

By Susanna Clarke

Because you should take the time to read something else now and then (this is one of the tips from Pragmatic Programmer as well), and this is a really, really great book.

How to Setup Remember The Milk for GTD

noreply@blogger.com (Magnus Nord) — Thu, 12 Jan 2012 12:56:00 +0000

An efficient system for keeping track of things to do is a must have for anyone with a busy life. In this post, I describe my Getting Things Done (GTD) setup in Remember The Milk (RTM).

I can think of at least four requirements for a working task management system (read: a system I actually stick with and use):

It needs to be very simple, if not idiot proof (call it self insight).
It needs to be flexible and extendable.
It needs to be accessible from just about anywhere.
I don’t want to be bothered by stuff not relevant just now.

The secret to my system is that I don’t use a standard list to keep track of next actions. Neither do I to keep lists for each project, instead I rely solely on tags. Everything goes in to the Inbox – and is filtered automatically using smart lists.

Workflow

Everything is dumped in to the default RTM inbox. This serves as a universal bucket for me, where I put everything from ideas and notes, to things like project items and recurrent events. All items stay in the inbox until finished, at which time they are checked off as completed.

All new items are added to the Inbox list.
I sometimes tag items directly, either with a context or a project tag, or both.
Tickler items are created by simply giving an item a due date. Possibly making it recurrent.
Items neither tagged nor tickled end up in a smart list named Unsorted.
When a task without due date has hung around for too long, it will show up in another smart list called Smellers.
All context and project tags are reviewed regularly. (Of course, I have a recurrent task to remind me.) It is also easy to spot unprocessed items by simply looking in the Unsorted list. Attention is also given to untouched tasks in the Smellers list.
The icing on the cake is the TODO smart list. This is the only list with “next actions” and the only list monitored continuously, at least daily.

Adding stuff quickly
When I get some stuff to follow up from a conversation, or when having an idea on the go, I often just add it without categorizing it. Later, or at the weekly review, I process items in the Unsorted list.

The Setup

The complete setup consists of the standard RTM inbox, three smart lists and an arbitrary number of tags.

Universal Inbox

As I use the default inbox as the universal inbox, all new tasks end up here, whether they are added from the mobile application, the browser or sent via email or any other of the functions available in RTM.

As all items go into one list, it makes it really easy to perform searches, filter items, and so on.

Smart Lists

Smart lists in RTM are based on search criteria. Here are the three smart lists I use, and their respective searches:

Unsorted contains items not yet processed; tasks without tags or due dates.
list:inbox and status:incomplete AND isTagged:false AND due:never
Smellers contains tasks who have stayed uncompleted for too long. It does not contain recurrent tasks.
NOT addedWithin:"3 months from today" AND list:"Inbox" AND status:incomplete AND (due:never OR dueBefore:now)
TODO is the “next action” list. It contains items marked with the @action tag and items due on the same day (or for high priority tasks: tomorrow).
list:Inbox AND status:incomplete AND (tag:@action OR dueBefore:tomorrow OR (due:tomorrow AND priority:1))

Tickler File

A tickler file is implemented implicitly by the way I use smart lists. I never look at the items in the inbox directly. Instead, I use the TODO smart list as the “go to list”. Tasks with due dates, possibly recurrent, pop up in the TODO list when they need to be acted upon.

Wrap-Up

Well, that’s it! I hope you found this post useful. If you have any suggestions for improvements, please let me know.

Agile Roadblocks: Stray Team Members

noreply@blogger.com (Magnus Nord) — Tue, 10 Jan 2012 12:05:00 +0000

This is the first post in a series about agile roadblocks: obstructions for implementing agile processes in an organization. First up is “Stray Team members”.

To share resources between projects seems to be a more common practice than one would expect. What’s worse is that often it is done seemingly without good cause. Some managers do not understand the impact this has on productivity, and the well being of the individual.

“It is virtually impossible to divide time between projects without generating cross project noise.”

Description

Sometimes key resources, for example with unique competence, needs to be split across projects. Doing it routinely and without thinking it through is counterproductive, if not downright ignorant and foolish.

It is virtually impossible to divide time between projects without generating cross project noise. While working on one project you will receive e-mail, get questions and be asked to do things related to the other project.

Effects

Shifting tasks and focus is time consuming and decreases productivity.
The increased amount of stress has a negative effect on the individual’s well being.
Both projects lose momentum.
It is an annoyance for other team members when a resource they rely on is unavailable.

Detours

Make it more difficult to split resources across projects. Maybe approval should be required by a senior manager.
Minimize the effect of a resource sharing. Let people shift projects as seldom as possible, for example weekly.
If you are a shared resource yourself, try to do the following:
- Minimize cross-project noise by applying mail filters and other barriers between projects.
- Let everyone know that when you’re working on that other project, you are indeed busy working on that other project – and you are not going to answer e-mail, have time for meetings, and so on.
- Avoid leaving open ends when switching between projects.
- Write a note to yourself about what you were doing and the state of things, before starting to work on another project.
This might very well be an organization issue and part of corporate culture. In that case it really comes down to convincing management that this really is an issue.

How to Conduct Effective Meetings

noreply@blogger.com (Magnus Nord) — Sat, 07 Jan 2012 19:30:00 +0000

Have you ever found yourself in a room with people discussing the internal test server’s footer size, or some other similarly insignificant detail? Making things worse, did you go to the meeting because you thought you were finally going to make a decision about that business proposition that could make or break the company?

In my experience it is very easy to have a meeting derail and turn into a complete train wreck. If the person leading the meeting fails to be disciplined, or come ill prepared, the risk is even greater.

Purpose and Agenda

A meeting should always have an expressed purpose or goal that is known to participants prior to the meeting. This is not the same as an agenda. The agenda should guide the meeting towards the goal.

When the meeting begins it is a good idea to remind everyone of the purpose.

Participants

Participants should be selected so that the purpose can be achieved. Including people that do not contribute to the purpose being fulfilled only increases the risk of derailing.

Similarly, failing to invite a person required to achieve the goal, is equally unproductive.

The Chairman

The chairman must have mandate to actually lead the meeting. This includes having the authority to cut off irrelevant discussions and steer the meeting towards its purpose.

This can be extra tricky when higher ranking managers participate. The chairman may hesitate to interrupt higher ranking individuals. On the other hand, they may have to participate to fulfill the purpose. If they are not: Do not invite them.

Time Boxing

Time box the meeting to increase the chance of it being productive. If participants start to go astray, remind them of the time box and also the purpose.

Meeting Discipline

Meeting discipline is important. This is primarily the responsibility of the chairman, but if enough people wander off it helps little if the chairman tries to maintain order. In my experience managers are more inclined to stray, maybe because they are more used to, and feel more confident, talking in front of the group.

Conclusion

To sum it up, keep the following three things in mind:

Always prepare the meeting well. Do not forget to formulate and distribute the purpose of the meeting, together with an agenda.
Only invite people necessary for the meeting’s purpose.
Most importantly: Successful meetings are a team effort. Everyone needs to be on board and adhere to meeting rules.

In an upcoming post I will give a suggestion for meeting guidelines.

Lost on Your New Assignment?

noreply@blogger.com (Magnus Nord) — Sat, 07 Jan 2012 12:41:00 +0000

When you start on a new assignment and land in a new environment, it is easy to feel a bit lost and confused. As a consultant, especially, you feel an obligation to contribute right from the start, and bring value to the team immediately. Easier said than done! Here are some advice that might help.

Be Resourceful

“Fixing bugs is often appreciated by the team as it is not considered the most glamorous work.”

Face it: You’re not there because the team has a lot of spare time. Chances are you have been hired for the exact opposite reason. This means no one is likely to help you out much. Even if they do, they probably feel they have more important things to do. This is no doubt contra productive, but it is often how people react under stress.

A common task on new assignments is therefore to read up on stuff. You are handed piles of technical documentation and manuals – anything to keep you occupied.

It is going to be up to you to take initiatives. Keep an eye open for well defined, low priority tasks. Here are some jobs I like to do in the beginning:

Fixing bugs is a great way of both contributing and getting familiarized with the code. It is often appreciated by the team as fixing bugs is not considered the most glamorous work. It is also often fairly easy to validate the result.
Configuration Management (CM) tasks are often not domain specific, and chances are your previous experience comes in handy. Sometimes these tasks haven’t been prioritized, even though they might very well be important to productiveness and efficiency. Many CM tasks are relatively independent from other work, making them perfect candidates for new team members.
Pre-studies and evaluations (spike solutions) are another example of independent tasks where previous experience is valuable. Others on the team may take things for granted. It might even be an advantage to use a new resource, as they look at problems from another perspective.

Be Perceptive

Be perceptive to the work environment. Try to get a feeling of team dynamics, problems they face and how they apply methodologies and processes. Are there any unspoken rules? Pay attention to how the team interacts, review each others work and give feedback.

It is never a good idea to start criticizing, or talk about how things “should” be done, before you get to know the other team members and the appropriate context for giving feedback.

Perceptiveness might also help you pick up possible further business and areas where you can contribute.

Be Open Minded

Ideally you have a job description of what the customer expects from you: an expressed reason why they hired you. However, once there don’t be surprised if the job description does not match team reality.

Sometimes this calls for a discussion with your manager or sales rep, perhaps canceling the assignment altogether.

Other times, you might simply contribute more by helping out in areas outside the job description. Always make sure you fulfill any obligations you have, but if you have key competence in other areas, help out there as well. It will be worth more to the customer. And to you.

Be Social

As a consultant you might not think it is necessary to participate in certain events and meetings. (Sometimes you are not allowed to.) Maybe you feel your time is better spent reading up on documentation or getting your hands dirty with the code.

However, meetings and other team activities are a great way of getting to know project internals and team dynamics. Participating in social events might give insight into why certain problems exist, and the context in which the team works.

Try to have lunch and coffee breaks together with other team members. If they eat out, tag along. If they bring own food, follow their example. Not only is it fun, but a lot of interesting discussions take place off radar in social contexts.

Be Relaxed

“Relax! Accept a feeling of chaos.”

Finally, relax! Accept a feeling of chaos. You are most likely overwhelmed by everything from code setup, new tools, names and roles of team members, logins and passwords to mundane stuff like time reports and finding the coffee machine – not to forget how to make it brew the perfect cup.

In the midst of all this, it is easy to lose the foothold. Keep your calm, though. After a couple of weeks you will feel much more comfortable, sitting at your designated desk in the team area sipping away at a perfect cup of coffee, working your way through the code like you’d been their all your life.

U669NS7ZZXCT