Open letters from Kalle to Matte (and vice versa) about stuff we both care about (and also some Jeff)

Menu

Agile

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 😉

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 itin order to better understand Why to build What When.

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 toolin order to reduce hours wasted by support.Definition of Success: Support no longer waste ~2 hours per day on this.

Restructure the web storein 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.

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.

So, as you know, I have recently began teaching classes on Agile methodologies at quite a large organisation. And I wanted to share some of my feelings about this.

Some background:

So far, I have taught about 5 classes, all on the subject of Kanban, each to a group of about 20-40 people. These people work as IT delivery outwardly to the rest of their organisation. They are unsurprisingly overworked, and receive more requests then they can realistically deal with, all of which are HIGHEST priority… So, all in all, a completely typical IT teams.

Before I started, I assisted in a 2 half day classes with someone who had been doing this for a while. (The best possible thing I could have done!)

My first class:

The first day of standing up there was absolutely terrifying, at least right up until the point I started speaking. Also, a side note, I woke up sick as a dog that day and really never should have left the apartment, let alone stood up and spoke for 8 hours.

So, as I said, I was extremely nervous in all the time leading up to this day. I was barely able to sleep for several days before hand. I tried practicing by myself in a room about 20 times, and I can tell you that this only served to make me more nervous.

However, the night before I practiced on my girlfriend, which went a long way to making me feel better. The problem with working alone in a room was, I got no feedback from participants and nothing to work from, so, I was basically trying to read a prepared speech for 4 hours’ worth of class, and every time I stumbled was completely devastating, because it seemed so huge without anyone there.

When I started to practice with an audience, I suddenly had engagement to work off of, and that made a major difference. I felt more like an expert, and was able to tailor my approach to meet the needs of the people I was speaking with (in this case, 1 person) So, when the day came, I was terrified right up until I started speaking and then it all dissolved. I realized very quickly that I did indeed know what I was talking about, and the audience was engaged enough to help me find discussion points whenever I ran dry.

My second class:

Each class was broken in to 1/2 day segments, so when I say 2nd class I mean part 2.

On the second class, I went completely the other way, I did very little preparation and decided to let the classes questions drive the discussion more (they had been using the stuff from the first class for about a week, so they had a lot of questions.) While I feel these were also successful, they were less so… I think I needed a little more “go to” material to bring a bit of order to the discussions. These discussions tended to get off topic, and felt less professional.

The conclusion:

Prepare a lot, but not too much!

Remember that you are indeed an expert in your area, and will be able to deal with the unexpected.

When you need to stall to think, ask the class a question 😉

Now the important part!

The reward:

The first reward was simply pulling off the class, realizing it went well.

But after that came the real reward, seeing that you got through to some people. I should be clear, the majority of people you spoke with, most likely went back to doing exactly what they were doing before. But there were a few people in every class who you could see you really reached, and that was a amazing feeling! To feel you inspired someone, and maybe made a small difference in the world was one of the nicest feelings I have ever had. I can only imagine how it feels for school teachers to see!

I love doing this work, and apparently I am fairly good at it, the classes gave me an average score of 5.2/6 which is apparently extremely high.

It is extremely exhausting, to attempting to make 20-40 people enthusiastic and engaged, and is often times terrifying, but also the most rewarding work I have ever done.

I suggest you all try it; I personally can’t wait to get better at it!

As you probably have noticed over the years, I have a tendency to get really absorbed and fascinated with some of my hobbies during a time period.

Since I have limited time and focus available, a sort of Kanban-like system has evolved for this without me actually thinking about it – I can really only focus on three hobbies at the same time.

Right now, my three are:

League of Legends

Civilization 5

Skyrim

Past examples of these include previous versions of Civ, Starcraft 1 and 2 (both as a player and a spectator), a crappy Facebook game called War Metal:Tyrant, another crappy Facebook game called Farmville, Fallout, NBA basketball, Wrestling (the fake WWE-kind), Magic: The Gathering and various other card games and surprisingly enough, front-end development (the XHTML/CSS Web Standards days). Yes, a lot of games on that list – what can I say, I like games more than most people.

What’s more interesting though is that this list only includes the things I’ve perceived as major hobbies and time-drains over the years. There are obviously a lot of other things that have both taken up time and energy and given me great fun, that I haven’t thought of in terms of this system.

These fall into a couple of categories:

Family and friends.

These are in a class of their own, since the “system” is mostly for the part of my free time that is usually “Matte time”. It would be weird to think I’d have to bump a friend in order to have time for another. In reality though, this is probably closer to the truth than I would like to admit (just ask Jeff and Mark…).

Things that are too small to register.

Right now, that would be this blog, Puzzle Quest on the iPhone, reading books, reading magazines and playing board games.

Things that aren’t easily categorized as “hobbies”.

Ironically, this might be work items that bridges the gap between work and freetime (like reading work-related articles or improving a mostly work-related skill).

Here is the point:
Your Kanban or SCRUM board only holds what you think about and label as stories or tasks, which probably isn’t all activities that your team performs (like maintenance, meetings, bug fixing, software installation etc).

Everything else, you still need to have a plan for – either that part of your work automatically flows into your day and is part of your velocity, or you have to make it visible in some way so you can track it, manage it and improve it (always improve everything, right?).

Can you remember how we did this at Lavasoft? It seems like a blur to me now… 😉