RSS Feed

Latest Entries

First time here?


My team keeps breaking their promises. What can I do?

Execution – actually having the team get things done– requires people to :

  1. Say what they will do 
  2. Mean it (be committed)
  3. Do it

Everyone likes to do #1. Only some do #2. Great teams also do #3.

This post is about #2.

There is a vast difference between people being committed to something, and people saying something.

For example, you can start looking for words that are not committing to execution:

  • I’ll try to get that to you by Monday”
  • “Someone should get that thing fixed”
  • “I hope to get to that later”
  • “I think I can make it”

spot these things and see if you can ask people to actually commit to the thing they need to do:

  • “I will do this by Monday”
  • “I commit to getting this done by Monday”
  • “It will be done by Monday”

If someone can’t commit to that – that’s good. Maybe they are not sure they can – maybe there is something stopping them. But you won’t know until you can either get them to commit, or get them to say why they cannot commit to it.

Also notice how there is a specific end date. Committing to something with an end date make things more real, and also prevents whoever is depending on that thing from bothering the doer. “Is it done yet?” “How about now?” .

No need to ask. They committed to do this by Monday.

Don’t under estimate peer pressure.

Doing all this talking in an open daily standup makes the commitment more important. it’s not just you and someone else. now it’s you telling the whole team you will get something.

If your team members don’t know how to verbally commit to something, you can teach them. You can actually ask them to say things differently:

“Can you say you will do it by date so and so? Is that something you can commit to? Why not? “

I can’t commit to something I don’t have control over

Of course, the biggest hurdle is that sometimes people really can’t commit to something if they don’t have full control of it. Expecting people to commit to something that depends on other people is less realistic.

If that happens, see what things that person can have control over. For example, if the task is about getting a bug fix to a client and making sure it’s closed by Monday – the dev might have control over actually sending the email to the client, but they have little control over when the client responds back. In such a case they can commit to sending the fix to the client .

Failing commitments

There should be no such thing is a failed commitments. the moment one sees that they will not make the deadline, they should notify whoever they committed to, that they will no make it in time – this allows the team to see if something can be done to maybe still get that thing in time by reorganizing or changing priorities.

A failed commitment means you won’t live up to what you promised and you didn’t notify anyone beforehand that you will not make it in time. that is something that is fully under your control and should not happen.


Kevlin Henney – 3 things every programmer should know

During the ACCU 2010 conference in London, I got to get on audio, several of the interesting people who attended and spoke at the conference.

One of them was Kevlin Henney. I first got to see him speaking during NDC 2009 in Norway. He was fascinating in the way he approached sophisticated architecture topics, and his lively and funny way of making everything more understandable.

Kevlin is also the main character behind the book 97 things every developer should know and several other books.

In this 20 minute audio mp3, we start off with a simple question: what are the three things every programmer should know? (you can watch Kevlin on this years NDC in Norway as well. I highly recommend it! (he’s also on twitter)

Download the mp3 – 20 min.


Interview: Patrick Kua : Agile Coach

This time, I talk with Patrick Kua, an Agile Coach living in the UK, about various subjects. Among them – the various types of tests, what is “Done”?, The difference between Team Leader and Team Manager and more.

Download mp3 – 29 minutes.



Interview: James Bach – The role of the tester

During the ACCU conference in London (at which I am still stuck due to the ash cloud while writing this), I got to speak with many interesting people, and even recorded some of those conversations.

One of the talks I enjoyed the most was with Tester James Bach, who gave a thrilling keynote about the role of the tester in the organization, and the idea of exploratory testing.

In this recording I talk to James about what real testers need to be, how to interview a tester for a job, the idea of exploratory testing, automated checks vs. manual, sapient  tests and many other things.

James has taken a clear leadership role in changing the perceptions many of us have about what testers are and should be, and what testing should be like.

Download mp3 - full time is 75 minutes.



James really made me change some of my points of view about what and where we might need testers, and how unit testing and “sapient" testing” go together, and don’t cancel each other out.


Move-Around kata for team leaders

Here’s an experiment for software team leaders: a set of katas (things you repeat exactly the same way many times).

Let’s try to do the following kata once a day:


  1. Get out of your chair and lock your computer
  2. For each team mate that sits in your floor:
    1. Ask “can you show me what you are you working on?”
    2. See at least one technical document they wrote (source code, documentation, build script..)
    3. If you think they could have done a better job, challenge them to find a better way to do the job without giving them the whole answer
    4. This should take no more than 5-10 minutes per team mate but you can take longer if you like.

What other katas do you recommend?