Mobile Me iDisk and rsync

I’ve been using Mobile Me since 2002. (Then it was called .Mac). One of the features I really like is the iDisk. This is really convenient when you have to transfer large files. Also, I use it to keep a set of files I need again and again for my work as an agile coach. To make the access transparent and fast you can keep a copy of your iDisk on the local Macintosh HD and use it like any other drive. There is a sync process running in the background taking care of the data syncing. Very nice and convenient. In the beginning I could put a symbolic link into the local iDisk to reference a folder with the files on my local hard drive. Then the files were synced onto the iDisk in the cloud and I could access them from anywhere.

However, with the release of Leopard this stopped working. Well, rather annoying but not a real big problem. I just created a folder which I kept up date manually. But, since the iPhone has an iDisk app I started to read and re-read certain documents while on public transport. As you can guess, it happened again and again, that I forgot to do the manual update and therefore could not read important documents.

rsync to the rescue. With rsync you can keep folders in sync. I use it to keep the folder on the iDisk an exact copy of the folder containing the documents.

Well, next problem. Now, I have the copy process automated but I still need to run the script manually. The fix for this is crontab. Crontab is a list of scripts to be executed by the cron demon at certain times. I cannot tell you how much I like that OS X is Unix based. A nice UI with the power Unix underneath, what a great combination.

Now at midnight, the documents are automatically synced from the local folder on my hard drive to my iDisk. There I can access them using my iPhone or my notebooks. (iDisk also has a Windows client).

If you run into the same problems, then hopefully this shed some light onto it.

Productive Meetings

Don't know what your experience is like, but for me it is the following. Meetings are much more productive when someone is standing at a white board and writes down ideas, risks, problems and what have you. I am sure every single human being who has attended enough meetings has observed the default pattern -- or anti pattern -- in meetings. Everyone has their point of view and does all necessary arguing to protect their idea. They fight each other instead of pulling together towards a common goal. Often after a long and useless meeting it is commonly decided (the only agreement) that another meeting is needed.

One way to counter this behavioral pattern is to mail out an agenda with all the topics and asking the participants to prepare. This might help but most often it does not. I even doubt that every recipient of the mail does read it entirely. It usually drowns in the sea of more important emails.

Now, imagine you are in a pissing contest meeting and someone gets up and starts to write the different points clearly visible down. In a heart beat the whole meeting has structure, everyone turns their head towards the board. Not the loudest voice is heard but all ideas. Often, after some time the whole group is working together towards a -- just identified -- common goal. If you don't believe it, then give it a try at the next deadlocked meeting. You will be amazed how much power a white board and a marker in hand can create.

Why am I writing this? Well, Scrum has this at the core of all of it's meetings. In Scrum we have four different meeting types. Sprint Planning meeting, Daily Scrum, Review and Retrospective. Usually each of those meetings is moderated by the Scrum Master. It might be moderated by someone else but it is always moderated! The medium to write on are either index cards or PostIts which are aranged on a white- or corkboard. Those cards are then updated and rearranged during the course of the sprint. A very visual way of management. Alistair Cockburn named it accordingly: Information Radiators.

Next time your are stuck in a non productive meeting just get up and start to use a marker and whiteboard. Everyone in the rooom will be grateful.

The future is Lean Agile.

PS If you are interested in a simple way to moderate a meeting then try out Edward de Bono's Six Thinking Hats

Pomodoro Technique

About one and a half years I made a huge mistake. A mistake which cost me lots of productivity. One and a half years ago I read about the Pomodoro Technique and was excited about its approach. I even printed out the free PDF. My mistake was to totally forget about it. So never read the PDF and did not learn about this great technique for too long.

Since I read a lot of books from The Pragmatic Bookshelf, I was surprised to see that they published a book -- The Pomodoro Technique Illustrated -- about this powerful approach. So, I got the book read it over the week-end and finished with the free PDF from Francesco Cirillo on the following Monday. Reading about the Pomodoro Technique was a great and enlightening experience. I come from an agile background and do agile software development since 2001. First XP and then added Scrum by 2004. In my professional life I do Scrum trainings and agile coaching. So, it was great to see the similarities between Scrum and the Pomodoro Technique. It made perfect sense to me from the get go.

Well, needless to say that I am a convert now. Being a consultant, I am often on the road at customer sites and only focusing on one thing. However, between projects or every couple of weeks I am working at the home office for a couple of days. During those days I have to work and catch up on many different things in a short time frame. In the past it was hard to get going and keep the overview. Too many urgent tasks, and at the end of the day the feeling that something important was forgotten. Pomodoro Technique to the rescue. Know I keep an Activity Inventory up to date and on my office days I go through that list and identify the most important ones, either by date or by priority. I get about 10 Pomodoros done in one day. At the end of the day I reassess what I was planning to be, were I actually am and how I could improve. With that in mind I go into the next day.

As I had mentioned, there are some stunning similarities between Scrum and the Pomodoro Technique, here is a list of how I compare them.

Scrum             Pomodore Technique

Product Backlog   Activity Inventory List
Sprint Backlog    To Do Today List

Sprint Length     Pomodore Length  

Review            Assessment at the end of the day

Retrospective     Assessment at the end of the day

I can only stress how effective the Pomodoro Technique has proven to be for me and I would recommend it to anyone who has to juggle several tasks in parallel. If your are an agilist then applying the Pomodore Technique should be rather easy.

Ring …. 25 minutes over – 5 minute break and then of to my next task.

Agile is about Deliverables

I just came back from a wedding which took place in a small remote place in northern Bavaria, Germany. What does a wedding have to do with agile software development? Nothing at all, but quite a bit.

The bride and the groom are both living in Paris, France. She is from Germany and he from Algeria. The location of the wedding was chosen for one single reason. A relative of the bride´s family owns a hotel. This guaranted excellent service for a competitive price.

Ok, now I will elaborate about my epiphany I had there. But first here it is:

Agile is about deliverables

whereas

Classical processes are about completed work steps

What do I mean with this? In classical, Taylorism style driven workflows you are completing work steps in a long sequence. If you have 10 steps and are done with 8 you have 80% completed.

In agile it is about usable deliverables, value. It either exist and can be used or you better don't mention it. 0% or 100%.

Now, as you can see from the geographical distribution it was not straight forward for everyone to be there on time. Some people only had to drive, others took the plane or train. Many of them had a combination of all sorts of meaning of transport. Also, as it happened, there were snow storms all over Europe with tons of snow and really chilly weather. Those weather conditions caused quite some traffic havoc.

Nevertheless, every single person was there on time. Not one single one was late. They all were standing in the church when the bride and groom walked down the aisle.

They delivered. They delivered value by being there and paying their respect. I am sure many of them had quite a stressful adventure behind them but all of them only smiled at the couple.

The alternative would have been the following. Imagine the phone ringing and a conversation sounding somewhere like that: '... we are 90% there. In the beginning everything went according to plan but then there was an accident because of the weather ...' or '... we heard about the weather but we assumed everything will be fine, but now the airport is shut down for a couple of hours, we will arrive tomorrow. Guess this is ok?'

Don't track and communicate your progress in regards to your work steps but deliver value. This is the ONLY important thing!

It was a great wedding, mainly because everybody was there!

SW development is empirical

One should learn from previous experiences and previous mistakes. Even better, one should learn from others experiences and mistakes. In SW development, we have been very good at adapting knowledge from other industries. This has been especially the case with the manufacturing industry. From the Taylorism to the more recently influences of Lean thinking, the SW development theories and practices have borrowed a lot from the manufacturing industry.

But we need to be very aware of the differences in our industries. Manufacturing typically deals with repeatable processes, while SW development is empirical.

In manufacturing, a repeatable process converts consistent inputs into consistent outputs. Repeatable means that the conversion of inputs to outputs can be replicated with little variation. In repeatable process, a small variation on inputs typically translates to a small variation to the outputs. But this is not the case with SW development.

SW development is really creation. And creation is not a highly predictable and repeatable thing. There is too much complexity and variability in the SW creation process; SW creation is an empirical activity.

Dictionary.com Empirical definition:
1. derived from or guided by experience or experiment.
2. depending upon experience or observation alone, without using scientific method or theory, esp. as in medicine.
3. provable or verifiable by experience or experiment.

In manufacturing, a great deal of work is about putting pieces together to build a specific thing. Whereas, in SW development, these pieces are often created, re-created, or customized every time. This is not to simplify the kind of work going on a manufacturing assembly line. My point is that the manufacturing discipline and its pieces of work are more mature, stable and well understood than the SW discipline, and its pieces of work.

Further, in SW development a small variation on inputs can result into a big variation to the outputs. For example, small changes in requirement or the architecture can result in huge differences in the software development and its output.

Are you Ready Ready

I’ve been to the Scrum Gathering in Munich this year. In his keynote Jeff Sutherland describes how he gets Scrum teams hyper productive. Essentially, you need to get your stories to Done Done as fast as possible. However, often too many unknowns do exist when a user story is being played. To fix this problem Jeff introduced, as on of his key ingredients, the concept of Ready Ready. Ready Ready removed disruptions and waste caused by issues being clarified with customer or others. He even suggested the use of a Ready Ready checklist to make sure that stories to be implemented do comply with the definition of Ready. Looks like the ‘Definition of Done’ gets a sibling -- ‘Definition of Ready’. The enforcement of DoR helped to increase the flow of stories to the anticipated state of Done Done and thereby increasing the productivity. Applying Ready Ready was core to create hyper productive Scrum teams. It came 2nd after 'Everyone must be trained in the Scrum framework'.

This is essentially what I have been doing or better trying to do in my last projects. However, the Ready Ready idea is very easy to explain and very convincing. Especially since it comes from Jeff Sutherland.

From now on my Product Backlog items will be Ready Ready before they can move into the Sprint Backlog.

The Agile manager is a master programmer

Lean thinking by Toyota says that managers must go and experience at the real place of work (gemba in Japanese) to learn what is going on. In the manufacturing field, gemba means the shop floor. When trying to apply Lean Thinking into my Agile management style, I feel like uploading the codebase from the repository into my computer and looking at the code; or even going further, I should be pairing with the programmers in my team.

The “real place” in software development is the crafting of the software. Therefore the Agile managers should be master programmers who can craft the code, and apply the development practices.

Of course not every master programmer will make a good Agile manager; and, on the other hand, not every traditional manager will make a good Agile manager. Either one will have to master several complementary skills that will empower a good Agile manager.

I have seen great traditional manager became great Agile managers, and great programmers became great Agile managers too. In both cases, the winner (the new Agile manager) did not stand alone. The whole team benefits at the end.

The manager who is new to Agile is to be empowered by the Agile team. And the programmer who is new to Agile is to be empowered by the team, including the Agile manager. Empower the team. Really. Don’t forget to empower the new-to-agile-manager. Please invite your manager to (once in a while) craft the software with you.