Monday, April 16, 2018

10x tools #1: the Kipling method

This time I'll start another series of posts (which I will not probably finish) called 

10x tools for 10x tester

which is a little bit modified version of a talk I've given a couple of times. 

The initial talk was demoing 10 tools from a wide range of categories that I use to increase my efficiency, in 30 minutes. Which is super duper fast. It was actually quite funny, because with this talk I first sent the proposal thinking that 3 minutes per tool is more than enough. But then after the talk was accepted and I started rehearsing and did in my opinion a really quick demo of the first tool, I was quite surprised to see the clock stop at 8 minutes. So I really had to cut everything extra away from the demos, and even skip demoing a couple of tools I originally wanted to. So now for the blog version I might demonstrate a bit different tools. 

But definitely 10.

And definitely 10x.

And the first one is the same as it was in the talk, called the Kipling method and combined with MindMup.

MindMup ( is a nice online mind mapping tool. It's free, enables collaboration on a shared map, and is constantly getting better too. But collaboration is the key here because the Kipling method is about planning, and good planning is all about collaboration.

So the Kipling method can be applied when you have something you would want to plan a bit. Could be a problem, a request, a project, a testing task, a family vacation, or whatever basically. And when using it with MindMup, you start by writing the task into the center, and then start asking Why.

Why would you want to do this? What problem would it solve? Why this solution and not something else?

These questions are crucial. These questions can save you days or even weeks of time spent on doing something that is not needed. And these questions raise beautiful discussions. 

Sometimes this is actually as far as you get, as you might here notice that you do not know enough of the reasons behind the task, you don't get the business value, or you just plain disagree. And that is one hell of a good planning session you just had. 

But if you kind of can agree on the why, you continue to the What.

What are the impacts you would want to achieve with this? What other impacts might happen? How would you know if that impact will be reached?

This will help deepening the understanding, but also starting to think about the things and problems that the solution should solve. Can't come up with any? Or only something very vague and something you cannot verify afterwards? Impacts don't match with the reasons you came up on the why? Better go back and talk more to some stakeholders.

But if you can come up with impacts too, then you can proceed to How.

So here we can start thinking of how can we actually solve the problem. Doesn't have to get too specific here, details will come out later, but rather consider all the different ways the problem could be solved. How could you do it without any coding? What different kind of architectures could be used? What different kind of UI's you could think of?

It would be important to come up with at least couple of different alternative approaches, which could then maybe be combined. Or you might decide on the most probable or easy solution. Or go crazy and do a prototype on something totally strange. As long as those would somehow relate to the impacts discussed before.

Ok so you got this far now, and you might wantto end it now. But continue for a moment still to briefly consider other needs and limitations,

Who do you need to get this done? Who would help you in this? Who are you afraid of :D

Where can this be done? Do we have the environments and tools? 

When should this be ready? Do we have some hard deadlines? Are those deadlines based on facts? When would we start getting value out of this.

And now you are done! And you have this beautiful mindmap! 

That you can toss away.


Because the plan is useless, but the planning is everything (smart words of D.D.Eisenhower). 

The power of the planning comes from having many people discussing stuff together, bringing in different views, ideas, critique. And going off with shared understanding. You do not really the plan anymore, as you have the understanding. It's magnificent :)

So the Kipling method is a simple planning framework, and a mindmup is a nice tool to do this quickly on. And this kicks the shit out of any project plan template ever created. 

Oh yeah, you might wonder why do I call it the Kipling method? It comes from a poem from Rudyard Kipling called Elephant's Child, which starts like this:

I KEEP six honest serving-men
 (They taught me all I knew);
Their names are What and Why and When 
 And How and Where and Who 

alas, the Kipling method (™Anssi Lehtelä).

Sunday, April 1, 2018

Nothing helps you more than helping others

This week I dived into the drafts folder of my blog posts. There were many interesting titles that I would want to write on, like for example one with title "The crying game". It had no content and I have no idea what I have thought of when writing that down in the year 2013. But what a great title!

But this other one that I'm now writing on had some content and is a pretty dear idea for me, so I'll now finish this post I started back year 2012. And that is, that nothing helps you more than helping others.

I have had this principle for a long time now that whenever someone asks for help, that I always do. Even if I'm swamped with work and in the middle of something and someone interrupts to ask if I could help I'll reply "of course!". Some might argue that asking to come back in an hour would be better, but the bad side on that is that potentially this other person is then stuck for an hour - and this is one hour lost. As opposed to helping them out immediately, everybody can go back and continue on full force.

So I think always helping others out is a good way for the efficiency of the team. And even for you, as if you help others then it is more likely that you will also be helped when you have a problem.

My wife was saying to me while discussing this, that sometimes some people might not want to help because they think keeping some knowledge to them self could be considered an advantage. Kind of like a superpower that other's don't have. I replied that I can maybe see someone thinking like that, but I think that not helping is still more of an disadvantage even for the person holding the information. Because good ideas can always get better and a great way to improve them is to share them and let others offer their own in return. Things I thought were pretty darn good already have gotten a lot better when I have shared them to others, by them offering their criticism and ideas in return.

So helping out improves also the ideas and knowledge you have.

And then there's the humanity factor.

I was a few years ago collecting money for Unicef with my son. Me and him (four years old back then), were standing on the center of Helsinki with a small box where we were asking people to donate some coins for the sake of poor people in Africa. I was quite sure that the box would get filled up in like minutes, the cause being so good and my son being pretty cute with an over sized Unicef vest almost touching the ground - but people were just walking on by. Hundreds of people just walking on by.

I was many times on the verge of losing my faith to the humanity, but then someone came, and dropped a few coins with a smile. And it rose us so much. It didn't even matter was it 2, 1, or .10 euros, just the fact of someone took the time to notice and give out something meant so much.

So these times when I see people collecting money for a good cause, I always give something. Like 10 cents. Because I know how much it means for the people who are giving out their own time for free, in order to help others.

So even in the context of the whole planet and human race, nothing helps us more than helping others.

I'll just close this one with a link to one of my favorite Beatles songs, you may guess what it is :)

Sunday, March 18, 2018

Retro for the past week

Keeping up to the deal with my colleague Mili for the total 52 posts during year 2018, this is my sixth one (Mili blogs here  I am not really in the mood of finishing any of my draft versions and do not have solid things on my mind that I would want to write about. So I thought to do a little retro of my past week, with the classic glad - sad - mad pattern. (nice machine to help coming up with other ideas to retro's here btw).

Here goes:

  • personal retro week 11
    • Sad
      • Had to spend very much time on solving issues and questions coming from support and stakeholders
      • A lot of people away from office this week
      • Meal on the lunch on new restaurant sucked
      • Few things on "my own backlog" stuck the whole week
      • Lost a query to a report I did couple of months ago
        that was asked from me again, need to redo
      • Could not do the mob programming sessions I had booked
      • Another problem with Git (root cause was that I had wrong branch as base)
    • Mad
    • Glad
      • Was able to squeeze in a few hours doing some programming on improving an existing feature
      • Tried one new restaurant for lunch
      • We were able to get quite a lot further with the goals in the workgroup I'm in
      • Was able to test and provide some feedback on some things done quite quickly after done by dev
      • Sent out a team stakeholder satisfaction survey, and got high grades on it
      • Came up with a maybe funny idea on a presentation I will give in two weeks
      • Survived one very hard meeting, and got good advice after it from my team members
      • Got help on a git issue once again
      • Tried kanbabflow as a kanbanboard for a workgroup I am in, so far like it
      • Got help from a team member to understand the reason why another one was maybe upset
      • Nice interactions with our support team
      • ( copying the mind map and pasting it as text comes out as a really nice bulleted list. And also the productivity beta version works nicely

Then a few possible action items for next week:
  • Arrange a meeting for showing how I regularly work with support support (with some example case), invite the whole team (or maybe two meetings people split to two) as optional in case someone would like to help there a bit
  • Push some of the things from my "own" backlog for the team to look at
  • Book new mob sessions
  • Start saving the queries I use more often to the useful queries file I have in git 
  • Choose some implementation task for next week too
  • Book a retro for our work group til the end of next week.

That was fun! And I feel a lot better from the past week, and looking forward to the new one :)

Sunday, March 4, 2018

Testers doing test automation - is that the most important thing for you to do right now?

I've been thinking quite a lot about tester's moving to do test automation.  Lately beause of these three things:

1. European testing conference, a great testing conference I attended couple of weeks ago. It is very cool due to many things; the way the speakers get compensated, the focus on the conferring side of conferences making it very easy for people to discuss stuff, the way the talks are chosen, and because there are also a lot of developers joining. So anyway when I was talking with several of the attendees, it was a bit strange how it was easier for me to talk about the product development as a whole with the developers, where as with the testers it more naturally moved into talk of automation and tools. Also on the open space, I think the majority of the topics pitched was automation or tool related. And quite little on the process or on the customer facing side of product development.

 2. In my company there are a lot of different products and product teams, and in an attempt to share some knowledge between the teams there are different guilds. Like devops guild, architecture guild, API guild, and a testing guild. So usually when the testing guild meets there are mainly testers from different teams participating, and a topic is introduced by someone with a little bit of followup discussion. And the three of the last four topics introduced have been quite automation/tool centric. (And the non automatic centric one was my topic)

3. This week I read a linkedin post from an old colleague titled Runnable Specifications are here, never speak about test cases anymore. In it he made several good arguments against the-step-by-step-testcase-execution by a tester and offered the role of executable specification writer in return. So kind of shifting left and doing automation.

So I don't have anything against test automation (well I do make a case against stupid automation but anything stupid is stupid so that don't really count), but I do have a little trouble understanding why so many testers think that's what they should be doing now. I mean, I do not try to argue that anybody should write and maintain test cases and then "execute" them manually. But that the only alternative to this is for the tester to automate those test cases? I don't buy it.

First of all, I'd say that most commonly there are a lot less "testers" than there are "programmers" on a product development team. And I'd say that commonly the people identified as "testers" are not as good in programming as the ones who have identified as "programmers". So I think the heavy lifting of test automation (which is also programming) should be done by people who know programming. Because they can, you know, program. And if they do test automation they might make the app more testable in the first place. And they also know how stuff works so that they can automate the tests faster. And if the same people work on the code and the test automation it ain't as likely to create bottlenecks and missing automation. And if it is ok already that programmers handle the unit and often also the integration level test writing - what is so different on the end to end level? Testing expertise comes in handy here of course, as testers might be better at providing stronger assertions, better test data, better test scenarios, etc. So teaming up might be a really nice idea (it almost always is ;) ). But who-does-what should be based on motivation and skills - not based on some label.

Secondly, when thinking of the biggest problems any of the products I have ever worked with, those would not have been prevented with more test automation. Many things might have been easier, sure. And many bugs would have been caught earlier, I believe. But the biggest problems? No. And this leads to a crazy statement.

There is more to product development than programming and testing.

I don't want to diss programming. It is an art. An art I ain't really good at (at least yet). But there's other stuff. There are alternatives to brainless test execution by person, or making the brainless test execution to be done automatically. I'll mention a few

Product management. This is what makes or breaks the product. A good idea done shitty, might give people value. But a shitty idea done in the most beautiful way with beautiful automated tests is still a shitty idea. It is like an ass made of silver - it's shiny but it's useless. So this is a place where we would need more emphasis! More brains to engage on making sure we pick the right stuff to do, that we focus on impacts, that we focus on not doing too much, that we pick the right level to prototype, that we do not overcommit too early, that we do stuff that is of value. And this is not the responsibility of a "product manager". It is the responsibility of everyone in the product team! And this requires work.

Stakeholder involvement and communication. If I would pick one thing that has caused most problems in all the stuff that I have been working on, it has been the lack of communication. Within team yes, but especially between the team and it's various stakeholders. We need people that not only consider what stakeholders need and want, but people that actually do the work of discussing, asking, asking again, demoing, listening, telling, managing expectations, with the stakeholders. Sales, marketing, support, customers, end users, integration partners, and who ever it is that has an interest on your product. They need to be heard, they need to know what's happening. And the team needs to do this. And this requires work.

Planning. We need people to make sure we are planning ahead - not too much! But not too little. Making sure we have an idea on the vision, that we think we know the next couple of steps, and a bit of the risks and alternatives. And that the team has always a shared understanding of what we are going to do. And creating this ain't easy. It requires work.

Process. It is easy to settle, continuous improvement is not. It is easy to agree to stupid procedures given, it is not easy to explain why you need to do differently. It is easy to believe that everyone is happy, it is hard to know if they are. It is easy to create silos, it is hard to break them. And it is easy to fallback to routine, it is hard to really start doing something in a different way. This requires work.

Monitoring and analysis. What is your definition of done? Acceptance tests pass? Documented and released to prod? That is not done, that is the start. Actually following what is happening in production, analyzing usage, digging for problems, thinking of improvement and making sure improvements get done is a super important part of product development. And it requires work.

Exploratory testing. Being there constantly looking for problems, looking for alternative ideas and things we did not think of, providing constant feedback to the team, and learning the whole product. It. Requires. Work.   

And a lot of other stuff.

Again, I don't want to say that (test) automation is not important. Hell, I would like to do more of programming myself too, because it is fun! And I guess it is easier to add that to employment adds and CVs. But there are also other things that a product development team needs to do.

So the next time you start writing those automated tests, I want you to think - is this the most important thing to do right now.  

Sunday, February 18, 2018

Mob programming - the heaven of a tester. Part2: What happens in a mob

This post continues from Mob programming - the heaven of a tester. Part1: the beginning.

I will next describe the formula of a rather common and a rather good mob development session. It consists of four parts; The initiation, The planning, The implementation, and The finishing.


1. Initiation

We started arranging the mobbing sessions by booking a few 2 hour slots for the week ahead where our aim would be to do some work in a mob. This was especially important in the beginning as the mobs did not seem to happen adhoc. Even if pretty much everyone always liked and wanted the mobs, people often did not arrange them by themselves. So this kind of forced us to do the stuff we like to do :)

Now after starting to make mobbing a habit, and starting to understand where it is especially effective, we have gotten better in initiating mob sessions ad-hoc. So these days it is the most common way to start implementing a solution for problems that seem hard to tackle, on something that is totally new, or on anything that appears to be big. Also we have started using the mob as a way to end arguments in a nice way. Like after arguing/discussing something too long in a meeting or in a flowdock thread, someone just suggests to mob it and then we go.

2. Planning

We most commonly start a session by drawing a picture of the thing we are trying to accomplish. If working on the same location we use a whiteboard, if remotely we use some simple paint tool. (Lately couple of our devs have been trying out using a iPad for easier drawing and it looks really nifty. But not much experience on that yet.) So someone graps the pen, and starts drawing the parts of what we are about to change. Simple drawing displaying the user interactions and the main components and their interactions in the scenario we are thinking of. Then we switch to a pen of another color and start drawing the new parts needed. And finally we decide which parts of those are kind of separate tasks and decide on the initial order in which to implement them.

Example result from whiteboard planning

Here it is often important to try to notice when you are starting to overplan on the whiteboard. The aim should not be to fully think of all the details, but to have a goal to start moving towards to. The details will get solved while implementing, and the goal might as well change while at it. You can keep in mind the phrase from Woody Zuill: "it's in the doing of the work that we discover the work we must do".

3. Implementation

In the beginning of our mobbing days we used to switch the person on the keyboard quite often, like every 7 minutes. But these days we often may just pick a person who will do all the writing during the whole session. I don't see a problem with this, as long as that person does not start writing something that has not already been discussed.

On the keyboard we usually (should run the existing tests, which we often forget, and instead move directly into) start by writing the tests, which is a smooth continual from the planning. We usually like to start with the user facing parts as there we really need to think of the inputs and outputs of the whole flow. This is hard, but usually leads to a smaller first increment than what you would get by e.g. starting the implementation from the db model.

Then after the tests are done (try to not write too many first - remember overplanning!) the writing of the actual code may be the easiest part of the session, partly because the hard business problems are already discussed thoroughly, and partly as there are so many capable coders present who know all the tricks. So we do not spend THAT much time in google...

4. Finishing a session

Our mob sessions last usually about 2 hours, and we would not do more than two of these a day. Mobbing is effective but also quite mentally consuming so doing too much of that may take its toll too.

So after the 2 hours are up we (commit and push if we haven't before which too often might be the case, and) agree on how to continue with the remaining tasks. If everything seem to be clear one person might just pick it up from there onwards. We might also agree that someone continues on their own on some stuff and then books a mob on the next more challenging things. Or then we may just agree to continue with the same people the next day.


There it is, the formula of a normal mob. "Why we like them so much and find them so effective" and "what is the testers role in a mob" I will go through on the next post on the series of Mob programming, the heaven of a tester.

Now I should go and book a few mobs. Recommend you do the same!