Archive for the ‘Visual Management’ Category

Sometimes when I say I use agile idea’s to raise my kids, people look at me like I’m totally crazy.
Although I don’t want to go into that,  I do want to explain a little more what I mean with using agile to raise my kids.

For me agile is about giving a team the tools to become self organizing and to take responsibility.
The same philosophy I used to raise my  kids.

No I’m not a person that gives his 7 year old the right to do anything he wants. Just as any parent, I have my command-and-control moments & I also have moments I gave my kids too much freedom and not enough support.

Recently we started using an actual scrum technique for helping Joppe (7 year old) with his homework. When we moved to Bordeaux, he got a large amount of books and assignments from his Belgium school. This had to keep him in sync with their work, so he can stay in his class next year.

Although it was a large amount, we never actually counted the pages that needed to be done. (As I said sometimes I don’t give enough support.)

Every Wednesday when there was no school in France) my wife helped Joppe to do more homework as on the others days. Although he liked doing the work, getting started was never easy (Not even when he asked to do some more work.)

A few weeks ago, Els told me, she was afraid he might not finish everything.
I started at the same place where I would start with a scrum team.

Facing reality!
What is the work that needs to be done? Joppe and I started counting the pages in all the books.
8 books with in total
884 pages that had to be done this year. Wow, I never realized that  7 year old kids do so much work in a year; (And that is not counting the books he finished in Belgium)

We then counted the pages he had already done (or better the pages still left to do.)
286 Ok that is a lot less.
(We have no idea how much of these 600 pages he did in Belgium and how much here in Bordeaux.)
Although the work is coming from 8 different books, we thread them all as one list. (As one product backlog.)

And yes we know that filling in a math page will take him longer as reading some dutch. We ignored that fact, and look at each page as the same. (Mainly because the effort to find this out, is too much compared to the benefits.)
(yes some scrum teams are doing the same.)
We now know the ultimate end date. 2010/08/31 (The next day joppe will go to his old class in Belgium)

That gave us 286/70 (number of days)  = 4 pages a day. That was the amount of pages, Els aimed for the Wednesday. But in this case that was for every day. I started to see why we felt he was getting behind.
Doing 4 pages a day also was a big risk. Then he would not have any slack + no holiday.
We actually wanted him to finish the 2010/07/31
That gives us 7 pages a day.
Once Joppe knew this, everything became a lot easier; No longer constant pushing and pulling from our side.

Although this was not a target set by him, he felt he could do it and he engaged in the work.
It still is hard to get him started, once he is started on his first page, he will rather go for 10 then for 4 pages.

On top of the target, I also created a burn down chart, that I update to show his progress.
Actually that is not completly true. Joppe keeps track of the pages he does every day &  calculates the total.
(More math exercise, with a real goal.)
We started on a portable whiteboard, the small amount (7 a day) makes it impossible to update.
The google doc version is actually much easier;
I also used the burndown chart to explain the complex topic of sustainable pace.

Update:Next up is start using the referee cards with my kids

Last week we did a large training (4 days, 40 people, 4 coaches) for an international company.

Although the official company  language is English, we realized that talking for 4 days in English was hard for most participants. To help our students  with this, my colleague Deborah Preuss came up with the concept of referee cards:

The concept is this:

Every one at the course got a yellow and a red card. When someone was talking too fast for you, you  show the yellow card. When the person talking used a word you do not understand, you show the red card.

I already printed out this picture and placed copies in all our meeting rooms.

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 checkin’s 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.

As a coach I invest in myself by following multiple trainings every year.

At ACCDE10, Deborah Preuss, said she that although she is a CST, she followed CSM classes with multiple people to learn about new techniques and ways of doing scrum/Training.

In the last 12 months I followed a Coaching class of David Hussman, part of an SM class of Robin Dymond, and a full PO class with Jeff Patton.

 

One of the people still on my list is Tobias.

When I saw this video earlier this week, a course with him moved higher on my courses backlog.

 

Using post it’s with the course agenda is something I learned from delivering courses with Vera Peeters.
From what I see, Tobias has more “Do as we do, not do as we say…” idea’s…

I love it.

Enjoy the short video.

 

 

On agile conferences and on agile mailing list every once in a while the same question pop’s up:

“What tool should I use to keep track of my team.” or what is the best tool…”

I answer this every time again with a question: what are you using right now.
I want to know why people want to use a tool.
I do this because the BEST tool does not exist. Now don’t get me wrong. These days there are a lot of nice tools out there that can help you. And I have friends amoung most of these tool makers. I ask the question because before you buy a tool, you should figure out why you need the tool.

If your team can’t get itself under control with a whiteboard, no tool will help you to solve that problem. And tool makers agree with me. They don’t want to be blamed them for something they do not want to solve.

Yes I know, we are in the software building industry, so we think that every problem we have, can be solved with some software. And if the software does not fix it, then we switch to another software.

I don’t believe that. I think you should first fix the problem, and then find the software that helps you best with your new process.

In my opinion “Low Tech” is a better to figure out how you want to work together with your team.

On a whiteboard the information is also much more “in your face”. If it is online in one of these fancy Agile project Management software, you have to realize that most software developers in your team will not open the software. And if they do, they will not got have a look at those fancy reports every day. They will look at the papers on their whiteboard. Especially when they are discussed during the standup.

Yes Yves you are right, but that won’t work for our distributed team…
When I started with my first distributed team (2005), I read everywhere that agile and distributed teams could not work together. I did not agree. I worked fine with our distributed team.

Today we have distributed agile experts and they claim (And I agree) that if you want/have to work distributed agile is the only/best way.
When I started with that first distributed team, I look around at some of the agile tools, I did not find any of them that really was good for what we wanted to do.
I have played around with whiteboard and different techniques on how to communicate the information with the team.

My favorite at this moment:
This works best with two subteams that are of similar size.

Have a whiteboard on either side. Hold a daily standup on both sides. Everyone states his own tasks, like he would do with a collocated team. On top of that everyone also states the work of his buddy on the other side. So everyone has a buddy in the other sub-team. Before the standup, they explain to each other what they have done.
Extra advantage: because for some people it is a kind of rehearsal of what they will say, the people in the team are much more focused while they speak during the standup.
This way you have a whiteboards that is up-to-date on both sides. And you have every member of your team that has a very close communication with one a person on the other side. Which is very good for the teamspirit. When you rotate your buddy’s every week or so, you can create a much bigger binding in your team then you usually have with a distributed team.
When you work like that you don’t need a software tool to spread that information in a distributed team. And you get a much healthier team on top of it.

Don’t get me wrong, I’m not saying that these tools don’t bring any value. I’m saying that you should not replace your whiteboard with software, only because you work distributed.

Oh and if the excuse is that these board look to unprofessional, read Xavier’s blog on Visual management to upgrade your whiteboard to look more professional. I “stole” the picture from his blog.

 

During most of my workshops I am using hourglasses.

Last Monday during another successful GTD course, I got again the question about where I bought them.

Update: These days I buy them at Team Building Shop

Tags van Technorati: