The mob and frustration

Or “should you split up to work on parallel tasks?” 

We had a few weeks of constantly changing topics. We worked a bit on one thing and then we noticed a warning from one of our systems that something was wrong, we looked into it, changed back to the first thing, had to wait for feedback before we could move on, changed focus onto something else, the feedback came in, we changed back, etc…

All of this happening while we had this rather big undertaking looming in the background on which we worked in between the other tasks. Something important that we need to get done but without being urgent. We need to get to it though, otherwise it will become urgent and then it will be stressful and hard to do a good job with it.

As we realized what was happening, with our collective frustration showing in different way, we sat down and talked about it. We uncover that we’re mostly to blame ourselves since we’re trying to be forthcoming to a lot of different stakeholders but we could actually be better at prioritizing. Since a lot of the things that we have been doing have not been urgent and could have waited a day or two, we could have had more focus on the big undertaking while bundling the odd things up for a particular day.

With the blessing of our Product Owner, we decide to clear this last attention stealer out of the way and then focus on the big undertaking for a week.

Back at the mobstation, we start working and discover that we have two things to do: add a link to the front end and add some css to that link because it shows as white on white background at the moment. We ask ourselves gingerly if we should split up for a while. One person could add the css while the others add the link. It is trivial anyway and we’ll be done quicker. We don’t usually do this but maybe this is a good situation? We really want to feel that we’re making some progress.

Everyone is apprehensive. We’re frustrated and want to move forward. But we also believe in the mob. We believe that speed isn’t the bottleneck. We value sharing knowledge over being uncomfortable.

We decide against.

And run into issues with the simple task of adding css since we’re unfamiliar with the project. And realize that what we thought should be a link would be better as a text. And the text isn’t white, so no need for a special case css.

It feels like staying true to our values was the right thing to do in this situation because it’s hardly never a simple straightforward thing in software development. But was sticks with me most is the realization that even it had been a simple and easy fix, it would have saved us at most 10 minutes.

So it’s either more difficult than you think and then you need the mob. Or it really is that easy but then the gain is minimal. The frustration was hurting so bad, all we wanted was to alleviate the pain and for that we almost made a bad decision.

What I learned from this experience is that for me, it’s not worth it to try to gain a little time by splitting up the mob even it would feel temporarily better.

 

 

Photo by Robert Bye on Unsplash

Running a fully remote unconference

Our 20+ people dev team is a remote friendly (single timezone) workplace with people living in different places in Sweden. We get together once a year for an unconference where you are expected to participate physically but we wanted to meet up once during the autumn as well. Having our weekly meetings fully remote already (we just sit at our desks with headsets if we’re in the office), creating a remote unconference didn’t feel like a huge step.

What is a fully remote/remote only meeting?

This is a meeting where none of the participants are sitting in together in a meeting room. A typical meeting requires booking a room for the onsite people and letting the the others join on video/audio link. Being fully remote evens out the experience for everyone. Having some people in a room always creates a “us and them” feeling if you’re not attending the meeting physically and the remote participants are often an afterthought.

So how was it?

Excellent! It gave me the same energy and inspiration boost as I get from a colocated unconference: problem solving with my colleagues, sharing ideas and finding inspiration. It ran ridiculously smoothly.

How did we do it?

We ran a very lightweight event with 5 lightning talks and 2 open space sessions.

We used a combination of Slack, Skype and Trello.

Trello was used to form the agenda the same way that you would do on a board/wall during a regular open space. Anyone could post a topic and then we organised them in Time slor 1, Time slot 2, etc…

Skype for Business was the equivalent of the main room. The call was activate throughout the entire day and people could join and leave. A skype meeting call doesn’t die when the last person leaves it so it could stay active for the entire time that the meeting is booked in the calendar. It also doesn’t have a upper limit of participants (that we would hit in this context)

Slack was used for the breakout sessions. The person proposing the topic would start a call in Slack named after the topic and people joined the call they were interested in discussing. Slack has a limit of 15 people in a call.

Some tips

Do

• Try to keep video on if possible. It gives you those extra cues to see if someone is just about to say something and makes the connection between individuals stronger.
• Slacks 15 people limit is beneficial in this context. You’ve probably attended an open space which is too large for its own good. This gave a technical limitation. Embrace it!
• A couple of us rounded up the day by playing a little mmorpg together to get some of that atmosphere that you could get from having beers together.
• Remote lightning talks has the benefit of allowing you to keep a script by your side so if you’re want to ease into public speaking, it could be a great warm up step.
  

Don’t

• Have the people in the office sit in a room together. Everyone needs to be at their laptop with their own headset. If your office environment is too noisy for this, encourage people to work from home that day. This evens out the playing field for the regular remoters and teaches the office teammates more about the experience of working remote.
• Do this as your first fully remote meeting. It requires a bit of practice and getting used to, both when it comes to the technical set up and how to behave.

 

Final thoughts

I would definitely recommend this as an alternative to a co-located unconference if you have some people working remotely.This experience was further argument in my book that remote teams can be as successful as colocated teams if you’re willing to let them.

 

For more remote teams thoughts and tips: https://www.remoteonly.org/

Remote Mob Programming Set Up

Mob programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer. This is similar to pair programming where two people sit at the same computer and collaborate on the same code at the same time.

A lot of things are being said on the benefits of mob programming and in my opinion they are probably all true. Given a team with similar values and individuals with the ability to put aside their personal preferences in order to move forward* you’ll see interesting results when you adopt it.  Sure, you might feel you’re going slower but you’re being the turtle, not the hare.

I’m not going to dive into the benefits, plenty of people do that. I just want to present my team’s set up for remote mob programming. We’ve had one person permanently remote for the past 3 months and I sometimes call in from home as well. Our team is The Perfect Size of 4.

 

We’ve got a mob station which is an adjustable standing desk, one stationary computer with two monitors, a really good microphone, a headphone splitter, one keyboard and one mouse.

The ergonomics

Having an adjustable desk means that you can switch between sitting and standing. If you have tried standing at work, you’ll know that you’re feeling more awake and that after a while your back will be stronger. We’re happy to have the option to stand while we’re working.

The visual

The monitors are mirroring each other so that it’s easier for everyone to see regardless of where you are standing around the table. There is less of a need to have a huge font size and some programs don’t even give you the option to increase the font size on the menus so having the monitor closer makes it a bit easier.

The coding

We use Teamviewer to share our mob station’s screen and it also lets the remote party have control of the mouse and keyboard. This makes for seamless rotation when switching driver. When you’re the one remote, it’s almost as typing live.

The audio hardware

Our microphone is a Blue Yeti which is a good quality usb microphone. It has a recording pattern which picks up sound primarily from the front of the microphone (and not all the way around) which helps a bit when you’re remote and the rest of the office is chatty.

We used to not use headphones but because of sound quality we would crank up the volume on the speakers to hear the remote party properly and that would disturb the rest of the office. So we wanted to switch to headphones.

In order to do so we started using a headphone splitter which allows us to connect up to five people to the same computer.

The Blue Yeti offers the ability to hook your headphones into the microphone which means that you can hear yourself speak as well.

This is very important because if you’re three people around a table all wearing good headphones, you actually won’t hear what the two others next to you are saying. You’ll only hear the remote party. By hooking in your headphone splitter into the microphone, you’ll hear everyone equally well.

To get this to work, make sure that the Yeti is both the recording device and the audio output in your call settings.

The audio software

Being a .Net shop we’ve switched from Slack to Microsoft Teams :O

It’s working well for us and we create a Teams meeting whenever someone uses the mob station and remote people can join the meeting if they want. It’s basically Skype but embedded in Teams and it does its job.

Summary

It’s taken us some time to find our set up. We started off with working on someone’s machine and each day had a bit of set up time to get things correct. The microphone had to be moved around, etc. Getting the headphone splitter made a huge difference for us (and the office) and getting the mob station also made a big impact.

By now, getting started is quick and easy and being remote for whatever reason isn’t an obstacle for team work.

PS. The Cucumber team is another remote team doing mob programming, here’s a article about their set up: https://cucumber.io/blog/2015/12/21/the-mob-rules-ok

 

*  in one team the first conflict to arise was “-that’s not way you write nice code! – yes, it is! – no, it isn’t! – yes it is!” kindergarten style… and no one budged.

Lightning planning

Some teamwork is better done in silence.

My golden rules for planning:

• I want to spend as little time as possible on the things which don’t matter.
• the goal of planning is deciding what to do, not how to do it

While a planning session can be a drawn out and tough experience with lengthy discussions, I like to keep the planning quick and full of energy and here’s one way of getting there.

Silence

Start by bringing up your work items on a white board or a table. *

Use categories: “do now”, “do later”, “never”, “I have a question before I can decide”

(Regarding the category “never“: some things are not relevant anymore and some you know will never be a high enough prio to make the cut. Just get rid of them, you’ll feel better afterwards.)

Ask participants to move items to  in silence.

If some items move back and forth between the categories, put it in the question category.

After 2-3 minutes you will have a rough filtering of the items without much effort. In my experience, half of the items in our backlog are filtered away.

Put away the “do later” items. Read though the “never” to make sure nothing important gets lost.

Questions and Answers

Now you’re left with the questions and the “do now” items.

Go through the questions (here is where you need to bring your facilitator skills and keep it short. The purpose is to get the question “do now, later or never” answered. Be relentless!

What Now?

So, finally, you’re at “do now”. Figure out how many things you can handle in the time frame until your next planning by using your throughput or velocity.

Now you want to fill those slots. If you have many more possible items than slots, I would try to avoid going through each item on “do now” and discuss them since you want to only discuss the things which you’re actually going to do. We don’t really know for sure which ones those are yet, but we can try to narrow it down.

Here you could use silence again to prioritize from most important to least important by asking participants to move the items in silence. You could also dot vote.

Double check that none of the things which aren’t in your slots is crucial during the time until next planning.

Done!

Why it works

A common mistake is to go through items one by one. There is always something to say about an item even if we agree. Especially if there is a technical challenge in solving it.

By using physical items and silence we enable the team to quickly show consensus on the things which they are in agreement on. We visualize what we need to discuss and what we don’t.

As a former tester, I put a lot of value in discussions regarding work items, the sooner the better. But in this case, I want us to agree upon which need we need to solve first, before we have the discussions on how it’s going to be done. I would say that’s a design discuss, or something for a Three Amigos meeting.

 

 

*if you already have a physical boards, this easy. Otherwise print out your cards and use magnets or write post its for them.

3 ideas to energize your stand up

I already described how using Walk the Board made our stand ups more efficient, here a few more ideas to make them even better.

Have team members take turns to facilitate

To increase the team’s ownership of the stand up (you’re supposed to be doing them as a way to help the team), having team members take turn in facilitating the meeting is a great idea.

Your role when facilitating is to make sure that this meeting brings as much value to the team as possible. It’s good exercise for each team member to reflect upon what that means.

It also livens things up a bit because everyone has different tempo when facilitating.

Furthermore it minimizes the risk that team doesn’t do the stand up when the Scrum Master is away because .

Work with WIP limits

To promote collaboration further and put even more focus on finish things rather than starting new ones, Work In Progress limit (WIP limit) is a great tool.

When there is no more room on the board because we hit a limit, we need to start helping the others out to finish a task or story before starting something new.

Agree on a code word for interrupting discussions

A common problem during stand ups is when a couple of members get involved in a long discussion about for example, design.

One tip to solve this is to agree on a code word to use to cut that discussion short without anyone getting offended. They are welcome to resume the conversation when the stand up is over.

I’ve heard people use SUMO (Shut Up and Move On) and in my team we say “time is like a tree” since we have this motivational poster on our board.

And then…

There are plenty of more ideas to use to improve your stand ups. I’ve heard of drawing a circle on the floor to get team members to stand closer together and other interesting ideas. Dare to explore and don’t just stick with the same formula forever!

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 Master? 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.

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!

Your team and a dining table

I 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!

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!