Gå till innehåll

Second meeting with my mentor.


First question is of course - have we made progress on the tasks we put down in our plan?

Well I have reviewed my CV as well as my linkedIn profile and made sure they are both up to date and that the Lean and management work I have done is clearly stated. Besides that I have written two blog post on getting Lean.

Anders in turn has looked into the possibility for me to participate in som Lean project as soon as possible. One important part is the Lean Box approach that I will discuss more detailed later in this post. I am ready to do some, possibly unpaid work, in order to gain experience.

Why do Lean Implementations Fail

We started out with a discussion on Why Lean implementations fail. A key factor is the view on leadership. The tradition western leadership is hierarchical with more important boss telling less important boss what to do until we reach the simple worker that just do wothout reflecting on why. Sometimes reflecting but beeing told to shut up and work - that has happened to me personally. The Lean thought is quite different. Everybody in the organisation is expected to assume responsibility for what they do in order for the whole team to be as good as possible. So the individual has more responsiblity for Kaizen - continuous improvement.. However most bonuses given out is for the TEAM performing well. No focus on individual excellence at the cost of producing a worse result overall! You cannot really succeed with Lean in the long run if you do not take a look at leadership style and principles.

How do we convince people that Lean is superior? Well, show them tehere is another way of doing things and things can be so much better for them AND for the company. How? Start by doing a pilot and show that it works for real.

What is the Deal with 6 sigma?

I have read at least part of the book Toyota Way to Lean Leadership and noticed that Six Sigma was mentioned a lot of times. I had to ask Anders his thoughts on the matter. Six Sigma is a very detailed process that may work well to impove large, well used processes by analysing statistics on the usage. So most of the work we do is not that well defined, our processes vary a lot and we do not have thise huge amounts of data to analyse! So in most contexts that we work - Six Sigma will not work very well, however for some specific contexts it may work great! Anders mentioned an example with the production of wings for those huge windpowered energy works where larger wings tended to break. By analysing huge amounts of data on materials ised and production methods they were able to identify key factors for building durable wings. That said, most projects we work on have to do with changing the way we work entirely and Lean Box is a much better tool for that.

Lean Box Explained


Here is the short description - this fall I may be skilled anough to tell you a more detailed story.

1: introduction to Lean, getting acceptance from management, agreeing on where they want to go

2: insight/perception: understanding the meaning of Lean. One day lean game with tehory and practice

3. vision: doing value flow mapping for a few selected processes - not too much. From wish to delivery - how much of the time is value adding activities. how much is waste?

4. doing it: 6 weeks sprints. Working on getting a better value flow - reducing waste. Often icludes doing effect mapping

All over this we have the Lean leadership I mentioned before. Changing of attitude from management. Reallise that leadership is different but not in any way diminished in meaning. True Lean companies recognise leaders by their ablities to make individuals grow and thereby adding more value for the team effort.

Improvements must come from the organisationion itself. ALL efforts to impose models on peopel that are not part of the process will inevitably FAIL!

After this coaching session I feel really good. I feel that Anders wants to be a good leader and that a very important task for him is to help me improve!

Also, a lot of the things we talk about I know already and am pretty good at as well (first I wrote God, I am good but not that good :-). I have worked a lot with the mapping of work processes - a large part of value-flow mapping. I love effect mapping - important part of stage 4: doing it.

I have good hopes that I will add value and learn a lot about Lean this coming year.

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!


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)

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!

Have you taken the RST class previously and feel that it is time for the next step? Rapid Test Management
is the class you are looking for. James Bach is back in Sweden again!

There will be two chances for you to participate:

7-8 Nov: in Stockholm, arranged by Fearless Consulting and Claremont in cooperation. The fee is 11 900 SEK + VAT. Apply to Hanna Källgren hanna.kallgren@claremont.se before October 28, 2011

10-11 Nov: in Gothenburg, arranged by Qamcom. Please contact magnus.kilian at qamcom.se for additional information.

The following is James Bach´s own description:

Rapid Test Management is about how to effectively manage a test project under time pressure and conditions of uncertainty. Based on the rapid software testing methodology developed by James Bach, and building on the Rapid Testing class, this class answers the questions managers frequently ask about how to run a rapid testing effort.

A prerequisite for this class is Rapid Software Testing. Those who've taken that class know what to expect from this: a socratic,
free-wheeling exploration of the material that will challenge your thinking.

In this seminar, we will examine:

- Activity-Based Test Management: Session-Based and Thread-Based
(instead of obsessing over test cases)
- Test Estimation: Factors and Heuristics
- Testing Metrics: The Bad, The Ugly, and the Fairly Presentable
- Testing Dashboard: Status Reporting without Pseudo-Science
- Risk-Based Test Strategy: The Heuristic Approach
- Developer Relations: Playing a Supporting Role, Advocating for Testability
- Bug Triage: Making the Case for a Fix
- Developing Your Test Team: Hiring, Coaching, Troubleshooting