Get more value out of your stand ups by throwing out the three standard questions

Are you tired of long stand ups where people merely report to the Scrum teamandboard_2Master? Do team members list all the ways in which they are busy rather than sharing information with each other?

 

One technique has helped my recent teams get more focused stand ups: Walk the Board. (Update: @KirstenMinshall pointed out on Twitter that Walk the Wall is catchier )

 

Instead of having each team member answer the three standard questions (what did I do yesterday? what will I do today? and what am I blocked by?), Walk the Board emphasises the stories which populate the board.

 

You move through the board story by story, but starting with the ones which are the closest to completion.

 

You start on the column to right which is usually “Done” or “Deployed” and then move left one step at the time. In each column, move in order of priority until you have talked about all stories.

board_numbers

For us it means that we start talking about the stories which were deployed since last stand up (see (1) in the picture). We then move over to the stories which are waiting to be deployed (where testing is done – (2) in the picture). We ask “what do we need to do to deploy this today?” and make sure that we’ll work towards removing obstacles or doing those tasks.

 

After that we have the stories which are in testing (3), and we ask “what do we need to do to get testing done today?”

And so on.

After having gone through all the stories, we ask if there is someone who hasn’t spoken in order to identify any work which isn’t on the board.

 

Benefits

 The story and not the individuals are the star of the stand up

Instead of focusing on the individuals and how much work they have achieved, Walk the Board emphasises the goal of the team: getting things done.

We don’t care how busy you were, what’s important to us is real progress.

The story needs to be finished, it doesn’t  matter who is working on it.

 

A team effort instead of individual performance

Again, the objective is to finish those stories and by not asking the individuals what they have done and instead ask the team we reinforce the feeling that we help each other towards our common goal.

 

Higher level of engagement

The stand up becomes more interesting and I’ve noticed that the level of engagement for everyone is higher. Maybe it’s the shared enthusiasm of collectively getting the stories closer to completion.

Of course, it doesn’t solve everything. If a few team members get caught up in a design discussion, it’s still possible to start dozing off.

 

Conclusion

Walk the Board is more true to the original purpose of the stand up.

The stand up is a meeting created to help the team. They are not for reporting to anyone but often we end up in stand ups where everyone reports to the Scrum Master.

A symptom of this is when the team doesn’t have stand ups when the Scrum Master is away.

When the team doesn’t use the stand up to report to the Scrum Master and instead finds a value in the meeting, they are less likely to ignore them.

Try out Walk the Board and see if it helps you reinforce team work and get more energy into your stand ups!

Advertisements

Your team and a dining table

menu-restaurant-vintage-tableI don’t believe the classic team sizes of 7 (+- 2) people. I feel that those teams are too large to have meaningful conversations.

My rule of thumb for a team which I’m comfortable in is the dinner table heuristic with an ideal size of 3-4 people.

The dinner table heuristic explained

Imagine you’re having dinner. If you are 2 people you can have a close conversation and both of you part take actively without problem. A two person conversation is more intense than others since you will have eye contact all the time.

At 3 or 4 people the conversation is still easy. Since you can slip in and out of taking an active part if you wish, the conversation is less intense than with just two people. At 4, you might split up into two pairs but it isn’t necessary to in order to feel that the conversation is even. It might even feel a bit strange to not have the conversation in the full group.

Larger than one dinner table

At 5, something happens. The awkwardness at dinner of being an odd number and having to occupy a four person table plus one is echoed in the conversation (no one wants to be that odd person out sitting with an empty chair in front!).

You will either try to keep everyone in the loop or you will start to split up into subgroups with 2 and 3 people. If you split up, instead of one conversation, the dinner party has several simultaneous. If you try to stay within the same conversation, your average speaking time is 12 minutes per hour.

At 6, frustration is starting to make itself known if you want everyone to take part. Otherwise, subgroups of 4+2, 2+2+2 or 3+3 will form.

At 7, you spend less than 9 minutes per person and hour speaking in average, which 15% of the time. Because it’s harder to try to participate, some people will disappear from the conversation by staying quiet. You are possibly interrupting each other since it is harder to find an appropriate time to speak. Not only that, but booking a restaurant table for your team activity is starting to get difficult.

Beyond this, it just gets harder and harder with less and less time per person to speak.

So what?

Let’s look at the quality of the conversation.
In a setting with for example 7 participants, some people lack the energy to participate and battle for their space and we loose their insight and opinions.

Instead we get only the opinions of the outspoken and extroverts who have the energy to make room for themselves.

You can also spot some people who aren’t actively listening. They are just waiting for their turn to speak because finding that gap is crucial to be able to say your piece.

When individuals don’t have a natural space to talk to each other, risks and concerns might not be voiced. Engagement goes down as well as the feeling of having fun or being appreciated.

Conclusion

There is something which happens when your team reaches 5 people. It’s the first time subgroups naturally start to form because it’s easier that way. If you want your team to have have the possibility to easily have meaningful and rewarding conversations, it might be an idea to limit the size of your team.

Use Brain Writing to make your retrospectives more equal

If you are struggling with quiet team members who never say a word during retrospectives, or on the contrary, loud team members who don’t understand to let the others speak once in a while, then brain writing could be brilliant for you!

Brain writing is a technique for brainstorming in a group. It can be used during the “generate insight” phase of the retrospective.

Everyone starts with a stack of blank papers and a pen. They get 3 minutes to write down ideas, one per paper. When the timer rings everyone passes their papers to the right and receive papers from the person to the left.

Now you have a new ideas which you can use for inspiration. You can either add things on the paper if the idea sparks new ones related to the one on the paper or start a new paper if you come up with something entirely different.

The exercise is over when the first papers come back to the original author. Now put the papers up on a wall or lay them out on the table and have everyone read through them and be awed by the amount of generated ideas!

We used this template for writing down ideas:
“To be better at __________
We need to ________________
Every _____________________”

For example we had:
“To be better at knowledge sharing
we need to do more mob programming
every now and then”

I love brain writing because:

  •  it is a silent activity, everyone is on equal terms. The loud person doesn’t get too much space and the quiet person gets hir ideas heard as well
  •  building upon other people’s ideas is inspiring and creates a lot of “yes, and …!” moments
  • the template made us focus on purpose of suggested actions.

Finish with a round of silent prioritization for “Decide what to do”, pick your top 1-3 and you’re ready to start working on some inspiring improvements!

I want to be selected for my gender

There is a lot of discussion regarding picking keynote speakers, speakers in general or even recruiting. Some say we need more women speaking but many women say that they don't want any special treatment, they want to be selected based on merit.

Like many, I dream of a world where this isn't an issue. In my dream world, there is a natural mix of people from different origins, ages, sexes, etc in our industry. In my dream world, I even leave room for people who prefer Star Trek over Star Wars (I'm generous that way).

Until that it is a reality, I'm not scared of being selected based on my gender. I used to feel sad about it, getting job offers and invitations to speak just because I'm a woman (you can often tell. Sometimes because they say "we need a woman".). I questioned if it really was my competence that was attractive or just my gender.

But I have come to realize that the truth is that because I'm a woman I bring more to table than my male equivalent.

You know what, I even bring more to the table than then my male superiors!

What we are lacking in our industry isn't talent. There is plenty of talent to go around. What we lack is diversity and all of the benefits diversity brings with it.

So I'm not only bringing the audience competent ideas, I'm showing that it's as normal for a woman to have competent ideas and to present them on stage. I'm bringing in my perspective on things and unfortunately, because we raise our boys and girls differently, my perspective will differ in a general sense from men's. By bringing all of this, the audience's world is growing.

Until we have a more equal proportion of women and men as speakers, I'll always wonder if I was picked based on gender or merit. But I have decided that this will be the price I have to pay in order to give more women the ability to speak at conferences. I'm willing to pay that price because I believe in the end result.

I have come to realize that my ideas + my gender is more valuable than just great ideas and one particular piece of information made me change my mind.

I listened to Sharon Vosmek presenting at Stanford Entrepreneurial Thought Leaders Series and she talked about some interesting research.

Researchers at MIT discovered that three factors have an impact on the collective intelligence of a team:

  • the ability of the team members to interpret other's feelings (can I tell that you are sad?)
  • the equality in the conversation (is everyone given enough room to speak?)
  • the number of women in the team.

The natural question is of course, up to what proportion do women increase the collective intelligence of a team? Up to a 100% according to the researchers. The theory is that women are in general better at the two first factors than men (probably from how boys and girls are raised).

The implications are huge. It means that we should acknowledge that the interpersonal skills are very important for software development. It means that you can favor picking a women over a man without feeling bad about it. It might even mean that you are making a bad decision if you don't.

My wish is that more women would accept that the world right now is unequal and that they, like me, start to pay this uncomfortable price to pave the way for more equality.
My wish is also that more men would make the equally uncomfortable choice of picking women over men sometimes to pave the way for more equality.

Until we are in an equal world, I want you to pick me for my gender.

A planning session

The team realizes it’s time to step away from the computers and train of thoughts and head over to a conference room for the meeting. Reluctantly keyboards are abandoned, screens locked and everyone shuffling their feet like 5 year olds asked to clean up all the while the code conversations carry on well into the conference room. Until the Scrum Master interrupts.

– We have been asked to estimate this task of upgrading a component to a new version.

Everyone nods and discuss what such a change would mean and after a while dive into code on the projector. Solutions are discussed, details are demanded, implementations analyzed. The code archaeology session is well underway when someone says:

– So there are two possible solutions then?
– Yes, basically, responds one developer and continues to list which classes should possibly be modified.

The conversation carries on a little longer until the same person speaks again, carefully.

– Will the two solutions take a different amount of time to implement?
– No, that’s not likely, another developer answers while the others aren’t leaving their train of thought on the code and classes.

The person now addresses the Scrum Master instead while the developer’s discussion is getting more heated regarding the state of the legacy code they will be forced to work in.

– What kind of estimate are they asking for? I mean, what granularity, number of sprints or so?
– Yes, exactly, just to get a feeling of roughly how much time it could take, the scrum master answers.
– How long do we think it’s going to take then? This time, the person speaks a little louder, making sure to interrupt the conversation and gets everyone’s answer.
– About 2 sprint I would say, answers one person. Everyone nods and agrees and the conversation moves from bashing the old code to discussing benefits and drawbacks of the different solutions.

– So, I guess we’re done then?

The room goes silent and the person meets everyone’s questioning looks.

– If both solutions take about the same time, which is about 2 sprints and that’s the kind of estimate we are asking for, then we have our answer, right?
– You can leave if you don’t want to be here, offers a developer, clearly annoyed by the interruptions, and tries to go back the debate on which solution to choose.
– My point is that we can all leave, retorts the person, interrupting again.

The silence is tense.

– Everyone here has something they would rather be doing and we don’t even know when we will be asked to do this change. By then we will have to go through this discussion again with the same arguments and the same procedure of digging through the code because we will have forgotten about it. Our goal was to give an estimate, and we have that. Let’s go and do some work!

The conference room is left with a light, relieved step and the team is filled with anticipation of the work that will be done in the 40 extra minutes suddenly gifted to the them.

Experience report: testing dojo with entire dev team

Last spring I worked as a test lead/quality coach for 3 teams that did their own testing. I experimented with different techniques to help them further improve their testing skills. I wrote this experience in March but I didn’t get around to publishing it then which I’m doing now.

I want to share with you another way of combining testing, learning and fun

At the Agile Testing Days in Potsdam/Berlin I accidentally ended up in a testing dojo session. For an hour, 4 pairs of testers tried their skills at a buggy piece of software and received feedback about their testing. It became immediately clear to me that this was a great opportunity to improve testing skills and I decided to try it at home with my teams.

I work as the sort of test lead who provides inspiration and encouragement for 3 teams of programmers who do their testing themselves. For our domain, web development, this works well. We have developed a testing strategy together and I also help them improve their testing skills. They are awesome, committed to continuously delivering value to our customers and eager to do a good job.

I planned a testing dojo of an hour and promised candy and laughs. The response was, to my relief, positive. I wasn’t sure that they would want to spend an hour of precious programming time doing testing. I chose an hour so that it wouldn’t be too long and it was easier to find a room and a time slot.

The preparations took a while because I needed to decide on a suitable piece of software and read up on dos and don’ts for testing dojos.

Finally, the software I picked was the one I had tested in Potsdam. It was crawling with bugs and this meant that everyone would find some. I thought this would be good for a first session to make everyone comfortable. It was also small enough to be constraining but big enough to allow people to try different areas. I also wanted to have something which no one in the teams had written themselves so that there wouldn’t be any awkward situations. This meant finding external software.

The parking rate calculator – object under test http://adam.goucher.ca/parkcalc/index.php

Format for the dojo
We had the 3 roles described in the testing dojo document. Every 5 minutes we rotated. We ended with a 10 minute debrief to discuss what we observed and what was good. http://www.testingdojo.org/tiki-index.php?page=Roles

Setting up the environment
I created a few posters which I put up on the walls. They detailed the format of dojo and the parking rates for everyone to see.

I explained carefully the purpose of the dojo. I put the emphasis on the fact the purpose was to learn from each other. This means that both observers and testers learn and we should be gentle to each other. It’s not easy to sit down a new computer and start testing in front of everyone, there needs to be humility from the audience for this. And on the other hand, active and good observers are key for learning.

How was it?
First of all, we had fun! The overwhelming buginess of the software created a lot of reactions: surprise, confusion, entertainment, frustration and joy.

The programmers were a bit overwhelmed by the amount of bugs. This is the downside of using this test object. In a normal situation I would just send it back after 2 minutes, but this isn’t a normal situation. I encourage splitting the debrief into two parts: “what did you think of the software?” and “what did you observe about the testing that we did?” or even say “let’s agree that the software is crap, but what did you observe about the testing?”.

It was clear that this was an ad hoc session. There was no plan and a lot of randomness. A few people started trying to be systematic but bugs caused them to lose focus. We tried a bit of everything, here and there.

This was a good thing though. For the group to observe this randomness was interesting. It shows well of you can spend an hour testing without knowing much more than when you started. When answering the question “what would you do differently if you did it again?” the group answered that they would be more systematic or organized. We also tried to highlight some of the things that the participants had done successfully.

What now?
We will do it again. This time I want to start with creating a plan together and see the difference in an organized approach. After this I think we’re ready for code closer to our domain or maybe even our own code.

Conclusion
I strongly recommend doing this kind of exercise with your team or your peers. It’s fun, interesting and a great opportunity to pick up new skills.

 

Book club suggestion: What to do with bugs?

In my old team we had the discussion about how we should handle the bugs we found. There are a few ways to handle them.

  • fix them
  • prioritize them among other items in the backlog
  • leave them to die in a bug reporting system

Would you like to have that discussion with your team? Hold a book club (blog post club?) over lunch to get the discussion going.

I suggest reading both Elisabeth Hendrickson’s  “Bugs spread disease” and Jeff Athwood’s “Not all bugs are worth fixing” and discuss them together. Talk about how the articles make you feel, what advantages do you see with each approach, and what long term effects do you think they have. Also talk about how it applies to your team and get extra credit if you devise an experiment to try in your team during the coming x weeks.

Book clubs are great for many reasons but their main disadvantage is the fact that they are long. People usually read half a book but rarely finish them. That’s why articles or blog posts are a better fit for a book club.

Happy reading!