Archive for October, 2009

This are the slides from my presentation at AgileTourToronto.

My intention with this talk was to remember my fellow agilists about a lot of the different ways todo retrospectives. Most of the examples come from one of the books on retrospectives. My slides are done presentation zen style, which means they don’t contain a lot of text. When people asked me about hand-outs, I pointed them to the Agile Retrospective book from Esther and Diana. That is a way better hand-out then I could ever make.

I struggled a bit with finding a nice team charter to show. That a feedback I got. So I struggled some more when waiting for my plane home. And then I reviewed some slides about leadership from Deborah Hartman Preuss. I was reading a piece of text I new for a few years. And then lightning struck. That text was one of the best Team Charters I knew.
See slide 14 for the text.

Update: Some people seem to have trouble seeing the presentation in their RSS Reader. Here is the link to the slides on slideshare

Have you ever been in a meeting that seems to go on for hours?
Where some people talk like this:

BlahBlahBlah, BlahBlahBlah, I don’t have anything to add to this conversation, but I want to make sure that everyone hears my voice, BlahBlahBlah, so that I’m sure that they value me, BlahBlahBlah, and so that everyone thinks I’m a smart person, BlahBlahBlah, that has something to say, BlahBlahBlah.

Actually I think that the idea that we are discussion here, blahBlahBlahBlahBlahBlah is a great idea, BlahBlahBlahBlahBLahBLahBlahBlahBlah I’m adding a few idea’ on top of it so I look smarter BlahBlahBlahBlahBlah, I support this idea the way it was proposed.

If you have 6 people around the table and we all take 10 minutes talking like that (and yes we all do it), that is 1 hour of lost productivity for 6 people.

That is 6 hours. mmm, maybe we need to have smarter meetings.

Comes along Decider, one of the Core Protocols.

Here are the basic rules: (See page 6 of the Core for all the details )

1. Proposer says “I propose [concise, actionable behavior].”
2. Proposer says “1-2-3.”
3. Voters, using either Yes (thumbs up), No (thumbs down), or Support-it (flat hand), vote
simultaneously with other voters.

Let’s use an example:
Situation: I’m hungry, my kids are noisy and my wife is having a bad day.

Yves: I’m proposing that we go out now and eat some French fries. 1-2-3
Yves: Thumbs up (it would be very stupid to vote thumbs down to my own proposal)
Joppe (7 y) : thumbs up
Bent (4 y): thumbs up
Geike (2 y): thumbs up (she doe snot understand it, but she loves to vote yes)
Els: thumbs down

I’m turning to her and ask her: what would it take to get you in?
Els says, I would accept it if we would leave in 15 minutes, so that I have the time to do X
As it is a small change I do a quick eye check with my kids to see if that is OK.
==> Decision taken.

Update:

This technique also works well with a distributed team over chat or E-mail. As I described in a previous post: taking group decisions by e-mail.

I noticed something strange the last months (year?).

Last year there were lot’s of discussions on agile mailing list about agile vs Agile.
We also had discussion about the advantages and disadvantages of certifications.

David wanted to write a new manifesto.

We had discussion if Lean was agile.
At Agile 2009 there was a Open Space session is Scrum evil?

Ken resigned of the Scrum Alliance he founded (the foundation to support “his” scrum)

Joel writing a post against TDD vs Uncle Bob’s response 
Tobias writing a blog post to stop doing XP.  vs Steve reaction’s to keep doing XP 
(Read Tobias answer in the comments to understand the whole discussion) 
I could add a lot more if I wanted, and so could you.

It looks like we have a lot of discussions where we question ourselves as an industry.

I have the feeling it is the first time this happens at this scale.
Maybe I’m too young. Maybe I ‘m more in the middle now or have more idea’s myself on who’s right or wrong.
Maybe it’s the always connect, twitterly, blogging world that makes these discussions so more public.

This reminds me a lot of the storming phase that exists in a team live cycle,or the chaos phase in Satirs model.
So from a point of view of a coach these discussions and where this goes is interesting.

In these discussions, there is clearly no leader. Or let me put it in another way, no leader that everyone would accept.
So this is a self-organizing team.

Who’s is part of this team?
I guess everyone involved in creating software.
Some are seniors, some are juniors. Some are good in communication others are bad at expressing what they think/feel, but have good idea’s. Some have great idea’s and don’t say/write anything. Some turn of heir browsers and start writing code.

What is the goal of this team?
mmm? That is a hard one, and as long was we don’t have a shared vision, I doubt we will agree on a lot of stuff. Anyway agreeing should never be a goal.
The creation of the agile manifesto was also not done without discussions.

My personal goal would be that we as an industry end up get better at writing great software.

As a coach I’m interested to look at META position and see how we behave as a community. And how the outside world looks at us during these discussions.

Do we scare people away because we argue?
Do we attract people because we listen to each other and argue politely?
Maybe it is too early to ask these questions, and I know that switching to and from meta position can influence the discussions. 

So lot’s of questions. And too much happening that I can take a look at on my own.

So I wonder, what is your idea? How do you feel about this?

I have been talking about real life deployment at Flickr for a few years. People have been asking me numbers or places where they could verify what I said. Problem was I did not remember where I read that Flickr deployed every 3 hours. Here are the slides.

This video talks about how Developers and Operation work together at Flickr. I know that Patrick Debois of DevOpsDay will love the one step build, the one step deploy, and one source codebase. (Just like I do) I know some people of my previous teams would love to hear about this.

I know some senior developers that don’t like PairProgram with juniors as they slow them down. First of all, the speed of the team (and thus the velocity of the team) is determent by the slowest on the team, not by the fastest.
First reaction could be: let’s throw out these juniors.
At first sight it might be good to only hire smart, seniors developers. We can advance much quicker. Well not exactly true. A lot of senior people have a hard time asking for help. I prefer to bring the juniors up to speed.

A lot of juniors feel overwhelmed by their senior colleagues. I think a junior has an incredible advantage over most seniors people. They have the advantage of being excused not to know. I blogged before about the TMN acronym.  The questions a junior asks go way beyond this.

And a lot of times some senior’s are happy that someone dares to ask that question.

Unfortunately by the time a junior does not feel overwhelmed anymore,  they might have lost that advantage, and now they might feel that they can no longer ask that question. When I have a junior joining a team I’m coaching, I make sure I explain them that it is OK to ask questions even (or should I say especially) stupid ones. I ‘m saying that I expect it, and that it is part of their job as a junior to ask questions.

I love diversity in my teams. Having a junior that dares to ask stupid questions brings the whole team to a higher level.

The better the juniors on my team do this, the more the seniors start doing this as well and the easier my job as a coach gets. And the faster I can leave this team.

As an agile coach I do quite some retrospectives. My partner asked me a few days ago how it was possible that a team that did not know me, trusted me to do their retrospective.

What I told her was that it goes much better then when I do a retrospective for a team I’m coaching.  When I am coaching a team, I try to avoid to facilitate the retrospectives of that team. I do this, because I am involved with the team. And when I am involved I want to bring my own opinion.
I consider bringing my own opinion when I facilitate a retrospective, a bad practice.

When I facilitate a  team I don’t coach, (or no longer coach) the team members see me as objective. I don’t let the CEO talk more. I don’t know the history of the team. I can only react to what I see happening. That makes it much easier for me to do a retrospective.

Of course the first retrospective I do with a team, they will test this if I’m neutral.

It’s common sense to be neutral when you facilitate. Another example where common sense is WRONG.
I can’t be neutral. When someone says something, I immediately have feelings.
-Ah that is smart
-Nah that won’t work
-You make me think of an old boss I did not like
-…
==> all these thoughts make me have sympathy or antipathy for the speaker.

For years I wanted to be neutral. Now I came to realize it is not possible. It is politic correct to be neutral. But it is not possible.

When I facilitate I want to have multiple partiality. Being aware what these feelings are, gives me the possibility to have multiple partiality.
And that is something I can.

I’m not sure I have to explain multiple partiality. I’m not sure I can.
It’s all related to the political correct TRUTH. I don’t believe their is one truth.
I believe we all have are truths.
I can believe that your truth is this and that her truth is that. I might have a total different idea of the world. I still respect both truths as a given.

For me multiple partiality is about respecting all parties the way they are. I can only do this when I understand my sympathies and antipathies.
It’s also one of the reason’s that I think agile coaches should have their own coach. It’s important to have a place where you as a coach can safely talk about your sympathies and antipathies, and to have a person with who you can explore these. At least I need that, because that way I can better understand them. When I better understand my sympathies and antipathies, they won’t drive me.

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: TeamBuddies
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.
Yep, 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.

Extra advantage that I never saw comming:

Every member of your team that has a very close communication with one a person on the other side. That 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.