Archive for the ‘Testing’ Category

Last week we published version 43 of the book Who is agile, Volume 1 (Yes Volume 1 as we have decided to create also a volume 2)

With version 43, we added Peter Armstrong as 89 person to the book.  That is the last person we add to Volume 1.

From now on, we have a quality control phase. (Wow, how un-agile of us…) What would Lisa  or Elisabeth say of this? 😉 )

these are the different steps we have to do for each person in the book:

  1. Spelling and grammar
  2. Are the  links to person you mention that are  in the book, are these internal book links working?
  3. Are the books you mention in the book list?
  4. Are your links you provided in the contact list?
  5. Is your question in the question list?
  6. is there anything you are missing in the book?
  7. is your location on the map correct?
  8. Update: is your location mentioned at the bottom of your answers?
  9. Update: Does  your location (mentioned at the bottom of your answers) have a correct wikipedia links?
    (You might want to download the latest version of the book for 9 as we only added the links on 2012/10/30)
    As you can see, doing this for 89 people and +20 community events is a lot of work. That is why we are sending out mails to everyone in the book to help us.

    Will you help us too?
    If you send us info, please add the version of the book you  have been reviewing.

 

 

 

 

Do you remember the first time you drove a car?
I still remember my first time.
I was very intensely holding the steering wheel. I was only looking through the front windshield.
I was sure I did not move the steering wheel and yet the car moved from left to right.
When I made a correction move, I overshot and moved to the other side.
Last year I drove from Belgium to Bordeaux. I think that at some places I drove 100 kilometers without making correcting moves. At least that is what it felt like. In reality I think I made an incredible amount of micro changes. What has happened in the 20 years between my first ride and my ride to Bordeaux is that I enhanced my system of receiving  feedback and responding to it. Yes, baby steps again.
And every time I ride an unknown car, I have to adapt my system, actually sometimes when my car comes back from a service, it behaves different. Not much, but I feel it has changed and I adjust my driving style.

Now imagine that your front windshield is closed. And the only feedback to drive is your rearview mirror.
That means that the only thing you can see is behind you. Did I hit something along the way?
That is like only doing retrospectives (lessons-learned) as a post-mortem. The patient has died. They do a it to find who did it and to prevent future dead’s. I don’t like that kind of feedback. CSI might look nice on television, in real live I prefer check-ups to keep the patient alive.
Please take a pencil, a baseball bat or anything with that shape. In a moment I want you to:

  • put this post aside
  • put the pencil with its smallest part on the index finger of your main hand.
  • try to keep the pencil (or whatever object you have chosen) in balance.
  • while you do this, you keep track of the time.
  • come back to this post 🙂
  • write your time in the comments and continue reading.

Ok, now it’s time to do it.
How did this go? Was it easy?
Now I want you to do the same with your eyes closed.
How did this go? Did you achieve the same time?
I don’t think so. (if you do please tell me in the comments)

Feedback makes a difference even for such a small task.
Now what if someone else would be your eyes? By now you might be tired of these exercises, if you aren’t, please try the following;
you close your eyes and while someone else gives you feedback, you do the balancing act.

Does it work better? If it doesn’t, maybe change PM euh feedback person.
Does this new person allow you to be back at your original level?

If you are like most people, you aren’t. Looks like your feedback is better than the delayed feedback from other people.
What if you are allowed to open your eyes for one second every 10 seconds?
What if you would do it every 5 seconds?
I don’t think you need to try this, to know that the shorter the feedback cycle, the better the result.
The agile mindset is about shortening the feedback cycle.

If you need another story, check out Lisa Crispin’s nice posts  about how shorter feedback helped her with donkey driving.

Short interview with Gojko Adzic

Quote: “My background is in delivering software not in developing software.” This says it all. It’s not testers vs developers. 

Gojko & Lisa Crispin are talking tomorrow (2011/02/16) about “Long Term value of Acceptence tests“, it’s a free event from Agile Consortium Belgium.

A few projects back, I was working with a team, that had a build server, they had automated tests, but they did not seem to care about them. At least not as much as I wanted them to care about them.

Mm, how do I motivate teams to care about their builds?

 

One of the things I came up with, was a Croissant build.

A croissant build is when we had enough checkins during the day (that was the teams size + 1) (yes I know that is not much, but I have to start somewhere)

 

And the build was never red (broken build) for more then 30 minutes

or yellow (failed tests)  for more then 1 hour.

I as a scrum master brought croissants the next day.

It helped to show people how I important I found the build (I paid the croissants out of my personal money)

 

What I don’t like about it, is that it thinks that motivation is extrensic, where I know it is intrinsic. To have less of this problem, next time I use this, I will ask the team what they define as a croissant build.

 

Question I received after explaining this to other people:

1) Shouldn’t a build be green/blue all the time?

Not in my opinion, if a builds stays green all the time people have been too carefull.

(hence are not innovative enough)

 

2) They run all tests on their machine and see if it is broken there.

True I want people to run test locally. But I prefer them to run the test of the modules that the are working on. Not all tests, all the time.

 

3) Should they not run all test before checking in?

Well I want people to check in as fast as possible:

    • Write a test
    • Make it green
    • Refactor.
    • Run the related tests
    • Do a get
    • Run the related tests
    • Checkin

 

4) My team has to much trouble syncing, when we checkin more often, won’t be have more problems?

Yes and no. You might have more often a problem, but the problems will be smaller and easier to solve. So the time you loose will be less. (On team level) On a personal level, the faster you check in, the bigger the chance is that you won’t have the problem but somebody else (who is waiting too long to check in.)

So no reason not to check in early.

 

5) What if after a while my teams get’s croissants every day, that is expensive.

You make the rules stricter.

Now it is

-more checkin’s every day

-less time to fix (this depends on the time the builds run)

-same rules but now for a week, instead of a day

-let them come up with some rules.