Martin Fowler has a nice piece on what a good team room should look like.
Here is what ours looks like:
Many times when we have visitors I get asked if sitting together so closely is not problematic. Especially if the person asking comes from a background of two people private offices.
My answer is always the same. I used to have a nice Jugendstil turn of the century private office with wooden floor and plastered ceiling – I don’t want to trade back: >> more…
Last week I not only finally managed to get my beloved reading lamp repaired, of course an Artemide Tolomeo 
, but also to utilize the newly provided cozily, brightly, and energy-savingly lit space to finish the book I had started the week before. And because I am excited about it, let me share my excitement with you:
The book title “Scrumban” is the combination of Scrum and Kanban, two management methods. Scrum is one of the predominant inhabitants of the Agile management method zoo, while Kanban originates from the lean management revolution attributed to the car manufacturer Toyota. >> more…
Like probably everybody else in our industry I have a lot of tasks I should be working on at any given point in time. The question always is, how do I best get a handle on all the things I should/want to be doing?
For a long time I tried to use the system Steven Covey suggested in “The Seven Habits of Highly Successful People“. The book is great and everything Covey says is very true. But as a time management system it fails. It reminds me a lot of the old waterfall.
Before each release the support guys click through the whole application (following a smoke test script) to prevent that new bugs sneak in. However, sometimes they don’t manage to find all of them. No wonder since humans just tend to make mistakes when doing such stupefying, reoccuring work. Apart from that, the procedure is awfully time consuming – eight days of development require two days of testing.
That’s why we decided to enhance our suite of acceptance tests. Now we use exactly those two days support needs for testing to write new Fitnesse tests. We first created a list of all parts of the smoke test which were not already covered by automated tests. Each pair of developers picks one of the tests, implements it and then the interaction design girls look over it to ensure its quality. That way we already implemented 2/3 of the missing tests. As a side effect we improve old Fitnesse tests we find while searching for “inspiration” for the new ones.
Because Fitnesse tests are run on our continuous build server after each commit, new bugs are found before the smoke test even starts.
And that pays off: In the last three iterations only one small mistake made it into the release! Customers and support love our improved Fitnesse.
Three years ago we closed our old Jira database because it was overflowing with over 1600 bugs and issues and improvements. We had nobody who treated this database as his baby and consequently everybody just dumped stuff into it. Development was regularly critized for not acting on all those requests. For some reason the expectation had been created that this was some sort of queue and eventually everything droped into it would be worked on.
Timo then stepped up, started fresh and has been owning our bug count ever since. He constantly kept an eye on the list and made sure we never were over two to three hundred. Also he regularly interfaced with everybody else in the company to get their priorities as to which issues should be worked on first. But overall the count kept increasing slowly. >> more…
The internet has a profound impact on software. Even on software that is locally installed on a device (in this case the iPhone)
Here are the guidelines that Apple gives to their ISVs how often to update their applications.
(c) Apple Inc.
