Tabula rasa & menti rasa

…or how valuable is really the empty mind / the beginner’s mind?

Hi guys,

Firstly, I’m not a latinist, as you know; you will have to excuse me… “Tabula rasa” is frequently translated as “blank slate”, to that I wanted to add “blank mind” and I don’t know if “menti rasa” works, but now you know what I was going for “Blank slate & blank mind”.

Now, this matter is like an untangled string in my mind, it has been with me since before I identified with it and before I saw it as “a thing”. Perhaps you can help me untangle it. And may I boldly suggest that perhaps we will untangle or tangle each other’s strings in this process. This is my aspiration.

I’ll simply share my personal experiences and thoughts without much judgement and hopefully a narrative will emerge.

Since early I have been turning to philosophy. If you ask me which philosophers I like, or who influenced me the most, I have no idea; I’ve barely read them. In fact I have been afraid to. I thought that their definitions and descriptions of things would limit my thinking and my view of the/my world. I still think like this; still I don’t read them.

So, I wanted (and want) to understand the world on my own terms as far as possible. This is perhaps complicated and not all that relevant. I bring it up because it was my first experience with the will to stay pure/untainted or stay with my “blank mind”.

For about 10 years I think philosophy was the only subject getting this treatment in my life. And then I remember having similar thoughts in late Lavasoft. These thoughts were, I think more concerned with Method rather than world view. And I think this is where it may become more interesting to you …but before that, I want to share with you my most resent experience and the trigger for this post.

As you know I’m screwing around in Asia. However, my recent experience is not of a philosophical nature (as you might guess from the Asian context). Instead I started to think: Fictional writing. This is a new source of pleasure, pain and curiosity.

Two days ago, with recaptured ambition I started describing the world, circumstances and the conflicts of the universe where I wish my story to play out, I believe this is “Outlining”. I am not sure and I don’t want to know because I want to try and fail with the facilities I already control before I see how other people do it. This is key. Do you think I am wise in this thinking?

To look in a more familiar direction: Before drinking software methodologies we often/hopefully see that something is wrong. And then we take somebodies else’s word for a solution… a solution we think we grasp, sometimes we kind of do. But do we grasp the difference between their and our situation and do we see the core of the principle (in many cases the preachers do not even see the true nature, but merely his/her situation in relation). In large there are big assumptions regarding cause and effect. (But as you know: true conviction alone (confused or not) is stronger than most problems).

Wow, I have no idea where I am right now. Did I had one golden camel? …which one am I?

Can you perhaps help me figure out where I’m trying to go here? And if so, what do you think about it?

Love,
Kalle

International speaking engagement!

Dear Matte and Kalle (If you are actually still reading this)

So, I am very excited to be asked to speak for the first time ever in another country!
I will be speaking at Agile Vilnius 2013!

So, the only thing left to decide is which topic I want to talk about…
I lean heavily toward my retrospective talk, as that is my best material. But…
Vaidas (who invited me) Thinks a talk about testing in an Agile environment will draw more of a crowd…

Opinions?

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 ;)

//Jeff

Best naming convention ever

Dear Kalle and Matte

My new team has the best naming convention ever!
Every sprint is given a alphabetical identifier. So, we are currently is sprint K, but that’s kind of dull right?

So, each sprint is named after a particular cake. Last one was “jordgubbstårta” and this one is “Kladdkaka”.

Then, after each demo, the teams and the customer eat said cake to celebrate a successful sprint!

Very nice way to end a sprint, have clear naming for future reference, and socialize with the the customer!

Will be advocating to teams going forward!

//Jeff

Rentastartup

Dear Kalle and Matte

Just an idea I have been bouncing around in my head… I would like to hear what you guys think.

Would services like rentacoder or elancer be good for startups? I have actually no experience with these services, so, this is purely an intellectual exercise.

Possible Pro’s:
Quick prototype:
One of the main focuses of the lean startup is to get something (anything) out fast, and see how people react. Since rentacoder has people at extreemly low prices, and you are not yet overly concerned about questions like code quality, you could have something hacked together for very cheap that you can use to test your first assumptions.

Possible Con’s:
Hard to iterate…Maybe?
Since you hire the coder for a limited amount of time, they may not be there when you need to iterate to test your next assumption.

No passion:
I suppose it would be hard to expect a hired gun to be passionate about the product you are trying to create… Although, is that really any different from any employee in the short term? I am of the opinion that most developers are self motivating, at least in the beginning.

Opinions?
There are a lot of things to consider around this, but I will leave that to you guys to bring up ;)

//Jeff

Definition of success

Dear Mattias and Jeff.

I am writing to you as I can not sleep and I fell to thinking, or perhaps it was the other way around. Anyway, I remembered Jeff asking me to elaborate on my definition of success idea. And I can imagine you would like that too Mattias.

Questioning, distilling and trying to see a bigger picture have intrigued me for some time. At Lavasoft this drove me to discover and learn many things. This is one of those things.

At one point, trying to do things as smart and effective as possible no longer seemed good enough; there was simply no way to keep everybody happy, there were fewer of us and seemingly more work to do. A new approach was due. Taking a step backwards I asked myself with sincerity: Why are we doing these things? What is the intention? What are we trying to accomplish?

At the time I wrote the following:

I’ve been thinking a lot lately about how we almost never evaluate the end result of our work. We complete stories then we demo to evaluate the end product, then we have a retrospective to evaluate how we worked to realize the product. We almost never evaluate the effect or the success of our projects. In the end this is what really matters. I also find it very likely that doing this will be how we learn what kind of projects to accept, question, investigate, initiate and so forth.

Self-quoting, isn’t it sweet? ;)

At the time I called myself a Product Owner, however I found no guidance from agile in how to deal with these matters. Instead I found inspiration in the idea of Retrospectives and a concept: Definition of Done. The later is essentially an aid in the question “What are we making?” Asking in the same way: “Why are we making?” and I got Definition of Success.

The quick and simplified answer to these questions were usually: We are trying to make money (for the company). The particular answers turned out to be of no interest, asking the question however was paramount.

This is how to use it
in order to better understand Why to build What When.

[ TODO Big bad advice here, something like: “Or don’t. Don’t follow other people’s advice – it is too often harmful…” It’s turtles all the way down! ]

Whenever someone would ask us to put something in our backlog we would talk to them to make sure that we and everybody involved understood why this should be done. In some extreme cases the person with the request was “stuck in the middle” and there because a third party wanted something that none of us really understood. Walking over to this third party generally made things clear for everybody, futile efforts was avoided and everybody had cake. There is nothing new to learn here.
Often however, the people involved came straight to us, and usually we all quite quickly understood why something seemed like a good idea. A “good idea“ isn’t good enough if you have too many. So this is where we would try to understand the intention or the desired effect more clearly…
Wow! Hi Mattias! I forgot that I’m writing to you and Jeff. I think I’ll keep this style though, the sparse usage of Software Development and Agile lingo forces me to think.

  • Fixing a problem in an internal tool might have the desired effect “Reduce hours wasted by support personnel circumventing this problem”.
  • An alteration to the web store might have the intention “Increase number of upsells” or “increase conversion rate after user adds products to cart”.
  • A mailer might have the desired effect “convert free users to paid”.
  • Updating outdated information on the front page might have the intention “make people trust us.”

(I know, this is scary; we ask our colleagues and ourselves to summarize complex things in simple words and recognize these as the truth. Though very helpful to catch the most crazy of things and the least questioned assumptions …if done too far or too systematic I’m sure you will arrive at a soulless place with no business.)

Wait… There is still nothing new to learn here.

This is usually where we make estimations from the gut. I would estimate the time required from us and the other party would put a measurable outcome, like: I expect to…
“Eliminate 2 hours wasted by support every day.”
“Increase number of upsells by 20/week, can be checked after one month.”
“Convert 2 000 free users to paid (can be checked 8 days after the campaign has gone out).”
“Make people trust us more(!?).”. This one obviously doesn’t fit the framework. I think this is where you should see that measuring things needs to live side by side with sense, emotion and instinct. (Don’t be a scientist).

Sometimes this is enough information to agree if the thing is a “Go” or a “Gone”. For example: The time required is small and the effect is really good. Or the time required is substantial and the effect is unknown and unmeasurable.
Often though, the discussion has to be delayed until more accurate estimations can be gathered.

After everybody agrees that something should be done the task/story/project may be updated to include the most relevant information, like this for example:

Fix problem with cake getting stuck in cakemaker tool
in order to reduce hours wasted by support.
Definition of Success: Support no longer waste ~2 hours per day on this.

Restructure the web store
in order to increase upsells.
Definition of Success: Increase number of upsells by 20/week, to be evaluated after one month.

Perhaps you can see the bigger idea here:
Build a habit that encourages everybody involved to talk about and understand what they are going to do/make and why. Encourage people to think and talk about what kind of outcome can be expected.
Furthermore, build a habit that encourages reflection and discussion on the effect of projects after they have made a dent in the business and the world. “Has it been a month since the web store updates?” – “Yes, it has and we have seen a trend in the number of upsells. We now have around more 100 per week!” – “OMG that is amazing!” …Or: “The campaign to convert free users to paying, converted 400. That is great … we expected five times that but it was still a success.” And everybody has cake.

If you use a board, such as Scrum, Kartoffel or Kanban, you can make sure that cards/stories have a “Definition of Success” before they move into “Ready” (unless too small to bother investigate or somebody used a “veto card”). Furthermore you can add a column: “To be evaluated” after “Done” on your board. Cards and their effect may then be evaluated together with stakeholders before being archived (the cards, not the stakeholders).
Understand that your Definitions of Success will be off. Like crazy. This doesn’t matter, the point is to talk about and recognize why we do things before and after.

I didn’t feel like I saw this through. Good things came of it for sure and I had a strong feeling that more good things would come had I not submitted to …fear?

Most of this information is probably only potentially useful in less than ideal situations. In a better scenario I think there is room for less science and more Power of the Flower.

This post grew into a crooked. And I can no longer see clearly. Posting now before this gets further out of hand.

Love,
Kalle

Making your retrospectives better!

OK, so Mattias asked me about retrospective tips today.

This is a video of basically exactly what I have started teaching my classes. All credit here goes to Ola Berg, I stole this from him basically line for line.

Also, I forgot to add in the video: since we have regular retrospectives  we don’t need to find a perfect solution to our big issue, we just need something we can try for 2 weeks (or until next retro) and then we reflect again and see if that worked, if not, we try something else.

This is a very quick job on the video, but I am considering making a nicer version for distribution. This version is totally unedited and missing the bit I mentioned above, also, what I write on the board could be better.