Building Blocks

A while ago I went to a lecture at Avega with Jim Coplien. It was quite interesting, since the subject changed back and forth from DCI to Lean. But given my last post I had to write this down as well.

This comparison is more between 7 Habits and GTD. A key part in 7 habits is to “begin with the end in mind”. In a tactical perspective this means focusing on doing the right thing at any moment. The doing part in GTD helps you protect yourself again procrastination and other things that might prevent you from ever doing a specified task. But there is also a built in part of GTD that just focuses on doing.

Now during Jim’s lecture he described the word Muda. For those of you who didn’t follow the link the word is Japanese and means doing things that adds no value. There is a risk in GTD that you will do things that have little value for you.

Given the nature of GTD where you can go through many tasks in a short period of time, the chances are that your productivity might still increase when using a personal tracking system. But there is a chance that your running your engines wastefully. If you and up doing something that does not add value to the end result then you could have ignored doing it.

You can see it as traction, the more tasks of this type you have in your list of things to do, the more you need to work to go the same distance.

One of the highlights of the past week was that I went to a free lecture by Mary Poppendick at Crisp in Stockholm. It’s quite interesting how your thought processes can be activated when shown the right materials.

During the presentation Mary gave a brief overview of both Kanban and Scrum, emphasizing on measuring the capacity of the team. Which started me thinking about capacity of one-self and to do-lists.

In GTD, the capturing process is designed to produce a lot of small tasks, that are ready for consumption at moments notice. But there is no measurement of capacity. Meaning that if your capacity is lower than the average arrival rate of tasks, you’ll end up with a never-ending inventory of work.

Now if you read my previous post on Inventory in software, you should know that I believe that inventories can be a great source of waste. As soon as you ad an inventory that inventory consumes time and money in management.

This means that what you might end up with is an inventory of tasks, so large that the management time for it steals valuable time from other tasks.

Enter Pomodoro. Pomodoro like GTD also focus on getting things done. But it reminds me more of a personal scrum system. The focus is much more on estimation and knowing you capacity.

By knowing your capacity, it can help you prioritize items and even see for your self that. Given the current capacity you will never reach item X. If you know this, you also know that unless you change your plans to give space for item X you might as well give up on the idea of ever doing X.

The way Staffan Nötenberg recommends measuring your capacity is by crossing of all your finished “tasks” or “Pomodoros”, in essence giving you both the satisfaction of completing it but also giving you visible statistics for how well you process is working for you. This and given the built in task size of Pomodoro, makes it easy to know your capacity. Which should help you when you are reflecting on your plans.

Where the two techniques differ is in doing. David Allen suggests three models of doing, Pomodoro could be seen as a fourth. But Pomodoro focus on committing to tasks on a day by day basis, where GTD lets your intuition play a role in which task to do next.

Both techniques imply structure, and I see Pomodoro to be the more “formal” of the two processes. Which leads me to concluded that the technique best suited for a given person is highly individual, not only in how the person wants to work, but also in what your tasks might look like.

It’s quite possible to combine the two, though I have yet to try that out. Apparently these things take time to adapt to your own personal way of life.

As I mentioned in a previous post I’ve been working on getting the Android application, Shuffle to synchronize with Tracks.

Now that the work has continued this post describes how this feature of Shuffle works. This feature is released with version 1.4.0 of Shuffle and will be available on the Android Market. Special thanks to Andy whom put up with my loads patches.

This feature affects no other features in Shuffle, it simply allows the synchronization between the two systems. If you never configure the synchronization feature it will never affect you.

Configuration

To configure Shuffle to synchronize with tracks start the Shuffle application.

Press menu, and select settings. Select the option called “Change synchronization”

This will open the settings file. Here you can enter the URL to your Tracks installation, username and password. You can also specify the settings for the background synchronization. Simply change the combo box between the different settings.

There is some validation in the settings screen. If you enter a invalid URL the text will change to red to display this.

When you save your settings they are validated by trying to download the contexts from Tracks. If Shuffle cannot get any content from Track with the specified settings it will not save them, but instead display an error message saying that something is wrong with them. You can always cancel.

The Synchronization

Once Shuffle is configured to synchronize with Tracks. You will have an extra button available in the menus across Shuffle. Pressing this will start the synchronization process. To notify that a synchronization is in progress Shuffle will also add a notification message during the synchronization. This is to notify the user that Shuffle synchronizes when doing background synchronization. If you click the notification Shuffle will display the synchronization view.

The synchronization synchronizes the entities in Shuffle in the following order: Contexts, Projects, and Tasks. During a synchronization Shuffle will look at the modification date and select the version of the entity that was latest modified, and merge this entity with the local entity or remote entity, which ever is updated.

Tracks only accept Tasks that have a context set, currently these tasks are excluded from the synchronization process. If you have such task a message is displayed at the end of the synchronization process.

I did some open-source work last week. I created a synchronization option in the Android program called Shuffle. Allowing it to synchronize with the web tool called Tracks.

Here is a description of how to use the synchronization in Shuffle.

Configuration

Open the settings menu, select the Change Synchronization option.

Specify your Tracks installation URL, username and password.

Make sure that the URL is correctly formatted and that there is no ending slash in the url:

this is wrong: http://my.gtdify.com/

this is correct: http://my.gtdify.com

Usage

On the menu available in most screens there is a button called synchronize. Click it and the synchronization starts. It will first synchronize the contexts, then project and last the Tasks.

Details of the synchronization

The synchronization will try to reduce duplicates that might occur between Tracks and Shuffle. This is done by looking that the description of tasks and the names of contexts and projects.

The synchronization works with a server wins, modification date oriented approach. Should there be a conflict the latest version will win, and in it will try to take as much detail it can from Tracks.

Also, using the “Delete completed” option removes the tasks from Shuffle. This means that the synchronizer wont find them and can’t mark them as finished in Tracks. If you use this synchronization I recommend letting the synchronizer take care of the “cleaning up”. This will be done the second synchronization that a task is complete on.

That is, if you complete a task and synchronize, both tasks will be in both systems as completed. Synchronize again the the task will be removed from Shuffle,  but maintained as completed in Tracks.

Happy new year everyone!

To celebrate I’m posting this screenshot.

I’ve been using Shuffle on my HTC Hero for a while now, and been lacking the ability to synchronize it with a online desktop-enables solution.

Well, the above screenshot is the result of what I’ve been doing these last two days. It’s Shuffle that’s synchronized its contexts with a Tracks installation. Still a lot to do, probably a day or three at least. But it’s looking promising.

Happy new year!

Funny thing. Some might remember my how I work with code, where you keep a list of issues you figure out as you work with the code.

Apparently Kent Beck presents this as a pattern called Test List.

I’m trying to embed it below, we’ll see how it goes.

Btw- if this embedding thing is more annoying then helpful, please let me know.

Roughly 1½ year ago I produce a plugin for team-system to allow me to report bugs quickly though as I’m working with the code. The idea behind it was from the Fogbugz intoruction video where I think its Joel Spolsky who says something along the lines of “it should take less than 30 seconds to report a bug, else the lazy developer wont do it.”

The resulting plugin was a short-command that started up a UI with a single textbox on it. I wrote the “bug”, and it created an bug item in Team System with my specified title. It also made sure to “record” the context of where I was in the code when I wrote the item. In this case, file and line-number.

In a previous post I discussed how to get things done with teams.

Consider having such a plugin to your IDE that will report the item generated to a central inbox, central for all developers. The item could be a bug, it could also be a suggestion for refactoring, request for more tests, idea for a new feature and much much more.

With such tooling in place, a team could quickly shed some light on issues that aren’t directly related for the delivery of the current iteration. But more related on the values of the team or the ongoing quality of the code product. The issues can be reviewed and managed during a weekly meeting, resulting in product backlog items, sprint backlog items, discussions, meetings. Or just a sense of common values within the team.

I wrote a blog post about how I work with code. The basic idea is that I record actions that I need to take as I work with the code in a format that is readable by the other developers in my team. In case I get run over by a truck they can see where I took off. Also its a way to record what and why I’m doing as I’m progressing through code written by someone else.

I got a response from a former colleague Anna who claimed I wouldn’t need to do it if I had automated tests. Even though Automated tests doesn’t have much to do with personal productivity at first glance, a recording of something that needs to be fixed could be a unit test. If developers run the tests often they are in my shelveset and they can see which pieces of the code I perceive bugs in.

In fact this is exactly what is being done as I work with TDD. Giving support to the fact that TDD can increase the productivity of a developer, following the same ideas presented in Getting Things Done.

Tests however doesn’t record suggestions for design improvements or actions such as “Ask x about icon y”. At Least not as far as I know.

With this concept of quickly creating new tasks and with the GTD and How I work with code ideas. An idea for a new tool popped up in my head.

The tasks that I create based on working code, are cluttered with my own opinions. With the Getting Things Done approach we could have an inbox with Action times created as team members work with the code. In a Weekly review each item in the Inbox could be manage, prioritized, discussed. Some items result in items on a sprint backlog, others simply result in other team members explaining parts of the system to each other.

This weekly review could be conducted outside the normal delivery cycles, as they are partially meta tasks for achieving a common mindset of how and what should be developed. The result could be new features, refactoring, extra testing, reduced bugs etc.

In Getting Things Done, David Allen discusses a work flow of how to handle things you need to-do. Now when I work at a coding task I often find places that could need some refactoring love, or needs to change in some way. There might be potential bugs, violations of DRY and all that.

What I’ve seen so far is that some developers tend to fix these “issues” as they find them, working towards a sort of zero-deficiency or a “if I cant read the code, chances are someone else wont be able to either”  motivation.

Working with code in this manner can have some interesting side-effects. To name a few.

• It takes longer to resolve a specific task
• It could result in team conflicts a some developers perceive written code as “theirs”
• It could introduce bugs, if the original intent of the code isn’t captured by tests (not even 100% code coverage will guarantee this).

What I like to do is to finish the task I’m holding as fast as possible. The reason for this is simple; others are relying on it. But while I finish the task I notice these things that needs to be changed, fixed, or clarified. Code items that require attention in someway. What I tend to do instead is to create a new Task to represent this change.

Creating a new task as several benefits.

• It allows delegation and parallel execution of code changes
• It allows the task to be discussed by the team
• It allows me as a developer to finish my current task, without having to fill up my brain with new things to-do
• It allows me to finish the task faster
• It allows the new tasks to be prioritised by the team
• It reduces the chances I need to context switch
• It allows me to work on just one task

Now or the last one I recommend reading Eric Brechners blog post about making your world easier