Na na na na na na na na Bug Slot!

<Sing title to the melody of the batman theme song>

In the company I just left we had a weekly bugslot to stay on top of defects: 2 hours every week during which all developers fixed bugs at the same time. It’s not a perfect solution but solved a number of pressing problems:

  • Discouragingly high number of bugs – accumulated over a long time
  • No overview / documentation / communication of what was fixed, what deployed, and what left to fester
    • We had no bugtracker. (The developers never reached agreement, which one to use.)
    • The same bugs appeared again and again, their symptoms often fixed by different people, so that no one recognized patterns
  • No order given in which to fix
    • Decision if and what to fix fell back on each individual dev. And as bugfixing took time away from the sprint and the team commitment…
  • About 30% of all developers were new hires, yet unfamiliar with the systems
    • The systems weren’t documented, so the new devs had no chance to fix bugs on their own. It was left to the “old” ones, who groaned under the additional workload

The situation in my new workplace is similar enough that I suggested a bugslot as well. It  has a good chance of doing the trick again.

How exactly does a bugslot work?

  • 2 hours each week for fixing (non-urgent) bugs
    • At the same time every week
    • All developers at the same time
    • Pick a week day and time that most developers will be there. Lunch time’s holy, though ;)
  • Before: Order the bugs. What needs fixing first is first in line
    • Can be done by product owner, stakeholder such as costumer support, …
    • Publish the list highly visible
      Continue reading
Posted in Agile / Lean, Fairly Good Practice, Self-Organization | Leave a comment

My Favourite Usability Books

People sometimes ask me what book to read to get started with usability. My recommendation depends on your background and focus:

IF (you like your knowledge applied and theory light) ->

  1. IF (mostly for web, interested in guerilla usability tests) ->
    Don’t make me think
    by Steve Krug
  2. IF (you’re a developer and want people to be happy with the solution you’re coding) ->
    User interface design for programmers by Joel Spolsky
  3. IF (love lots of examples, mostly from non-web GUIs) ->
    GUI Bloopers
    – Jeff Johnson

IF (you like theory and psychology) ->

The 1st and last ones are also great, if you’re not yet convinced that usability is a good thing and usually suspect that your system’s fine and your users are just too stupid to operate it.

While I’m at it: One thing that will improve the usability of everything you “produce” – software, emails, whatever – is good writing. The 2nd book has a great chapter on this. Alternatively, if you’re German you can read this article on writing well by Sushee. It’s the best I’ve ever read on writing, ever. Everything you really need to know on just 3 pages.

Posted in Resource, UX | 10 Comments

Düsseldorfer Softwerkskammer Konferenz am 23.6.

Sorry, non-German-speaking readers, this will be my first post in German (about a local conference on Software Craftsmanship):

Du hast einen hohen Anspruch an die Software, die Du entwickelst? Sie soll gut vertestet und leicht änderbar sein? Dann komm vorbei! Wir möchten voneinander lernen und uns zu Software Craftsmanship sowie verwandten Themen (Clean Code, TDD, etc.) austauschen:

Anfahrt mit ÖPNV: Mit der Straßenbahn 708 bis “Wupperstr.” oder mit der S8 / S11 / S28 bis “Völklinger Str.”.

PS: Wenn Du am 23. 6. nicht kannst, aber Dich generell für die Themen interessierst, dann werde Mitglied der Softwerkskammer Düsseldorf.

Posted in Meta | Leave a comment

Introducing Retr-O-Mat

I did it! I finally launched my current project: Retr-O-Mat. I’m thrilled! And exhausted. I think, I’m catching a cold…

Anyway, I’d be happy to know how you like the Retr-O-Mat. Tell me in the comments or write to corinna@finding-marbles.com. Thanks in advance :)

Posted in Meta, Resource, Scrum Master | 4 Comments

Retrospective fatigue? How to increase follow-through on action items

The retrospective is my personal favorite among the Scrum meetings. Why? Even if there were no other meeting, role, or artefact, retrospectives enable you to invent everything else you need to improve. In theory at least.

When I was just learning how to facilitate retrospectives, I was mainly concerned about the flow of the actual meetings. I needed to gain some routine before I had freed up enough brain cycles to realize that what happens after the retro is at least as important: The whole point is to inspect and adapt, i.e. to change something. If few of the retrospectives’ action items ever get implemented and bear fruit it’s frustrating. Ultimately it leads to retrospective fatigue where teams are unwilling to participate in the retro anymore, because “What’s the point anyway? Nothing ever changes!”

So, how can you increase follow-through and make sure that more action items are carried out? As always it depends on the situation:

A – Team can’t agree on action items

If you don’t have a facilitator, get one or nurture one. If you do have a facilitator, the “Facilitator’s Guide to Participatory Decision Making” or a training about retrospectives (or moderation techniques) will be beneficial.

B – No one feels responsible for action items

Ass kick fairyEach action item does have a name on it, doesn’t it? In the end of each retro check all action items and ask for each unassigned one who is going to take care of it. A single task such as “Write mail to admins about monitors” also needs a deadline. Recurring tasks such as “Pair program 2 hours per day” are assigned for the whole sprint (or indefinitely until the one resonsible transfers responsibility). The duty here is to remind everyone to comply. One of my fellow scrum masters lovingly dubbed this role “Arschtrittfee” = “ass kick fairy”.

Continue reading

Posted in Agile / Lean, Change, Fairly Good Practice, Food for Thought, Scrum Master | 2 Comments

A Brief History of Agile and Lean Events

Timeline of Agile, Lean & Engineering PracticesWhenever I explore a new field I like to get an overview of how things got to be the way they are – A short timeline of how we’ve arrived at the “state of the art”. What happened when, so that everything is what it is today?

The following is my current state of knowledge (April 18th, 2012 – v2). For the visually inclined I turned this into the infographic at the left hand side. Please note that for various reasons, not all events are in the infographic – only those set in bold.

Disclaimer: This list is very subjective and not comprehensive. Loads of cool people are missing. I wanted to concentrate on the turning points. Continue reading

Posted in Agile / Lean, Resource | Leave a comment

“It can’t be done!” O RLY?

It makes me sad when a PO presents a new story and the first thing out of a developer’s mouth is “It can’t be done!”*. A story is meant to be the basis of a discussion – “It can’t be done!” is harmful to this discussion.

As long as there is no timeframe attached to the story, “It can’t be done!” is rarely true.

Just like “I don’t have time for that!” is code for “It’s not a priority”, “It can’t be done!” is usually code for something along the lines of:

  • We’d have to do a major rewrite. It would take months!
  • That code is chaos. No one knows how it works. I don’t want to touch it. I’m afraid to break something.
  • I can’t think of a way to achieve it. (In this very moment.)
  • I don’t want to do it.
  • I think that feature’s stupid but you won’t listen to me, so it’s easier if I declare it impossible.
  • I could do it, but you’ll just change your mind in a week’s time and I’ll have to throw that code away.
  • We can’t afford the expensive thingamabob, we’d need to achieve that.

Continue reading

Posted in Agile / Lean, Communication, Decision Making, Fairly Good Practice, Food for Thought | 6 Comments