Tag Archives: team

The Ballpoint Game – A Scrum Simulation

I recently played the ballpoint game for the first time and was impressed…

  • … how clearly it demonstrates the different phases of a team going through the ‘storming, norming and performing’-phases for everyone – even for management spectators.
  • … how the iteration-rhythm helps to keep focus and increase the team performance to a very high and predictable level.
  • … how easy it felt to deliver good results once the team started to perform after the 2nd and 3rd iteration.
  • … how much fun it can be, to be part of and work in a cool software develoment team.

You can find various explanations on how the ballpoint game is organized and played.

Here is a nice video that illustrates what happens through the iterations: http://www.youtube.com/watch?v=d4-El7gJuZE

Thanks to Stefan and René for the inspiration!

Consistent Development Environments using VirtualMachines

As a development team we always run into situations where we have trouble setting up a proper development environment for each of the team members to get going or add new staff on the go. It annoyed me every time since it causes a lot of unnecessary communication and friction.

I often heard of virtualization but never actually played seriously with it. The idea is:

If we could have a virtual machine for every project that contains an equivalent environment like the production system, everybody working on it…

  • … could just rely on his development environment by just starting the VM without having to set up anything half-baked themselves.
  • … could use his favourite working environment OS, IDE and tools on which they are most comfortable and thus happy and productive.
  • … could work on their own checked out working copy using version control.
  • … could immedately see what they built refreshing the local browser or starting Unittests on the VM via ssh to check their dev increments.

We used http://www.virtualbox.org. A good starting point to get to know VirtualBox better and learn how to start your first virtual machine: https://help.ubuntu.com/community/VirtualBox

Our target was to be able to startup the development VM as guest system on any developers development machine being the host system, open a browser on the host (!) and call for example http://develop/ to see the webroot of the VM. Additionally we set up samba and ssh on the VM in order to have the webserver’s webroot on the VM available via the filesystem. In order to do that you need to…

  • …start your VM with networking set to ‘Host interface’ instead of the default NAT. This is explained in detail on this page (sorry German) http://www.nwlab.net/tutorials/virtualbox/virtual-networking.html – for me it was tricky to get the guest machine available on the host and have internet access at the same time.
  • …edit the hosts file (on OSX ‘sudo nano /private/etc/hosts’ and reboot) on the development machines and add something like the following line: ’192.168.56.101 develop’. To find out the IP enter ‘sudo ifconfig’ (OSX/Linux) on your host system after you have started the VM. You will see aditional adapters set by virtualbox and the IP address.
  • …configure /etc/samba/smb.conf on the VM, restart samba and connect (e.g. smb://develop/webroot). We check out a working copy of the applicaton under development directly onto the webroot and create a new PHP-Project there in our IDE. Update and commit directly from there.

If you search the web for ready-made VMs you find mostly VMware images. You can not run them directly in VirtualBox and need to convert them.

Under Linux you can convert the VMware image (.vmdk) into a VirtualBox image (.vdi) like this:

sudo apt-get install virtualbox-ose virtualbox-ose-guest-utils;
sudo apt-get install qemu;

qemu-img convert xxx.vmdk xxx.bin;
VBoxManage convertdd xxx.bin xxx.vdi

Install the required packages with apt-get install once. VBoxManage is part of VirtualBox. The last two lines do the conversion.


We ended up creating a fresh install from a Debian 5 netinstall iso. The iso-file can be mounted as CDROM on the creation of the new VM with VirtualBox. Receipes for setting up the appropriate LAMP environment with apt-get install can be found on the web. You only have to do it once. Save the state of your VM afterwards.


There are ways to generate a virtual machine from a physical server. Use Google to find receipes. I used http://www.partimage.org on a Debian Etch system with the live CDROM from http://www.sysresccd.org. This requires that you are able to umount your filesystem or rather boot into the live cd on the production/staging machine in order to generate the partimage.

You mount an external drive over the network or a usb harddrive. The partition (e.g. /dev/sda1) you would like to backup must be umounted. From the live cd you can see your partitions, including attached usb drives, with the ‘fdisk -l‘ command. Just mount the target (e.g. /mnt/usbdrive) and start partimage from the commandline. Dialogues guide you through the image creation.


In case you wonder what is meant by the ‘Host key’ to enter or leave a running VM with your mouse… it is the right (!) Strg-Button on your Keyboard.


I just installed Ubuntu Server on a VM from my MacBook. To have a usable keyboard once you logged on to the new VM, you must do the following in order to have a keymap including the pipe symbol, braces etc.:

  • sudo apt-get install console-data; #to install the keymaps
  • sudo loadkeys mac-macbook-de; #to set the keymap for German MacBook

Once you have done that, you can use your right Command-Key as ‘Alt-Gr-Key’ like on a PC keyboard. The pipe symbol is then typable with ‘Alt-Gr + >’, Braces and Brackets are typable via ‘Alt-Gr + 6,7,8,9′.


This is how you copy a virtual machine using VirtualBox tools:

$ VBoxManage clonevdi /Users/marco/MyMachine.vdi /Users/marco/MyMachine_copy.vdi
$ VBoxManage internalcommands setvdiuuid /Users/marco/MyMachine_copy.vdi

Incrementalists vs. Completionists

I have just finished the book ‘Managing Humans: Biting and Humorous Tales of a Software Engineering Manager’ by Michael Lopp and I would like to recap the idea behind the 2 identified types of ploblem solvers on a development team. These are their characteristics:

  • Incrementalist: They are driven by constantly making small forward increments. They are aware of available resources and the landscape in which they operate at any time. Since they know that there is no final solution, they are good brainstormers to come up with quick solutions. They love discussions and drive progress.
  • Completionist: They need time to figure out the plan to analyse and solve a problem before they start moving in a direction. They apply a strategic vision to integrate their solution into the greater picture.  If a Completionist is quiet, is does not mean he has nothing to say. It is just unlikely for him to talk about something without a fully formed plan. After having thought all through, the Completionist knows exactly what to do.  It is the architect type of guy striving for a perfect longtime solution.

In the end both types like to get stuff done. The difference is just how they get there and that is exactly the point around which both regularly argue with one another.

If you think about your team and who shows tendencies towards one of the two types, how can this insight make your team communication and problem solving habits more effective? As a team lead you definitely need both types and it is your responsibility to engage both in a healthy discussion.

Ressource Performance Management Plan

I am a fan of good receipes and checklists and just discovered the podcast “The Managing Software Development (MSD) Show” by James Edgell, which I highly recommend for all folks being responsible for IT-people and in the end for what they produce.

The value of your software development resources (people) consists of two things: their technical knowledge and their behaviour. The first can be developed by training and gained experience, the second is harder to change. And since everything is about bahaviour in people management, we also focus on it in terms of performance measurement.

James recommends the following:

  • Identify important abstract behaviours (see following list).
  • Measure the performance of every desired behaviour for each of your directs at regularly scheduled checkpoints. Scoring is from 1-5, where 1 is least demonstrated and 5 is most demonstrated. Add score corrections for plusses and minusses that are not covered by the behaviours in the list, e.g. for a rare talent or special industry knowledge no one else has.
  • Set annual goals to improve on some of them. Goals should be ‘smart’ (s=specific, m=measurable, a=attainable, t=timebound).
  • Sum up the scores and order them by score. You now have a handy helper to make decisions regarding: bonus payment, promotion, layoffs.
    Divide the list in 4 sections from top to bottom:

    • 10% – your excellent people.
    • 20% – exceed expectations.
    • 60% – meet expectations.
    • 10% – need to improve.

Here are the behaviours:

  • Strategic planning: Consideration of future needs, vision of the future.
  • Maintained industry awareness: Latest trends, not only technical, understands customer business, evolution and lifecycles.
  • Innovation: Brings in new ideas, continuous brainstorming, brings vitality to the organization.
  • Builds and sustains relationships: Inside the team, the department, also builds those relationships actively outside the department and organization.
  • Communicates effectively: Oral, written documentation and email, accurate to-the-point information or distraction.
  • Leads and develops a team: Gets things done and drives the team, also motivates to do unpopular tasks.
  • Enthusiasm: Does his things with high energy and enthusiasm.
  • Assertiveness: Challenges the organization and the team to get the best possible outcome, does not settle with what is already there.
  • Decisiveness: Stands by team decisions, solves conflicts quickly, does not undermine made decisions once they have been made.
  • Clear and focussed thinking: Concentrates on what is relevant to make progress working on issues, is result oriented.
  • Planning and organizing: How efective they organize their tasks and the team’s tasks.
  • Productivity: Are they always on time, do they produce work of good quality, are they busy to get things done effectively.
  • Customer focus: Mentality towards the customer.
  • Integrity: Honesty, ethical thinking, are they trying to do the right things.

Thanks James, please give us more of that!

Generalizing Specialists, Agile Heros

Inspired by the Podcast ‘Tips and Advice – Manifesto for Agile Software Development‘ in which Bob Payne and George Dinwiddie discuss the points made in the Agile Manifesto and talk about agile environments and mechanics. If you would like to discover the power of agile teams you should definitely check this one out!

They also mention the term ‘Generalizing Specialist’. Scott W. Ambler wrote about this kind of developer in his essay ‘Generalizing Specialists: Improving Your IT Career Skills‘. This is a kind of developer who is constantly learning and playing with adjacent topics and thus widens his knowledge over the years of his worklife. The effects and advantages for the team, the project owner and the developer are depicted nicely in this essay.

Planning Poker for better Estimates

There are many essays and articles on ‘Planning Poker’ out there. So I do not need to repeat the principles here. By checking out the recommended links (and folloups and others from your own research) you need to understand the following:

  • What a story point of a project looks like and how you generate those story points in advance. Remember, your estimation should include design, coding, testing and delivery. In Planning Poker it is your goal to come up with estimates to those those story points with your team.
  • The process of how one story point is estimated using the Planning Poker card deck and how to narrow down your team members’ estimates through discussion of the ‘played’ estimates.
  • The background of the card deck used and why there are such odd numers in it.
  • The effect all this will have to your project and the team.

The important thing is not the single estimate as such, but rather the open discussion among the the team members in advance, the mix of different perspectives and the collection of confidence in the team’s estimates. If the team is not able to get confident for an estimate you better recheck the user story in question and clarify it – possibly again with the customer. The more confident the team in one estimate is (=no big spread in single estimates of the team members), the less unclear ‘assumptions’ have been made in the estimate itself. This, in the end, reduces the overall risk (friction and interruptions) during the actual project and most importantly makes your customer happy.

Recommended articles and links:

Software Development Myths

There is no doubt: The environment in which software is designed, produced and maintained has fundamental impact on what comes out below the bottom line for all players playing in this game. I have learnt that there is little in software development, you can do intuitively right the first time – even if you have a background from another production discipline. Surprisingly even people working in a software development environment sometimes just don’t have the required understanding nor are they open to it.

To make these points of un-openness transparent, a great way is to talk about common myths around software development. Other people have done this before, so all I deliver here is a list of links that I can recommend for reading and discussion among your team:

Now check yourself: How much cynicism did you feel reading things like ‘More developers mean faster development’ or ‘Every design decision is documented before it is implemented’ or ‘You dont need developers when designing software’ or ‘The answer to every challenge we face in the software industry lies in doing more work in shorter times’ etc?

If you did not feel any cynicism at all or very little, well… it is time to leave the cave.

Bureaucracy is not Discipline

Sometimes you come accross something and pause thinking ‘I have experienced exactly that’. So it happend when I read Scott Ambler’s post ‘Bureaucracy Isn’t Discipline’.

Here are the main points and in my view ammunition for philosophical discussions:

  • Successful agile practices demand great discipline and require significant skill and experience to actually get stuff done.
  • Just following repeatable processes rather than focusing on repeatable results are ‘process smells’ and seen as anti-pattern.
  • Delivering repeatable results in agile environments is critical to success in IT projects.
  • Mistaking bureaucracy for discipline is a reflection of cultural damage that has occurred over the years to large organizations.
  • This bureaucracy is seen as inhibitor to software process improvement efforts and particularly to agile methodologies.
  • A cultural shift towards agile will make many ‘bureaucrats’ uncomfortable.

I think, the approach to use a defined set of formal processes (bureaucracy) comes from the management people who hope to reduce risk and thus ensure repeatable production results. On the other side there are the natural constants of the IT environment with its complexity, constant evolution on all layers, life-cycles etc.

In my opinion, a possible solution could be found between these two extreme views if…

  • hierarchies are kept flat or are at least perceived as being flat.
  • communication-paths are reduced to the least required number and everybody knows what exactly his job is and what skillset this requires.
  • an open, friendly, frictionless and goal-oriented culture gets established and maintained (preferably top-down).
  • the system allows the players to focus on and finish their tasks and have a feeling of accomplishment.

Conway’s Law

In an article from 1968 with the title “How Do Committees Invent?”, the author Melvin Conway makes the following point, which later became established as “Conway’s Law”:

“Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’s communication structure.” (Original Article) (Conway’s Law on Wikipedia)

Conway suggested an approach containing the following steps:

  1. Define your business mission.
  2. Learn the business processes from the business owners.
  3. Re-engineer these business processes to match their mission.
  4. Structure your IT to support no 3.

His concluding points:

  • Design according to the need for communication.
  • Your design will never be perfect because things change and require your processes to adapt accordingly.
  • Reward people who keep the organization lean an flexible.
  • Adding more manpower does NOT equal adding productivity into a design effort.