November 19, 2010
September 22, 2010
If you want your team to improve, you need to give it the means to innovate. Since innovation needs ideas, the problem is how to stimulate the creation of new thoughts. A daily stand-up can be a step in the right direction.
Some science seems to suggest that a lot of good ideas, maybe even most of them, come from collaboration and is a network of thoughts rather than a single person unexpectedly getting an idea while taking a bath. In a tightly knit group, your teammates are the extension of your mind, imagination and memory. Or as Steven Johnson said, “chance favors the connected mind”.
If this is true, let’s think about it in the context of software development. What’s the most important thing to get good ideas about in our profession?
Here are a few suggestions:
- Reducing bugs
- Writing better code
- Increase collaboration
- Improve communications
- Increase usability
If you’re like me, you believe that all of the above are results of the way the team works, i.e. the process. It would then seem like a team that is capable of spawning really good ideas about the process and ways to improve it is very valuable.
If you somehow stimulate the intellectual and free discussions of progress in your team, then you’re practically bound to get many improvement suggestions that any one individual couldn’t have figured out on their own. If the teams learns how to, in a safe environment, discuss, argue, challenge and intellectually defend ideas, beautiful things happen.
To me, a well run daily stand-up seems like a good option to achieve this.
May 11, 2010
Stoppa pressarna! Stockholm Lean Coffee har sitt första möte i morgon bitti (onsdag 12/5 2010), kl 8:30 på Café Caldo i Sundbyberg. Det ligger nära pendeln/t-banan, på Landsvägen. Vet inte exakt gatunummer, eftersom caféet är nyöppnat, men det är mellan Systembolaget och ICA Supermarket.
– vi träffas och köper kaffe + frukostmacka
– vi skriver ner tänkbara samtalsämnen för morgonen
– vi röstar på vilka ämnen som är intressantast och betar av dem i turordning utifrån popularitet. Under tiden finns möjlighet att fylla i den mindmap som ligger framme och som sedan kommer att fotas och läggas upp på våran blogg för att vi ska kunna gå tillbaka senare och se vad som diskuterades
– det hela avslutas när folk tycker att det är dags att gå till jobbet
Alla är välkomna, det här är ett generellt lean-forum. Har du bakgrund inom akademiska världen, bilbranschen, vården eller mjukvaruindustrin spelar ingen roll, det är bara att dyka upp.
Om det finns nog med intresse för det här flyttar vi gärna in till ett mer centralt beläget café i Stockholm, men som det är nu så jobbar vi tre som drar i det hela i Sundbybergsområdet, därför var det smidigast så. Klaga gärna, vi är flexibla med både tid och plats!
Om ni vill läsa mer om Lean Coffee-konceptet kan ni kolla upp ursprunget: Seattle Lean Coffee.
April 8, 2010
I’m currently experimenting with checklists in order to make sure I don’t forget or look over important actions when programming. This is my current list.
I’m done when the code is:
- covered by automatic tests that express domain logic to as large an extent as possible
- tested in the following browsers: IE6, IE7, IE8, Firefox, Chrome, Safari
- following the project standards
- peer reviewed
April 7, 2010
I’ve never read the Hippocratic Oath before. It’s fascinating. Read through it a few times for yourself and think about it. What does it mean? Why is it used? Does any of it apply to your profession?
This is a modern version of it, written in 1964.
I swear to fulfill, to the best of my ability and judgment, this covenant:
I will respect the hard-won scientific gains of those physicians in whose steps I walk, and gladly share such knowledge as is mine with those who are to follow.
I will apply, for the benefit of the sick, all measures [that] are required, avoiding those twin traps of overtreatment and therapeutic nihilism.
I will remember that there is art to medicine as well as science, and that warmth, sympathy, and understanding may outweigh the surgeon’s knife or the chemist’s drug.
I will not be ashamed to say "I know not," nor will I fail to call in my colleagues when the skills of another are needed for a patient’s recovery.
I will respect the privacy of my patients, for their problems are not disclosed to me that the world may know. Most especially must I tread with care in matters of life and death. If it is given me to save a life, all thanks. But it may also be within my power to take a life; this awesome responsibility must be faced with great humbleness and awareness of my own frailty. Above all, I must not play at God.
I will remember that I do not treat a fever chart, a cancerous growth, but a sick human being, whose illness may affect the person’s family and economic stability. My responsibility includes these related problems, if I am to care adequately for the sick.
I will prevent disease whenever I can, for prevention is preferable to cure.
I will remember that I remain a member of society, with special obligations to all my fellow human beings, those sound of mind and body as well as the infirm.
If I do not violate this oath, may I enjoy life and art, respected while I live and remembered with affection thereafter. May I always act so as to preserve the finest traditions of my calling and may I long experience the joy of healing those who seek my help.
December 14, 2009
Last week, the Swedish ALT.NET group hosted an experimental Code Sparring night at the RemoteX offices. The idea came from the experiences we’ve had with coding dojos and the problems we recognized with that particular way of evolving as a coder. Mainly we felt that there was too much idle time for the people not sitting at the computer, and things quickly became messy with complex communication behaviors disturbing the overall experience. So I suggested that we should work on programming challenges in pairs instead.
Sparring in martial arts
There are many metaphors for software development taken from the world of hurting other people, and this is no different. I have some limited martial arts experience, mainly MMA, and I’ve always found that the most rewarding part of practice was the sparring.
A sparring session usually consists of people pairing up to try out their skills in a slightly more realistic environment that is still safe. The sparring may be very broad, i.e. everything is allowed, or sometimes only a subset of techniques can be utilized or you have to accomplish a specific goal (such as a rear naked choke).
A boxing class, for example, might start off with warm-ups and then move on to technical drills, such as a improving hand-eye coordination, like the guy to the left, or specific striking combination for 30 minutes. After that, you could finish with 30 minutes of sparring. The sparring is usually done in pairs, and you go at it for a round and then change your sparring partner. The goal is of course to improve and during the rounds you learn from each other, help each other and get to apply fine-grained knowledge in a complex and fluid situation.
How well does it translate to our profession?
Very well if you ask me. We can say that learning the programming basics through reading books, attending courses, practicing katas etc. is like drilling, and our day jobs are like a real fight in front of an audience. So code sparring should be something in between that is safe (e.g. you wont harm any important production code) and less competitive/dangerous.
I know that Micah Martin has a different definition of what code sparring is, but that was a sort of competition instead of what I feel sparring really is. I’m not saying that it’s a bad thing, but I’d call his version “light contact coding” or something.
Anyway, to emulate real programming work more than a dojo did for us, roughly 10 people gathered at a big table and paired up. In order to keep things fluent, fun and to learn to know each other better, we rotated every 20 minutes. Due to the fact that people might feel uneasy about the prospect of handing over their sacred computer to others, the ones who brought laptops stayed put, and the others switched seats by moving one step to the left. The assignment we chose to work on was the KataYahtzee, driving the implementation out using test-driven development.
The people who rotated always had fresh and clever ideas from the other pairing stations they had been at (just like consultants, eh?) which merged together with the existing code to evolve into something new. And constantly being part of a pair meant that everybody seemed to be focused and utilizing the time efficiently from start to finish. Also, unlike a dojo, any group size should work for this kind of exercise.
The constant change of pairs also meant you had to be able to quickly communicate the whats and the hows of the code to your new partner, which sharpens your verbal skills as well.
The biggest problem that I could see was the strict division between the laptop owners and the more consultant-like people who changed code base every 20 minutes. Some people were not content with sitting in the same seat all night, so there’s room for improvement. Make sure to read Morten Nielsens summary of the sparring as well.
Why don’t you try a code sparring night in your office or with your local user group? If you do, tell me how it went and any suggestions you have for making this better.
EDIT: I am in no way claiming that I invented this kind of practice. I know that CodeRetreats are very similar and other kinds of pairing roulettes existed before I suggested Code Sparring.
October 30, 2009
For a few months I’ve been using a personal kanban board as a way to becoming more effective, efficient and knowledgeable about the process that goes into my work. It’s only been used for hobby and home projects, because that’s where I felt had lost control and stuff just kept piling up.
I’ve always known that my main problem was initializing too many projects only to become stressed out by everything, unmotivated and abandoning most of them halfway through, which in turn led to a sense of failure and broken promises, either to myself or to others. Therefore the Work In Process (WIP) limitations of a kanban board seemed like a very good idea, and I quickly set one up for free at Zen. After adding some WIP limitations to the Working column, I got started and the results came instantly: I’ve been finishing up some old projects that I’ve had in the back of my mind for years. All of a sudden I know that when I start a project, I will finish it. Even if it becomes stale or boring, I have to push through before I can move on to something that seems like more fun. Just knowing that is a great motivator for actually finishing stuff, thereby delivering some kind of value.
My kanban board is very simple: I have a backlog, a Working column, a Complete column and an archive (where items I’ve finished long ago go). It seems almost too simple compared to what large teams use, but hey – there’s no team in I (and vice versa). The Working column has a WIP limit of 2 items, of which one can be computer related (e.g. reading the RSpec Book) and one can be related to something else (e.g. painting the walls). I noticed that if I allow myself to do two or more computer related tasks at once, I jump back and forth depending on the mood. That in turn leads to the pace feeling a bit slow, which lowers the motivation to work on stuff even more, which makes the pace even slower and so on…
I’ve actually completed many more items than are in the Complete column above. I’ve just moved them into the “Archive” column. Just so you know.
Since I only have three columns, the visualization part of the kanban isn’t as prominent as when you’re working on a bigger team. Neither the backlog nor the Complete column can be bottlenecks, all I have to analyze from this perspective is the Working column, and it’s always full. I tried having more columns in the beginning, just to be able to identify bottlenecks, but it always felt contrived.
So the steps for you to get started with a personal kanban are very few:
- Create a board with columns and determine the initial Work In Process limits (you can change them later, it’s an open process).
- Create tasks/stories and put them in the backlog.
- Start pulling from the backlog.
- Analyze what goes well and what doesn’t, and start reaping the benefits of actually getting things done. It sure feels good pulling items into that column.
Once those darn walls are painted, my fiancee and I will put up a common kanban board for both of us in that room (the guest room/office). I’ll report on that in a future blog post.