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!

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.


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.



 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.



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

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.


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.