Gå till innehåll

Blogg

First meeting mentor-apprentice

We decided to spend some four hours together, including lunch. We ended up meeting at my home for practical reasons. We, that means my mentor Anders Häggkvist and myself. Anders has worked many years with processes and the last four years exclusively with Lean. In addition he is certified in Lean – something we will come back to in a later discussion. I think I will do an interview on that subject because I am really curious to what it has given him.

Anders started by asking me what I want I want from the sessions we have together, what are my goals? Now that is a good question to start with but something that is often forgotten when we build IT-systems, we do not really need functions – we need to achieve something and that may or may not be done best by building a function. Likewise I want to know about the true meaning of Lean – if there is one – and how to help organisations implement Lean- because I want to be able to do this on my own. Listing my own goals was one of the first things we did:

1. Learning the theory of Lean thinking

2. Understanding how Lean projects are done – examples from the real world

3. Participate actively in Lean projects as a complement to testing

Anders talking about Lean basics

There are many interpretations of Lean – many of them missing the essence of the philosophy behind. Many books are written that focus on the TPS, which is production of goods. A common first argument against Lean is “But our organization does not produce goods, how can Lean apply to us?” Well at Toyota, Lean is part of ALL work, not only the production of cars. That’s why you need to read the books about Lean Leadership Tobbe! The same principles apply regardless of what you do. We are going to dig into Lean for "service providers" but not so much for factory production.

One of the most important principles is go to gemba – go to the place where the work is done and see for yourself. You cannot make excellent decisions unless you truly understand the problem. We then discussed the problems many Swedish companies face when they are bought and become part of a much larger organization. Decisions start to made far away from where work actually happens. This is the opposite of Lean – instead of using the knowledge and competence of the local employees, managers far away make inferior decisions that are not accepted and thus employees leave. We see it happen over and over again.

For SW development one large problem is that we are too far away from the future users. If we are lucky there is some requirements analyst that is given access to some person that represent at least part of the future users. Then the analyst has to try to put all this knowledge in some – often formalized – documentation that testers and developers interpret and try to satisfy. No wonder we get unsatisfied users! Compare this to the “power of three” meeting where users, developers and testers together discuss what to build. Whenever we have these meetings continuously – the complaints during acceptance tests are almost non-existing. This is Lean – doing the right thing the first time, getting close to the end user.  Spending a day with your customer at work can be very revealing to what their problems really are.

We talked about effect-mapping (similar to impact mapping) and I showed the map I made for the current project. This is a lean tool! We often create it in a table format but the idea is the same. We use the five why to understand the root cause to a problem and also the real(root) needs of future users.

Time for a lunch break with fried Pike-perch (Gös), mashed potatoes and parmesan-ream made of sour cream, white wine and lots of cheese. We had to drink water instead of the rest of the Saint Clair since some of us had to drive and others pick children up at school. In both cases smelling of wine would be less than optimal.

Summing up our first meeting we created a...

Plan for the Near Future

1. Update my CV so that it clearly reflects the things that I have worked with and want to work with in the future. Highlight any Lean or management efforts so they do not drown in the sea of testing assignments I have done.  (Tobbe)

2. Read two books on Lean Leadership – starting with Lean Leadership: Liker, Convis(Tobbe)

3. Blogg about what I learn as an exercise of structuring my knowledge and to show the world that I am going Lean(Tobbe)

4. Participating in some Lean assignments during 2013. (Anders will look into opportunities)

Of the above I have updated my CV and written two blog posts. Now getting ready for next mentor meeting on Friday. Sprints are fairly short I say!

1

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!