Gå till innehåll


So it is 2013 and I am trying to figure out the next step on my trip of constant learning. Having thought about this a lot on my own I started to make a plan. I like planning. It helps me to focus. It´s like writing this blog – I have to structure my knowledge in order to make things readable and that is a learning experience in itself.

First Coaching Session

I managed to squeeze in an informal coaching session with friend and colleague as well as professional coach Mattias Nordin over a bottle of wine. “In vino veritas”. A very simplified version of our coaching session is the following conversation:

- So we meet in the French alps in three years – what are you up to these days?

- Well I am working with some Lean projects at the moment and try to do a lot of outdoor stuff like skiing. (vision)

- So how did you get to be where you are?

- Well I got myself a Lean mentor and read a lot of books and then started to participate in some Lean projects mostly managed by my mentor. (plan)

- So how was the first year (2013)?

- Well I found a mentor, read this list of books and worked in my first lean projects as an assistant. (Immediate action!)

A more thorough coaching with Mattias is typically six two-hour sessions. But this is a good start to get a feel for it and forces me to focus. If you have not had this type of talk with someone lately – give it a try. Maybe you have an HR-function at work, a boss or colleague skilled in this or find a coach like Mattias. It may change your future!

Searching for information

As you may have guessed from the title of the post, my plan is to go Lean. This may mean becoming a Lean coach or finding what lean can do for testing, I do not know yet. From what I have read about Lean so far there seem to be a lot of good stuff that may benefit me whatever I do in the future.

The world is flooded by Lean books – all describing their own interpretation of what it is all about. The origin is TPS – Toyota Production System - focused  on production lines in factories. However the Lean ideas are applied throughout the whole Toyota organization so there is a lot of good stuff even though I am not planning on working in a factory. The factory thing is a regular comment when discussing Lean according to my mentor so we will get back that question in a later post.

The first book I read on the subject was Lean SW development – how can Lean ideas be applied when building code. I think it has some interesting ideas but since it was a year since I read it I will not write any detailed analysis.

The next book I read was Kanban by David J Andersson. The focus here is maintenance – this is a more direct application of factory thinking. Focus is on getting a flow efficient organization that strives to go from input in the form of most serious problem right now to solved problem as fast as possible. The author´s point is that Kanban is really a way of transforming your organization to Lean.  The case stories are really impressive and he manages to convince me that Kanban as decribed in his book is really a good way of working with maintenance. He also points out that most Kanban-style organisations use parts of Scrum as well. I have heard someone interpret Kanban as – “we do not have to have any releases like in Scrum”. The truth is quite the opposite – in order to get good flow most organisations use frequent releases – only a fraction has taken the step to Continuous Deployment where every little change is deployed instantly to production.

Next book I read was The Lean Startup by Eric Ries. How can we be effective as entrepeneurs? How can we build companies and products in a Lean way? Most important message here is not to spend huge amounts of money before you know what a potential customer really wants. Really makes a point - too many try to create and implement pretty detailed and heavy processes, products etc without knowing what the intended user wants or needs.

Getting a Mentor

I have realized that in order to in order to succeed with my goal of really learning Lean I must understand the theory behind and practice in real projects. To keep me on the right track I need a mentor. That said, I recently joined the company Kvadrat and a colleague of mine, Anders Häggkvist, with many years of experience in Lean volunteered to be my mentor.  Next blog post will be on our first meeting.

Status of learning:

Books read on Lean:

1)Lean Startup: focused on how to handle a start-up with low cost until you know what to build, Like a prototyping handbook.

2)This is Lean: a great beginners book on the essence of Lean. Great book to hand out in an organisation to get everyone started

3)Scrum and Kanban - making the most of both: Kniberg

4)Lean SW Development: Poppendieck

5)50 nyanser av Lean: a bit thin and only available in Swedish. Has some important learnings on why Lean implementations fail and others succeed

Work done:

Worked as Scrum master in several projects

Created a quality assurance process for development with a distinct flavor of Lean

Was Project manager for implementation of continuous integration with special focus on my part for test automation.

Plan for the next month:

Blogg about my progress including the books I read and the following discussions

Read: The Toyota Way to Lean Leadership: Liker, Convis

Have meeting number two with mentor to discuss what I have read so far – next week.

Plan for the next year

Become a Certified Scrum Master

Read: discuss with mentor if I should read more books or work with the ones I read.

Work: participate in at least one Lean project, participate in Lean Box work (c)

This fall is full of exciting testing events. Gothenburg seems to be the center of testing hosting not only EuroSTAR but also another RST class with James Bach!

If you are a tester and feel that you need to get inspiration and learn about solving problems fast, I recommend taking the RST-class in November in Gothenburg. We have manged to get James Bach to do a class again. Read this blog post from a very satistfied student.

I have been in the SW industry for more than 17 years now and I still learn something new all the time. I realise I cannot know everything and because of that it is important to be able to learn new things fast when requried. It is equally important to understand how to think, analyse and solve problems in general. My goal is to constantly keep on learning in order to be consistently valuable for anyone that wants to have my services. Both because a find it thrilling to solve problems and in the end - I need a job!

Part of this plan is to participate in at least one new class every year. I does not have to be in Testing but in something I find useful in general. Last year I finally took the Effect-Managing IT class which was great.  The class before that was Corporate Story-Telling. I have taken the RST-class twice and learned something new also the second time.

If you are a tester and feel that you need to get inspiration and learn about solving problems fast, I recommend taking the RST-class in November in Gothenburg. We have manged to get James Bach to do a class again. Read this blog post from a very satistfied student.

A more specific testing problem is how to effectively manage Exploratory testing. You do not only have t be able to test but also to plan, analyse and continually make progress. How DO you plan and manage today? In Scrum we do retrospectives in order to get better. In ET we do debriefings in order to get better at testing. If you are a tester or a test manager and want to get a hands on experience with SBTM - Session Based Test Management - take a look at the SBTM Clincic we arrange with James in November in Stockholm

Hope to see you there!

A friend of mine is a software developer. He is of the passionate kind that really cares about the code he writes. I have the utmost respect for him. When he talks about coding, I listen. We had lunch the other day and he mentioned the book Clean Code by Uncle Bob Martin. In his opinion this should be mandatory reading for all developers. Since I am always hungry for valuable learning I ordered the book. I spent the last two days reading it. OK, I admit, I am not a developer and I have not written a lot of code but none the less I found it interesting.

Clean code is about how to be a professional developer. You can be great at coding stuff but it is different to be professional. The difference is that you do not only solve a problem but you solve with code that it easy to read for others which means maintainable. Interesting idea that comments should be avoided most of the time. The code should be so clear that it tells you what it does when you read through it. Good naming, simple functions, no duplication, indentations, clean unit tests as well. If you do not follow these practices your code will be a mess. Hard to read, lots of bugs, hard to update. In this view all automated tests is programming as well!

This leads me to the following conclusions: many people write code but few do it professionally. If you want to be a professional programmer – you have to practice hard and really want to become one. Constantly refactoring and writing tests takes a lot of effort, if you give up - the code will deteriorate fast. Automating testing is really an integrated part of development. Contrary to some popular belief, I don’t think you can just take any tester and assign them the task of automating the manual tests they are doing today, neither is it a good idea to ask them to write the unit tests. This is really writing code as well, and writing code professionally requires you to really want to write good code.

I work with a couple of really skilled developers at the moment. They know the technical stuff, they care about their code. When they tell us that they will not deliver new functions this week because they need to refactor and fix a lot of small bugs, we tester applaude! However I notice a lot that most developers have a hard time seeing the whole picture. They are very focused on solving the problems at hand and do it well technically. A nice user interface and the ability of seeing the whole picture is much lower priority than creating working code. Now I respect that, and they respect that we testers find a lot of bugs that they do not notice. I think it would be a really poor choice to make tester code and developers test more. The strength of our team is that we are good at different things. I really think the idea of everyone being able to do everything is a misunderstanding. I think it is very beneficial if developers can handle different types of coding and that testers can handle different types of testing. But that is not the same thing as everyone beeing a developer.

Both developers and testers need to become more professional. If I was a developer I would read Clean Code and do all the exercises and I would give a copy of that book to all my colleagues. Now I am a tester so I read the book to understand what developers go through. I also hand out copies of my own book on test design to members of my projects so they can understand testing better. I read about Lean, Kanban and Scrum so I understand what is happening in the agile world of today. I am really surprised and disappointed that most project managers don’t seem to care about that new stuff called Scrum when they are supposed to manage a Scrum project on some level. I learn about Effect mapping so I can help making the users happy.

Professional developers are the core of all software projects, but so are the testers. Without one or the other we will fail. Those who believe that all testing can be automated have totally missed the point, those who believe that automating testing is a waste of time have also missed the point. Both are needed but they have a very different focus. Manual testing can never make the code clean – only developers can do that using other techniques. Good manual testing will give invaluable information in order to make the application useful – help the user solve their problem!

And yes, I am really looking forward to our upcoming conferences this spring. SWET peer conference in March and Let’s test in May. The latter one open for the public. Let is discuss and bring software development one step further ahead towards real professionalism!

Notes from a context-driven tester

We call ourself context-driven testers. Since you are reading this we assume you like the ideas about rapid testing. Maybe you like to do test sessions on your own or in pairs. You feel that exploring a product is very effective for finding problems and you are really bothered by running test cases with detailed steps. At the same time there is a need to keep track of what you and your colleagues are doing without reverting to the old methods of counting test cases and bugs. No need to worry, there are plenty of ways to both plan, execute and report a more exploratory way of testing. It may be different from what you are used to but it is not harder.

Instead of obsessing about detailed test cases we try to find a better way of preparation. This may be in the form of a mind-map, a test charter or a list of test ideas. Most of the time we believe that the detailed procedures found in test cases are an obstacle for efficient testing. We don´t mind details – just the wrong details in the wrong place.

When executing tests we prefer to do it in sessions. This means that we sit down uninterrupted and focus totally on what we are doing. It is a bit exhausting at times but very rewarding and it is great to feel the flow! Best of all – it is fun!

As a test manager you are required to report status to the team and to your project manager. Instead of handing out detailed description of bug counts we rise a level and use the low-level dashboard. It has less detail but gives a better view of what is really going on. We count sessions but we also analyse them in detail in regular debriefings. We know very well what is going on! We feel more part of a team than a separate function. We practice explaining why a bug might be serious for a user and we work on building working relationships with developers.

This class presents some key elements for managing an exploratory team of testers. Regardless of you are a tester or a test manager – this is a golden opportunity of learning more about how to manage an efficient test team. Is presented to you by the man who has done the most thinking, discussing, writing and fighting on the subject the last 15 years.

Torbjörn Ryber, Fearless Consulting and Claremont AB.

Course application:
The fee is 11 900 SEK + VAT. (coffee and lunch included)
Apply to: Hanna Källgren, email hanna.kallgren@claremont.se
Latest by October 28, 2011