Skip to main content

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 (https://www.mindmup.com/) 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.

Yes. 

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ä).

Comments

Popular posts from this blog

Periodical retrospectives are lame

  "You got nothing, not a single thing?! Well lets just end this here then." I remember well when I said this, being very frustrated. About ten years ago I had been working as a Scrum master for a team some months, and putting quite a lot of effort into planning our scrum teams sprint retrospectives. Lot of work also because I felt we were not getting too much out from them; not very good discussions, very few actions, and even the few actions we did come up with did not stick.  And then it happened: a retro where none of the participants came up with anything to say about the sprint. Regardless of the retro topic boxes, reading of books on retrospectives, getting inspiration from tools like retromat.org, having them in different places, using all kinds of different formats and rainbow coloured post-it notes. Not a single thing. Blank.  So then I said the words, out of frustration, mainly to myself. Why couldn't I get this thing everyone is so hyped about to work? After t

I don't report bugs

I don't report bugs . Bug is such a loaded word that people understand very differently, that instead of using it and explaining what I mean by it I rather just use other words. Like observations, thoughts, surprises, ideas, alternatives, or something similar. (And no I don't use fault, defect, or error either). Bug has also quite a negative connotation. "Reporting a bug" is kind of like telling someone that they've been served. And as we are actually giving away the gift of information, why wrap it in such a nasty package? And maybe more importantly it is very likely that whatever you might have to say is wrong. If not plain wrong, then at least incomplete. So I like to approach the kind of situations with the assumption that I am probably wrong. Cutting off anything that might sound arrogant makes stuff quite a lot easier. Especially after you realise later on that you have been wrong. I leave plenty of observations unreported . I don't want to waste

Testing drunk

(My first blog writing ever.) I've been thinking a long time that it's funny how many bugs I find by accident. Try to do something, make a mistake and boom - a bug is found.  Making the mistakes intentionally doesn't quite work - that's why they are called accidents I guess.. So I've thought of ways to make myself more prone to accidents, coming up with an apparent one; testing drunk. TUI (testing under the influence). So this I gotta try. More to come on that later.