X Unit Tests, 0 Integration Tests

Sometimes a gif says more than a thousand words. In this case, what happens when you only focus on unit tests and don’t test anything else?


Here is my personal collection of “X unit tests, 0 integration/usability tests”



The faucet works, the sink works…





The tunnel works, the truck runs…





The trash can works, the dryer works…


And my personal favorite:



The lock works!


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.


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.

Becoming a modern Renaissance Woman

TIL: my wish to become a programmer stems from wanting to become a renaissance woman in my field.

It’s difficult with all our advances in science to be among the top in many different fields, the same way Laura Bassi did in the 18th century for example. But I think within the field of Software Development it’s (possibly, kind of, for some definition of it) achievable.

Not in the sense that I want to be recognized as the top but I want to understand this field. Like deeply understand.

I already know a great deal about testing and realize that I’m far from knowing it all. I have some awareness of where some of my gaps are. I feel that’s more than I knew when I started out, or a few years ago. Some day I might fill those gaps and probably discover new ones in the process.

I’ve also come to understand and learn about teams and coaching. Here, I’m not as far advanced as I am in testing. It’s an incredibly vast area but barely scraping the surface has given me powerful insights already.

Coming into the world of programming and making (more) sense of how systems programmatically fit together will give me another piece of the puzzle. So far, I’ve been approaching it from the outside perspective. I’ve seen programmers struggle and I’ve helped best I could but I haven’t experienced it first hand. This is of course the most crucial piece of the puzzle since without the act of putting the software together, we’re not doing Software Development.

Not that the software has a raison d’être in itself. If we can solve the problem without software, that’s even better. I just want to contribute when the software is designed to make someone’s life easier. For example, it can be that streaming a movie is easier than going out to rent it or that new entrepreneur can charge for her goods easily.

My best guess is that my journey will take me through a few more different roles within Software Development. Or maybe rather than roles, performing other activities than testing, coding and coaching. It wouldn’t surprise me if I find myself iterating over those activities to deepen my knowledge.

It’s in that sense I see this change of career path as a part of becoming a renaissance woman. Rather than specializing in one or two fields of Software Development, I want to see as many perspectives as I can.

I find myself driven by one main question “how does it all fit together?”

Looking for a programming job

Here is my full resume as PDF: UlrikaMalmgren-Resume
LinkedIn profile
(Unfortunately I’m not interested in consulting, relocating from Stockholm or remote work at this point in my life)

I’m looking for a job as a programmer. Even though I’ve been working with software development for 10 years, I’ve never written production code for money. There has been the occasional helpful tool, automated testing and such but never anything a user has seen. After a year as an agile coach, I’m dying to dive into programming!

(But why? I think partially because of this)

What I’m looking for is a team where I’ll spend most (all?) of my time working together with the team members and where people share my love for quality. I want to spend my time pairing or mob programming. I don’t know what kind of programming I want to do, I’m just ready to explore.

Even though this will be the first time I dive into production code programming, I’m not a Software Development rookie.

What I bring to a Software Development team

  • knowledge and understanding about testing. What it is, what it isn’t.
  • experience as a team coach
  • knowledge and understanding (and love!) of Kanban principles
  • problem solving intuition
  • pushing on to finish: I have the endurance to get things done. I mean really done with all the details.

I have basic understanding of git, terminals, unit testing, java, python, ruby, cucumber, selenium. This means that I’m able to do some basic programming projects without spending too much time on Stack Overflow. 😉

I feel that my Master of Science in Information Technology studies have helped me reach good intuition about problem solving and troubleshooting which I’ve been developing ever since. I have to be honest, I do love a good troubleshooting from time to time. KTH also boosted my self confidence. After all the operating system, parallel computing and message passing labs, I feel that there is nothing I can’t conquer.

From my time as a tester I’ve learned many ways in which things can go wrong. Testers quickly learn that their work is not done until the i’s are dotted and the t’s are crossed which means that there is no room for sloppy work. You need to fire up IE7 even though no one in their right minds wants to use it.

As team coach, I’ve developed an arsenal of techniques to help a team from slicing work into meaningful pieces to getting to know each other’s personal values. I’ve also experienced what benefits a pull system can bring to a team. I believe these to be helpful for any team.


My Software Development values

(If we don’t match in values, there is no point in going further than this)

  • one small thing at the time: it’s just better and faster. Not everything can be highest prio.
  • get feedback quickly: we need to know if we’re on the right track. Let’s not plan in details too far ahead.
  • working together: it’s better for quality and creativity. It’s a waste of time to not pair.
  • take time for improvement: you need to carve out time for improvements and use it well. This is as important as features.


So there it is: junior developer but senior team member. What do you have for me?

Here is my full resume as PDF: UlrikaMalmgren-Resume

LinkedIn profile





How important is writing?

I read this interview with Matt Mullenweg , the creator of WordPess, where he says:

“Skill in writing is one of the things I look for the most in hiring, because I feel that clear writing represents clear thinking, regardless of someone’s background, or whether they’re a designer or coder or whatever.

The ability to communicate effectively and clearly in written form is not only super important in a distributed company, but I think reflects well on how they approach life in general.

Part of the reason I started blogging and started working on WordPress was because I love writing.

If I can become a better writer, perhaps I can become a better thinker.”

I feel that my writing reflects my thinking a lot. I’m a slow writer, an email takes me ages. I pick my words carefully, delete, rewrite and keep going until perfection or until I say to myself “come on, you’re just cancelling your subscription, this is probably good enough”.

I wonder if the process shows in the results. I also wonder how my favourite colleagues do in this regard. Would I have hired them based on their writing?


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.


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.planning

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.


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!