Customer Collaboration Win!

Dear Kalle and Matte

I think we already have a post along these lines, but I thought I would make one anyway.

Yesterday my team went to trafikverket to watch our system that we build be used live by the customer service department. I know! Watch the people who use the system actually use it…. Crazy right?

Anyway, this was a super positive experience for all that were involved and I just wanted to share a bit about it.

1) You can never know how the user actually uses the system:
Within 10 seconds of having sat down, I (and other team members working with other people) observed an issue with the system that I had never observed before. This revolved around a search function that we never really use on this end. Simply because of the way our test system is configured, it is not really needed for functional testing. (I should note, we are completely unable to test in the production environment at the moment for reasons I won’t get in to). So, this function always seems unneeded to me when trying the system. But a quick observation of live use revealed they use is on every single call they take, and it is SUPER slow. The fix for this will be a very small amount of work (don’t know how much at the moment) and will save the service rep a few seconds per call, over several hundred calls a day, across 20-30 reps. You do the math!
This is only one example of a few 20+ actions we took away from the day. Most of which are easy changes that will make the system much smoother to work in.

2) Showing our faces:
I think the biggest benefits from this is showing our faces to the customers, letting them understand that we care about their feedback and how things work for them. I think this alone has a big impact of the customers perceptions of the system and their willingness to work with us to make it better. I would however note, I think there is an inherent risk with this. It now becomes absolutely essential that we implement some of the things they requested, or that they see some impact from these sessions, otherwise, the attitude of “we complained but nothing happened” will develop.

3) Getting the team charged up:
I think my team deserves major props for taking the initiative to do this kind of thing. As simple as it is, so few teams actually do it. So, they go and get the gratification of seeing that the system is actually being used by people, they get to feel good about themselves for making the effort to do so, and finally they get to feel charged up about making changes to make the system even better going forward!

So, in closing, what I am trying to say is that everyone wins in this scenario! This is just an overview I think I could write on this subject for hours, but I won’t 😉


Personal improvement

Dear Kalle and Matte,

So, I have been thinking about this a lot lately…

Quite a while back I had a sort of epiphany to do with continues improvement (CI), I decided that CI was the true key to successful agile implementations, after that I started to see the need for this in everything I looked at, especially myself. But for this post I will focus on my role and a Scrum Master/Agile Coach.

So, there is a lot of places I want to practice CI, and I have had some limited success with this… Monthly meetings with the Scrumbeers group let’s bounce ideas off people, get feedback and think about new approaches… But, it’s not enough!

The issue is 2 fold:
1) Motivation and focus:
I basically know I need to spend some time reading blog posts, books, attending conferences,  probably a lot of other stuff… But I can’t seem to get my butt in gear and do it. I was trying for a while to read 1 fiction, then 1 agile book… The problem was it was always easier to read a fiction after a hard days work. I am thinking what I need is a solid plan of how often to spend on what. Like 2 hours book, 1 hour blogs a week. And 2 conferences a year… Or something along that line… Then I have to work hard on focusing myself and doing this. Thoughts? Maybe if we vowed to do something as a group? (Could include blog posts here)

2) What do I do!?!
There is soooooo much out there, it is really difficult to decide what to focus on. I tried looking online for a Scrum Master development path, but got no good results from that (Aside from the certification path). I feel I need to set some goals and limitations on myself, while at the same time leaving time to explore and examine ideas I would not normally…
Anyone got ideas about what to focus on? I have too many ideas is my issue…

So, what do you guys say? Who wants to commit a few hours a week to personal improvement? Or, do you think this needs to be a personal journey?

Also, any of our other readership is invited to weigh in on this conversation!


No bosses, no juniors – working at Valve

Hi Kalle,

if you haven’t already, it’s now time for you to go and read what might be the most interesting publication in company and workplace culture this year:

The “leaked” Valve handbook for new employees.

There is just too much interesting stuff in here to discuss in one blog post so I’ll probably break this down to a few posts (or we discuss it on the podcast), but here are some highlights:

  • No management – people work on the projects where they feel they can be of most use and move their desks to form groups accordingly.
  • No juniors – only hire extremely competent and driven people at the height of their careers. No costly bringing up of juniors, they have enough attraction as an employer that they don’t need to “grow their own” – they can attract the best within the business.
  • Compensation based on peer review – salaries are based on stack ranking by your co-workers. You make what the guy sitting next to you think you should make based on your contributions.
  • “T-shaped” employees – hire people with a broad range of skills that are also one of the best in their field within a narrow discipline (sounds a bit like The “Jack of all trades” department put into practice!).

Valve also lists what they think they could improve on (mentoring, predicting more than a few months away etc) which is very self-aware of them, could be interesting to discuss as well.

But what are you waiting for – let me know when you read it, can’t wait to discuss it with you (and Jeff)!

And may all your TF2 hats be awesome,


Day 1 checklist – Make the new guy the hero

Hi Kalle,

since I just started at a new company and am in the first few weeks in the “getting-up-to-speed” phase where you go around feeling kinda useless and stupid, I have two good, solid tips for how to make sure to get your new employee a flying start.

So when you have to hire a guy three years from now to your gloriously successful start-up, whip out this post and make sure to:

1) Have everything ready for them.

Computer, chair, phone, keycard, whatever system access they need (especially to SVN/TFS/etc – for some reason version handling always gets forgotten by HR, I wonder why…).

Everything you need to do good work should be there ready to use at day 1 – no exceptions. If the hire has a choice of computer or phone, make sure to sort this during the time between the signing and the first day so everything is ready to go.

If you have this all sorted and stars align on that first day, you have a chance to…

2) Have the new guy/girl make an impact in the company on day 1.

First day at Lavasoft, I got to fix a bug for customer support that caused their support form to give the customer the impression that their ticket failed submitting, causing the customer to type in the same request over and over again in an increasingly agitated tone, producing a nice mess for the support department to deal with.

I wrote a single line of code, managed to publish the change and voila! – instant gratitude by the support department and saved money for the company on day 1. Couldn’t have asked for a better start.

This was by pure chance in my case but in future hires, I will try to make this part of the introduction plan – to have a task that needs doing that day that is important for the company, so they get to be the hero on the first day of work. I forgot this at my last company, so this is as much a reminder to you as it is to me.

Some ideas for suitable tasks might be:

  • Fix a bug that can be published the same day.
  • Improve the language of a particularly nastily written public webpage / wiki.
  • Answer customer questions on the company forum.
  • Fixing the resolution of the projector in the conference room so that it actually fits the canvas. (We might have this problem at work…)

Can you think of other useful tasks in the same spirit?

Take care,



Creating an API to a team – a system developer’s take at company communication

Hey Kalle!

Been a while since I posted here (we should really publish the podcast too btw, need to speak to Jeff about that).

As you know, I’m now working for a really big company (about 18000 employees) and as such I’m but a grain of sand on a large beach of company culture.

However, the part of the company I’m working for used to be a smaller company that was bought and incorporated into the bigger company in a single-brand strategy (i.e. the old company’s name is not used any more etc). It is still a fairly self-contained branch with stable customer relations that was established before the merger and has the application management of a product that has been around since the early 90’s.

So our department is both a part of the rest of the organization, as well as our own ship, and this reflects in our methodology. In some parts we are running some SCRUM, we are looking at Kanban for some of our stuff and we also have a lot of waterfall in a lot of parts as well as some ITIL-inspired roles for application management. On top of this, we also have a delivery excellence process that is instituted by the company as a whole. In short, it’s all a bit of a mixed sallad (one that has both tomatoes and tuna as well as steak and kumquats – yummy!) with each bite tasting slightly different (not very agile-sashimi at all).

Here is our dilemma:

We need to work out a way of working that works for our independent unit given our customers, our products and our staff – while at the same time working together with the large organization we are also a part of in a way that they can understand and appreciate.

The good news is that I feel that it would be accepted to run any kind of methodology internally in our branch as long as it meshed well with the rest of the company and it yielded great results (i.e. we were efficient and very profitable), so it is a great situation for improving our process. However, the key here is how to work together with everyone else in the company in a manner that is efficient for them and for us.

So I thought:

Why not approach this as a system developer and picture our part of the company as a module in a large piece of software?

If we could just provide an API to the exterior world (the rest of the company and our customers) with metrics and ways of communication that is useful and efficient for them, we could pretty much run any kind of internal process as long as it was CPU-efficient (i.e. cost-effective).

This is obviously the opposite of transparency, and it would be interesting to hear your thoughts on the subject. Maybe transparency should be a topic for a future podcast, sometimes I feel that people just don’t want to know and too much transparency might just create confusion as to what they are looking at.

I’ll keep you posted on how this develops – I think my next step will be to map our “interface” in a way similar to how I would map the interface of a module and see if that yields any interesting results.

Thanks for reading all of this (I think I just scored 0/3 on my own scale…), let’s talk soon.

Take care,



Loose leadership – Lavasoft lessons learned

Hey Kalle,

it’s read-an-article-and-then-read-what-Matte-thinks-so-we-can-discuss time!

Here’s the link:

I’ll give you a few minutes…

Back? Good!

This post from mr Brogan obviously ties into my previous post about The “Jack of all trades” department. He might have even read it. Or not.

Anyways, the idea about leader employees is pretty exciting. Pretty much a situation where you have succeeded with empowering everyone to be decision-makers, something that we worked hard on at Lavasoft if you remember (succeeding in some cases, failing miserably in others).

Brogan had four points that can make this style of leadership possible, I’ll illustrate with some examples from our shared time at the web department of Lavasoft for your reading pleasure (ah, the memories):

1. “Bumpers” to keep your team from making any grievous and irreparable mistakes. 

At Lavasoft, this would be the peer reviewing of design decisions and the sanity checks in stand-up meetings. Also, the whole back-up support from a manager in tricky communications with partners and other departments. When it comes to expenses and being able to drive parts of the budget themselves, we never came that far – I mostly took advice on which licenses and office equipment we needed and mad decisions based on that. That would have been an interesting thing to try, putting people in charge of different parts of the budget and managing that all by themselves.

2. Production- and results-based metrics versus “butt in seat” metrics.

We were never much about metrics for performance at Lavasoft, and we didn’t need to be since we had such a small team (about 5-6 members) and good daily communication that I knew what you guys were doing and how it was going. Not much need for metrics then, but in a larger organization they might form a good starting point for discussion and a fairly unbiased measurement (the bias, of course, lies in what you measure though).

Putting in the wrong measurements though might lead to everyone managing their own pet projects, the success of which they’ll be measured by, and competing for resources for these – not my favorite kind of workplace.

One solution might to be set metrics for the group instead (hewwow SCRUM sprints!) that are better indicators for if people are performing. And then coach the group to figure out what needs fixing.

I’ve heard example of real estate brokers (of all things) that get provision based on how they are doing as a group, which encourages them to send prospective buyers to other brokers properties as well which benefits everyone in the group – something that a straight bonus system based on individual performance traditionally discourages.

3. A more open communication stream. 

Hopefully you’d agree, but I tried hard to give you guys as much information about what was going on in the company as possible, barring sensitive information about co-workers and such that wouldn’t benefit you and actually would hurt someone else.

I think this is just common sense – the more information you guys have, the better you can make decisions on your own. You will always be more knowledgable about the technology than me anyways since that is your speciality so if I can impart as much relevant information about the business as possible, we’ll can cut out me as the middle-man in decision-making, making us less vulnerable.

This stream should always be finetuned constantly so only relevant and interesting information is passed on both ways (“I don’t think I need these numbers anymore, they are useless to me and I never take any action based on if they are high or low since I have better indicators if the application is performing as it should or not. If you say we’re doing fine, that is enough for me and more efficient.”).

4. An active learning culture and mistake-learning path.

It’s always healthy to question how things are done at the company. It’s important to keep this constructive though. The “What puzzles us?”- question in the heartbeat retrospective after sprints was a good way of catching organizational flaws that needed adressing by someone with a bit of clout with the rest of the organization (“Why does marketing always deliver their stuff a few days late?”). I guess if you have a group of leaders, you should coach them in optimizing these things themselves (advice them a bit on how to approach Marketing in a constructive way on this subject that might be a little bit touchy).

We had a lot of shifts in how we did stuff (build-your-own vs adapt-your-own, figuring out what the web department should focus on, adopting SCRUM) and most of these were results of employees pointing out flaws in the way we worked and suggesting that we examine alternative approaches.

So, did we have loose leadership at the web department at Lavasoft?

More so than some other departments I would say. We were a long way from embracing it completely I feel, but the aspects of it that we implemented (without ever labeling them “loose leadership” per se) worked pretty well and were beneficial to us.

And that is the key take-away for me:

If you are constantly trying to get better, you’ll never be fully optimized and content, ever.

So make sure that each step is a goal in itself and makes you happier, more efficient or more powerful by itself, while at the same time bringing you closer to a goal or vision of how you want things to work.

Let’s do lunch some day,


Russian pomodoroulette

Hi Mattias,

I would like to share with you an experiment I performed last Tuesday. Knowing that you too have been using the Pomodoro Technique lately, perhaps this twist will interest you.

This day started like many others with processing of inboxes and grooming of the to-do list. Ending up with a short list of quite differing tasks I felt like no prioritization would make me satisfied, some items where small, some larger and some open ended… I did however find that they could be categorized into three projects. The natural instinct was to leave the digital and move the tasks to three project cards along with more detailed notes and related activities. Great, so I had brought order, I had categories but I had not accomplished anything at all! All three projects felt important but in different ways, all were also open ended or huge, making it even harder.

Here comes the thing. Wanting to work on all projects but incapable to find a way to order or prioritize I gave them each a number from one to three and went over to to get a random number between one and three. I then worked on that project for 25 minutes (one pomodoro), took a break, went back to, worked on whatever project it gave me next …and so on.

The most interesting thing about this process was perhaps that everything became much more fun. It feels a bit silly to admit this, but after each break randomizing to see what’s going to happen next was actually kind of …very exciting. The more boring project even became fun, perhaps because I knew that something else was likely to come in a very short while.

Another thing I found interesting with this was the peace of mind I experienced after accepting a random number generator to make the decisions for me, delegating to random you might call it ;). Worth mentioning might be that these decisions were not important. Somebody once said “Don’t think too much before making reversible decisions…”. I’m now proposing: Don’t think when making decisions; let decide! 😀 …or perhaps a dice.

Well, that was just some random thoughts.

Take care,