Markus Gärtner: Hi Johan, could you please introduce yourself? Who are you? What do you do for work?
Johan Jonasson: I work as a test consultant, coach and trainer at House of Test, a multi-national company that offers context-driven consulting, training and outsourcing services throughout Scandinavia. I’m also engaged in different global and local community initiatives, like AST, EAST and SWET, which has lately resulted in me becoming involved in the community lead Let’s Test conference on context-driven testing. I’m passionate about both gaining and spreading knowledge about testing and so try to spend as much time as I can advocating a growth mindset among testers.

Markus Gärtner: Out-sourcing of context-driven testing? How do you do that? Do you have to convince clients about your services?
Johan Jonasson: The way you present and provide a context-driven service doesn’t really change that much if you do it as outsourcing compared to on-site work. We offer a flexible and adaptable outsourcing solution that is free from pre-packaged “best practices”. Instead we look at the specific problem the client needs to solve and we tailor the entire solution, after that problem. The goal is to give the client what they need, and figure out what that need is in close collaboration with the client, not sell them a standard “one-size-fits-all” bogus solution. It means doing a bit more work up front, but we believe the pay off for the client is much greater than with non-context-driven outsourcing.

Markus Gärtner: How have you crossed the path of context-driven testing?
Johan Jonasson: I first came into contact with the community in 2007, when I first met James Bach and attended his Rapid Software Testing class. About a year later, I founded House of Test and joined the Association for Software Testing to be able to learn more about context-driven testing. Today I try to help the community grow in Europe, through conferences and workshops and also by helping out with the AST’s BBST training program as an assistant instructor.

Markus Gärtner: How do you apply context-driven testing at your workplace?
Johan Jonasson: One of the principles of the context-driven school is that people, working together, are the most important part of any project’s context. This is something I always try to emphasize wherever I work. I always go to great lengths trying to promote effective communication and collaboration in the workplace, because I believe that when people stop communicating, it’s only a matter of time before the project breaks down. Also, I’m not a big fan of trying to predict the future to any greater extent than maybe the coming few days. Being context-driven is about doing the best we can with what we get, and by working together in a project and staying flexible to change so that we can better counter the unknown unknowns or whatever other curve balls our surroundings choose to throw at us.

Markus Gärtner: How do you promote communication and collaboration? One of the biggest struggles in the testing world I see, is that testers should be kept separated, maybe even locked away from the rest of the development team. What is your answer to such claims?
Johan Jonasson: That’s one of the ideas I try to abolish as part of my promoting communication and collaboration. I don’t buy the argument about how separation of testers and programmers should help testers do more “bias free” blackbox testing. We have a ton of biases that we carry with us anyway that we need to become aware of and deal with and I don’t (personally) see insight into the inner workings of a product to be a very problematic bias, unless you have a strong tendency for confirmation bias to begin with, but then there’s your problem right there.

I think that isolating any part of a development teams is generally speaking a bad idea. I don’t believe that information silos lead to any advantages for anybody in the long run and it certainly impacts the value I can provide as a tester if I’m kept in the dark or separated from programmers, architects or business analysts. Getting to know more about a product by communicating with the rest of the team or with the customer is crucial for me in order to craft a proper testing strategy for myself. Take for example the Heuristic Test Strategy Model which encourages testers to (aside from considering quality criteria) become aware of a wide range of factors in the project environment as well as numerous product elements in order to select appropriate methods, approaches and techniques to test the product both efficiently and effectively. I think that makes much more sense than separating certain people from the information.

Markus Gärtner: What are the challenges you see in Europe’s testing culture? What are your replies to these challenges?
Johan Jonasson: I think one of the major challenges is that we’ve been focusing too long on planning, prediction, measuring, coverage and control as the only way of “assuring” quality. Testers in Europe have also been predisposed to only do “checking” for the longest time, with a high emphasis on confirming existing beliefs and explicit requirement rather than focusing on discovery and experimentation in their testing. In other words, the European testing culture has been dominated by only asking questions like “Does this function do what I expect it to do?” instead of asking more questions like “What happens if I do this?”.

Testers have slowly started to come around to a more deliberate way of critiquing the products they test, rather than just verifying that they work as designed, but there’s still a long way to go. I think we need to encourage more creativity and curiosity in the way we work, or we’ll risk ending up in a situation where we as testers produce no more value than an automated script, and projects where “Black Swans” can roam freely and destroy entire development projects.

One of my replies to these challenges is to encourage human testers to do more heuristic based testing, and work more with high level test ideas rather than detailed test cases. This allows for the occasional serendipitous discovery of impossible to predict bugs which, if left undiscovered, can kill a product in the marketplace.

Markus Gärtner: Consider time-travelling being possible today. What would you change in the history of software testing, if you could?
Johan Jonasson: If time-travelling was possible, I’d probably travel forward and not backwards, because I’d like to see what “comes next” for us all. But if I were to travel back (and if I could convince myself to limit my tinkering to only software testing history…), I’d try to make sure more testers learned about the works of e.g. Jerry Weinberg and Cem Kaner at a much earlier point in time. I’d try to not touch too much else, or I’d probably risk causing too much “positive damage” to the present. Or maybe I’ll just add some awareness of the difference between exploring and verifying too, and abolish the idea that testing doesn’t require any skill, and… No, that’s it. Better to quit while you’re ahead. :-)

Markus Gärtner: Imagine the world in 20 years. What has happened to software testing
that will make us pursue this craft for the next two decades?
Johan Jonasson: I think testers are heading for a bright future, but we’ll lose a few people on the way going there, but that’s actually ok. The reason is that so much testing being done today is really fake testing, and that needs to stop. Fake testing can be done in many ways, but it’s almost always recognizable by its obvious lack of conscious thought or drive. It’s testing done as painting by numbers, going through the motions, all handed down scripts and no creativity. It’s what’s been called “ceremonious testing” by James Bach, or “the testing theater” by Ben Kelly. I believe we’ll see less of this in the future. That probably means we’ll see fewer testers, too, because quite frankly, testing requires a growth mindset in order for testers to keep up with the evolution of software development, and unfortunately that doesn’t seem to strike a chord with all testers in the industry today.

I’m not saying that all testers need to learn how to code, because I don’t think they do. But I’m saying that all testers need to at least read a book on software testing, any book really, or some blogs, or a few articles. And I think they need to share those experiences, and their experience from their day to day work, with other testers and learn from each other. And last but not least, I think this should be the first thing a junior tester gets encouraged to do in their career, not study for a multiple-choice test in order to get yet another piece of paper saying they’ve passed an exam.

Too few testers today seem eager to learn and develop existing or new skills and so they will probably be left behind as the people who pay for testing services become more informed. Right now, we often seem to be in a situation that Scott Barber has described as “The under-informed, leading the under-trained, to do the irrelevant.” and I want to encourage testers to eliminate that as the status quo.

So are the people who pay money for testing services becoming more informed? I have seen some evidence of that, yes, but it’s not happening fast enough. That’s why I think community driven initiatives in the testing industry, like the peer workshops that we’ve started to adopt all over Europe, are so incredibly important. The community needs to come together and through discussion and debate forge the tools needed to explain to big businesses why software testing is worth doing well, and to spread that message far and wide. Otherwise, we’ll be stuck competing for the spotlight with people advocating for more fake testing that “anybody can do, and that’s why it’s so cheap”. Also, scores of potentially pretty good testers will continue to view testing as nothing more than a stepping stone towards getting a more “qualified” software development gig, and so they never bother to learn what real testing looks like, and they will carefully stay away from anything that might “infect them” with some passion for software testing, which makes it even less likely that they’ll stick around and help develop the craft. In 20 years, we will have hopefully broken this cycle, or the cycle will have broken us. Either way, I think it’s in our power to decide which future we want to see.

Markus Gärtner: What will happen after Let’s Test? What do you plan to take away from it?
Johan Jonasson: After Let’s Test 2012 we’ll start planning for Let’s Test 2013! The response from the testing community has been great and we have high expectations that this will be a really great and unique event that we can continue to build upon and improve for years to come. I’m hoping to take away many great learnings and experiences that are shared by all the awesome testers, both speakers and attendees, who are flying in from all over Europe and the rest of the world that I’ll meet at the conference. I’m hoping that people who come to the conference will go home feeling energized and ready to either seek out some of the great local context-driven communities that exist all around Europe, or start new ones where they don’t already exist. Finally, I also hope of course that we’ll all leave Let’s Test having made many new friends that we can continue to share experiences and debate new ideas with even after the conference ends. Another really cool thing with meeting places like this is that you get to meet people that you’ve maybe previously only known through their Twitter feed or blog, and looking at the list of people who’ve already registered and the list of speakers, Let’s Test will surely give people that opportunity, too.

Markus Gärtner: One final question: If you knew one year in the past what you knew
today, would you still (or again?) organize a conference like Let’s Test?
Johan Jonasson: Yes, without a doubt. It’s a lot of work for sure, but it’s really a privilege to be able to be involved in a thing like this, and to be part of all the discussions and see the positive reactions from the community. It’s well worth it.

Markus Gärtner: Thanks for your time, Johan. I look forward meeting up with you at Let’s Test, and meeting all the other context-driven folks there.

• 23rd March: TestBash in Cambridge
• 1st-28th April: BBST Foundations (online)
• 16th-17th April: ScanDev in Göteborg
• 18th April: JAX in Mainz
• 7th-9th May: Let’s Test in Stockholm
• 10th May: Karlsruher Entwicklertag
• 23rd-25th May: Testing in Scrum in München, a public three day course that I am offering
• 3rd-30th June: BBST Bug Advocacy (online)
• 14th-15th July: Test Coach Camp in San Jose, CA
• 16th-18th July: CAST 2012 in San Jose, CA
• 24th-28th July: Rapid Testing Intensive (most probably online)
• 2nd-4th August: SoCraTes in Rückersbach
• 10th-27th October: BBST Instructor Course (online)
• 17th-19th October: Testing in Scrum in Hamburg, a public three day course that I am offering
• 19th-22th November: Agile Testing Days in Potsdam
• 29th November – 1st December: XP Days Germany in Hamburg

Phew. Quite a list. There are a few dates missing, but I will wait to get confirmation on them before making them public.

In between, I hope to see the relese of my book “ATDD by Example”. I just found out yesterday that Amazon.com put up the publishing dates as the 9th of June. But I am a bit skeptical about that.

Mentoring

Mentoring consists of a mentee and a mentor, and a topic on which the mentee gets mentored. While this sounds like a bogus statement, I have found this mentor – mentee model in different places – sometimes with some kind of drawbacks.

In the Miagi-Do school we work with mentors. Well, after you found us, you usually need to pursue a challenge. An instructor will pass you a challenge, and then work you through it, eventually debriefing afterwards as well, and reflecting on your course of action. If you decide to stay with the school, you become a member of our group, and are encouraged to find a mentor if you want to follow up on higher levels. A few years back I was the instructor of Michael Larsen which really knew where his next challenges were, and I myself found a mentor in Matt Heusser through whom I eventually became an author.

But there are also other places you can look out for mentors. Some are offering free coaching on Skype, other might want to be contacted first. The most amazing place I was able to find mentors is my current workplace.

We have a mentor and apprentice model. You can basically pick any mentor for any topic that interests you, and you want to pursuit. Of course the mentor has to take on the additional time for mentoring you. That said, we have developers picking a more senior programmer to extend their skills, or they pick up a consultant in order to master their skills in this direction. Some of my colleagues are more interested in technical topics, others want to dig deeper on soft skills. There is virtually no boundary, as a senior consultant may also decide to be mentored by a programmer. Some of my colleagues even have three to four mentors at the same time.

One thing I found out over the course of the past years. When it comes to mentoring, it’s crucial that you pick your own mentor by yourself. First of all your intrinsic motivation will be higher to work with the one mentor that you picked. Another advantage is, that you can talk to your mentor about his contract with you, what the areas are, besides risking that there is another stakeholder in this game – the one who imposed the mentor on you. When it comes to mentoring the level of trust can not be undervalued. That’s why I picked some of the people I learned from the most outside my workplace. If my memories of the apprenticeship patterns recall correctly, finding a mentor is one pattern in the book. I whole-heartedly took it on multiple levels.

Peer-Groups

In the past year we played around with deciding about salaries. So far we had a system in place that didn’t scale: a group of four senior consultants decided about salary increases. Back in March we decided that every employer has the chance to self-select a group of peers which then work with the employer, and give recommendations for salary increases to the senior consultant group. Sounds crazy? Well it is.

Peer-Groups meet together from time to time, reflect on what the particular colleague did, and try to come up with recommendations for the future. In my particular case, I got some feedback from three colleagues, some of them I implemented, some of them I decided to keep stale for the moment. In our second meeting, I laid out my reasons to not pursuit this particular goal, and got some more feedback with some more goals, that I might pursue or not. So far, I found this group fully worth the time based on the feedback and recommendations I got.

In January we even decided to have a full day of peer groups. We met in the morning, working in a World Cafe on the idea of peer groups. Then we set up a market place with peer groups that wanted to meet and give and provide feedback. Some plans previously laid out were changed then, but we spent a full day with colleagues, talking about peers, how we see each other, and recommendations for further improvements. So far I found this feedback very valuable, nonetheless we are experimenting with 360°-feedback now. So, there might be more to come.

Conclusion

Picking the right mentor, and the right peers to listen for feedback and recommendation can help you personally grow. For both approaches it is crucial to keep an eye on the self-selected aspect of it. If this sounds like selection bias to you, maybe consider some of the constraints we initially put on the selection of peer-groups: at least one peer that is more senior than you are, at least one peer that is less senior than you are. We eventually re-formulated that into: at least one consultant, and at least one programmer in our final discussions, yet the constraints help you to decide about it.

One final thought. I myself consider me to know about the goals and directions that I want to pursuit. There are tendencies which I take up. So, meeting with mentors and peer groups far less is fine with me – so far. I hope to notice the right point in the future to change that. You might have a different cadence for similar get-togethers.

Programer’s survey

Up until know 183 people have filled out the survey.

The first question in the programmer’s survey is on the particular programming the programmers used.

The majority of programmers seem to use Java. There are some using JavaScript, C#, and Ruby. The minority of the participants so far use Visual Basic, Clojure, and Haskell. I think this is is relevant for the remaining answers – i.e. when it comes to the SOLID principles which mostly refer to object-oriented programming.

On the usage of TDD, I received some interesting answers so far.

43% use TDD regularly, 20% at least once per week, 17% about once per month. 17% never use TDD, and 3% don’t even know what it is. This surprised me, as I thought that fewer people use TDD on a regular basis.

On refactoring the picture seems a bit better.

64% use refactoring several times per day; 24% use it at least once per week, 8% about once per month. 3% never use refactoring, while 1% does not know refactoring at all. More than 90% of the people who took the survey at least know about refactoring, and use it on a regular basis – ome more often than others. This didn’t really surprise me, as today’s IDEs – besides ones like XCode or Visual Studio – ship with support for automated refactorings. Probably that’s why so many use them regularly.

The final question in the programmer’s survey referred to the SOLID principles.

48% consider it part of their work, while 32% think about some of the letters from time to time. 25 don’t need SOLID, and 19% wondered about why I wrote it all uppercase. Surprisingly this number is also higher than the numbers I had thought of before sending out the survey. So I was again surprised.

Tester’s survey

The tester survey was mainly motivated by Lee Copeland’s Nine Forgettings. So far 104 people have filled it out.

First of all I wanted to know about the experience in the field. I was interested in the experience of the people filling out the survey, and how this might correlate with the different viewpoints.

42% have more than 10 years of experience, 37% more than 5 years, 7% 4-5 years, 7% 2-3 years, 6% of about one year. 2% stated they started with testing just recently. This reflects a huge level of experience.

Next thing I asked for some testers in the past. Reflecting on Lee Copeland’s presentation, I was interested in how many people actually know these testers.

90% know Michael Bolton, 88% James Bach, 78% Jerry Weinberg. Michael Fagan, who introduced inspections, know 33%, Dave Gelperin, who authored the IEEE-829 standard, know 13%, and Bill Perry, who founded SQE, know just 8% about. I think this reflects some worries from Lee, but I was still surprised by the knowledge about some of the past heads in software testing.

On the last book read by the tester, I collected together a bunch of books, which I found helpful in the past.

19% have read some other book, 18% Lessons Learned in Software Testing, 18% Agile Testing, and 13% Perfect Software… and other illusions about testing. On the other answers, one thing struck me. There were some people pointing to books as Growing Object-Oriented Software Guided by Tests, and Working Effectively with Legacy Code, or Continuous Delivery. I don’t considered these as software testing books as to my understanding. I think this reflects the ambiguity that comes with the term software testing, but that could be just my interpretation.

Another thing struck me. 4% claimed they never have read a book on software testing.

On the book recommendations there were a few interesting points. At least two participants claimed that they read any of the ISTQB books last, and would not recommend any book on software testing. A lot of recommendations go out for Lessons Learned in Software Testing. Interesting in my data is also, that most of the participants who don’t recommend a book, have read books like any of the ISTQB books, The Art of Software Testing, or Managing the Testing Process.

When I try not to overrate the data, I would claim that we do not have the same understanding of what good testing consists of – given the variety of responses I got.

Some thoughts

On the programmer’s survey, I think my data is biased. I might have overestimated my reach with the survey here. I am quite sure that these data don’t reflect the state of our software development craft.

On the tester’s survey, I think my data is also biased. People reading my blog might actually be influenced by similar sources as I am. This means the context-driven and the Agile testing world. That’s ok, but I hoped for a variety of responses here as well. I seem to have got such responses by accident, but would like to see more people filling out this form to gain more insights, maybe.

That’s it for now. I hope to get some more responses, but don’t put too much faith into it.

In short, Angelique reminds us to ask potential new employees for the development processes they used, their development practices, – particularly TDD, pair programming, short iterations, and continuous integration – and how they educated themselves and kept their claws sharp. She also points out that she would ask for a proof of their talent, how they estimated, how deadlines are met, and what they can say about the costs involved when developing software.

This list was so compelling to that I decided to put up a similar list with the things I was looking out for hiring a software tester. I believe there are some unique skills I would look for in a software tester that I would not necessarily look for in a programmer. So, here it is.

I would ask about their approach in different contexts. Agile software development is all around us. But still many companies also use more traditional approaches. In the end, one approach to testing might work in an Agile shop, while it would fail dramatically on a more traditional project. I would look for their adaptability to different contexts, and how they react to different situations. In today’s world it’s certainly not enough to know about the latest methodology, but also to apply different techniques as unique situations unfold. I would also look out for their tactics in fast-paced Agile iterations, and how they adapt to two week long sprints. What about one week? What about daily deployments?

I would ask about the testing techniques they could show me right now without preparation. My experience in our field is that testers visit a course or two – if they actually can do so. After that they use the 20 percent of testing knowledge that they need in their day job – without exercising their brain cells on the remaining 80 percent. Even worse, there is little interest in growing beyond these practices. If the potential new hire can share a lot of testing techniques without preparation, she certainly uses all of these different techniques regularly.

I would ask about their programming experiences. Fast-paced iterations call for test automation. Even if you don’t work in an Agile context, programming knowledge will benefit you at creating different tools that assist your manual tests. In the end, you can talk to programmers on a different level, if you can at least read their code. Specifically I would ask the potential new tester if she could pair with me right now on some production code. I would also ask for experiences with TDD, pair programming, pair testing, continuous integration, and different automation tools and programming languages.

I would ask for heuristics they regularly use. Test automation alone is not enough. A good tester also needs to be aware of the oracles and heuristics by which we recognize a problem. A good tester also knows when to aim for more depth in their test sessions, or to aim for overview on a new product. These are covered in many of the mnemonics on software testing around. Maybe they even came up with their own mnemonic on aspects in their testing which they regularly use.

I would ask for a demonstration of their skills. This could mean to submit an example bug report as Lessons Learned in Software Testing points out. This certainly also means that I hand them some problem to test, and ask them to show me how they would test the particular application. Among the things I would look out for, is how they handle traps, and what basic assumptions about testing they follow through. I certainly would use one of the missions over at Testing Challenges.org. I would also spent an eye on how they try to clarify the mission, and how they involve the different stakeholders in their testing.

I would ask for how they work on their knowledge. What has been the latest book on software testing that they read? Which blogs do they read regularly? Did they invent a new testing technique (like the Black Viper testing)? Which conferences did they attend? Which online coaching opportunities did they take? Weekend Testing? Skype coaching? Miagi-Do? BBST? These are all examples of personal dedication to our craft. They also show a passion for life-long learning.

I would ask for how they collaborated. This includes collaboration with programmers like pair programming, but also with peers in pair testing sessions. I would also seek to get to know how they worked out specification details and acceptance tests with the customer. What is their approach to collaborate with programmers who don’t give a thing about testing and testers? How do they show their unique value they bring to the software development process, and how do they get others engaged in what they do? Testers need not be alone in their daily struggle on quality, and certainly shouldn’t be the gatekeeper about quality. I would look for a tester who understands that quality in the software is a team effort.

I would ask for their previous professional job. In the last year, I attended the second writing-about-testing workshop. During the introduction on the first day, everyone stated how she or he came into testing. Most of the participants didn’t pick software testing as their first job. Eventually they found out about their passion for testing by accident. Since then I made it a habit to interview testers about their path to the profession. Most of them had interesting stories to tell, and even compelling insights about fields of expertise that suits any tester.

Product:
Regression Test Calculator

Mission:
Test the regression test calculator for any flaws you can find. You might gain bonus points, if you can find out how the calculation is done. Another set of bonus points if you can come up with a better approach.

In the meantime I found out that Ajay Balamurugadas actually found the link to the website, and sent it to James and Michael. I think he deserves some special kudos for this.

These are the responses I received.

Twitter

I recevied some feedback over twitter. Tim Western challenged the purpose of the tool completely. He was not alone with this opinion. Justin Rohrman, and Ben Simo felt the same about the tool.

Michael Bolton noticed that “boundary” was mispelled in a link to another tool.

Peter H-L pointed out that you can actually get minus coverage. I wonder what minus coverage should mean. Maybe having tested a product less than untested at all.

jss mentioned that I should try one test case that takes one tester two hours. Two testers can execute this test in one hour. I think that calculator didn’t know about Brooks’ Law very well. Or the calculator also thinks that carrying out a baby takes two women 4.5 months.

Blog comments

I recevied four blog comments from my readers. One was actually a pingback from Rasmus Koorits who submitted his report via email. I will get to this in the next section.

Phil Kirkham played a bit with the calculator, but lost interest after getting the first division by zero error.

Jean-Paul Varwijk submitted his report on playing for fifteen minutes with the calculator. He found some interesting problems in just 15 minutes. I asked him for a condensed report. I hope he will reply on that.

Emile Zwiggelaar also went for a 15 minute session, and also found some interesting problems.

For all three reports, go back to the original blog entry, and read their comments. They found some quite interesting stuff.

E-Mail

I received exactly one report by email. It came from Rasmus Koorits, as I mentioned earlier. He had seven pages full of interesting stuff that he found. The report is very thorough. He showed great passion in the craft. I don’t dare to put his report up here without having asked him beforehand. Maybe I will add this later. I think he deserves the most kudos for following up, and he did well on that.

Some endnotes

I intentionally didn’t mention too much details about the bugs and problems. I hope that some readers will later dive into the topic, and submit a report on their own.

Over twitter I also received the feedback that things are worse for testers. I would like to put numbers on that as well. Therefore I also put up an equally small survey for tester: http://www.shino.de/tester-survey/ Please forward this survey to anyone in the software business that you know of.

From time to time to I will publish some of the results. I aim for end of January for the first set of data.

Complexity Thinking

Complexity Thinking evolves around three main concepts. That is, in each self-organizing there are several containers which determine the boundaries of smaller groups. Every organizational hierarchy could be thought of as such a container. But there are also others. In a matrix organization, containers also evolve around the project structures. Testers and programmers are also two different containers.

Containers themselves are defined by significant differences to other containers. There are also insignificant different between containers, and within containers themselves. Complexity Thinking states that the significant ones are meaningful for the work as a change agent.

The third concept has to do with exchanges. In order to self-organize, people in the system have to exchange their differences between each other. If there are too few exchanges, then the team will not be able to self-organize. The things we strive for as change artists are transformational exchanges, exchanges that yield a different behavior, a transformation.

As a change agent for self-organization this model helps us to find the right balance between containers, significant differences, and transformational exchanges. If people are stuck because they lack information from another department, organize an exchange between the two. If people self-organization is limited because the containers are not clear, then you shape these, or shape them differently.

MOI(J) model

The MOI(J) model consists of four aspects and two dimensions, on what leaders should take into account. The letters mean motivation, organization, information, and jiggle. The dimensions consist of observation and action.

In any group of people as a leader you can observe their motivation, how they are organized, and how information flows within the group, and beyond the boundaries. You can also observe whether the team is stuck in some particular sense.

Then you have different options to help the team, and lead them. You can change their motivation by introducing competition or by raising incentives. You can change their organization by promoting one of the team members. You can change their information flow by bringing in a colleague from that other department. Sometimes you can also jiggle the team, and show them new ways to handle the situation.

Now, complexity thinking appears to me to be a subset of the MOI(J) model. Transformational exchanges are changes that I may bring when I change their information flow. Significant differences can be mostly found in the way the team organizes their work, and what motivates them. Only the concept of containers is a bit vague for me in the MOI(J) model. It could have something to do with jiggling those boundaries once the team gets stuck. Yet, I found the MOI(J) model goes pretty beyond the Complexity Thinking model since it considers more variables for me as a system change agent.

I think there is more to it. So, here is your mission, if you dare to accept it.

Product:
Regression Test Calculator

Mission:
Test the regression test calculator for any flaws you can find. You might gain bonus points, if you can find out how the calculation is done. Another set of bonus points if you can come up with a better approach.

I am sure, I do not exceed the number of books that for example Michael Larsen read this year, but I was still amazed about the number – having estimated it at about ten or twelve. I decided to visit back the books I read, and see which lessons stayed current even after having read them. This list is based upon my notes over at Library Thing, where I looked up which books I finished this year. Some of them I started back in 2010. Some of them are also in German. some have an English translation, others don’t. Maybe time learning some German for some of my readers. :)

Training From the Back of the Room! – Sharon L. Bowman

I made this an expedite in my reading list. My colleague Stefan Roock visited the course back in 2010, and reported great things from it. I started to read this book back in January, read through in one week, and immediately started to incorporate the lessons into my training. I received some new inspiration from Sharon back in November when I visited her course as well. Great book, great insights, a must-read for any trainer and workshop moderator.

How to Read a Book – Mortime J. Adler, Charles Van Doren

I started to read this back in 2010. I got inspired by it on how I could test better. Initially this was a recommendation from Ilja Preuss with whom I exchanged some e-mails back before my time at it-agile – and also his. It explains why you shouldn’t bother reading every book, because some of them are not worthwhile to read cover to cover. This is especially the case when you face a book that is written badly, or that has some beginners content which you are already familiar with. The book also explains how to find out about it. Recently I worked through my to read list, and prioritized the 30 or so to read books based on the recommendations from this book. While the title might be confusing, definitely a book worth reading – maybe not cover to cover, but that’s how I did it.

Please Understand Me II – David Kirsey

Having dug deeper in the first part of this series, I was wondering what I would face when starting this one. This is also a relict from 2010. I enjoyed the insights about the Myers-Briggs Type Indicator from this book, but also the different temperaments which you may find in the different SP, SJ, NT and NF preferences. I learned some new stuff which I also incorporated in my trainings on a meta-level. For example, I remember one training where I was facing a detailed-oriented S-preference and knew based on this book what I had to do. Today, I might question the lesson I tried back then, but it helped in this particular situation. If you’re unsure about other people surrounding you, you should probably read one of these – but be prepared that this is a psychology book. I had no problem with that, since I had educational science back in school with a psychology teacher. But you might find it dry to read.

Kanban – David J. Anderson

This is another expedite book in my reading list for 2011. I decided to jump deeper into the topic of Kanban back in February. My colleagues were discussing how to extend our knowledge about Kanban and our ability to coach companies adopting Kanban. I felt I had to dig deeper. I found this book interesting to read, but at times the lessons felt a bit too managerial. Being a tester that is suspicious about any metrics, I also had problems reading this part. I think Kanban is an interesting method, and it surely will evolve over the course of the next years even more.

Exploring Requirements – Quality before Design – Don C. Gause, Gerald M. Weinberg

Since I read Bridging the Communication Gap back in 2009 I had this on my book shelf. Finally I got to read this book. I enjoyed it. Especially I enjoyed reading about different requirements elicitation techniques, as well as the Mary Had a Little Lamb Heuristic. I applied it from time to time on some particular pieces on my blog – which readers thought to be a bit nitpicking. Unfortunately I was already aware of most of the lessons. Yet the authors achieved to teach me some new things as well.

Weinberg on Writing – The Fieldstone Method – Gerald M. Weinberg

A book on writing by an author that has written more than 50 technology books in the past 50 years. This was an awesome read. Since I am working on some pieces of writing myself, Jerry could give me some great hints on what to try out, and how to digest ideas. I also watched two different Alive in Wonderland movies as a result of reading this book. Great tips from a book writing guru.

Pömpel, Patt und Pillepoppen – Matthias E. Borner

This is a book on the German dialect as it is used in the region of Bielefeld – the place where I grew up and studied. It is covered with some stories about Bielefeld, a small city with a 300k population. I enjoyed diving out of the usual readings in English, and reading some humor back at that time.

Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform Group Productivity – David Sibbet

Back in February we organized a Visual Facilitation course in our company. I finally learned how to draw flipcharts nicely, and what to do to make them colorful and engaging. As a result, I ordered several books on visual facilitation afterwards. This is the first one I started to read. Oh dear, I have to train my flipchart skills some more. Recently I found out that I still have to work more on them. Maybe a resolution for 2012.

Behind Closed Doors: Secrets of Great Management – Johanna Rothman, Esther Derby

Before attending the Problem-solving leadership course back in May, I already had this book. I asked both Johanna and Esther to sign it for me back in Albuquerque, NM. I enjoyed the management story alongside the explanations about good management. It’s not a business novel alone. It’s a business novel aided with theoretical insights about management. I think I read this in two maybe three weeks, which is quite fast for me. And you really had to force me to turn this down.

Pömpel, Patt und Pillepoppen 2 – Matthias E. Borner

The second volume from the Bielefeld dialect. This is the volume where I ran into the following saying for the first time:

Bielefeld is the nicest city in the world. Everyone who says other lies – or has been somewhere else.

Having been somewhere else, I think the author is right about it. :)

Rethinking Systems Analysis and Design – Gerald M. Weinberg

I enjoyed reading this book on system analysis and design. In one of the first few chapters, Jerry claims that you will think differently about design once you finish this book. He was right about it. He raises many questions about what we call software design, and really makes you think about it differently by doing so. A must read for any wannabe designer. I think Design Thinking could be originated based on this book.

xkcd – Volume 0 – Randall Munroe

This is an awesome geek comic on the web. I had to read the book once I saw it came out. It covers many comics based on science, geek-wisdom, and other stuff. A must read for geeks.

Give and Take – Chester L. Karrass

This was a recommendation from Jerry Weinberg at PSL to me. At dinner I joined Esther Derby and Jerry Weinberg for some personal coaching. On our way back to the hotel, we discussed the issue of the psychological contracts. Jerry recommended this book to me. I enjoyed reading it, and it cleared up my mind for things I can do to set expectations about my work more clearly, and how to work with concessions. At times I found the structure a bit unnatural, but as a lookup reference it’s awesome.

5 Very Good Reasons to Punch a Dolphin in the Mouth (And Other Useful Guides) – Matthew Inman

This is the first Oatmeal book. Another one in the series of the comics I enjoy reading. Humorous at times, thought-provoking at other times.

Runtime Error: Not Invented Here Book 1 – Bill Barnes, Paul Southworth

Another web comic I read regularly. This one covers the first few episodes of the Not Invented Here comic. A strip on a software development comic which seems dysfunctional at times.

The Gift of Time – Fiona Charles (ed.)

This was a gift – both for me as well as for Jerry Weinberg. Back in 2010 I asked Michael Bolton whether he had written any book, as I wanted to get a sign from him on one of his pieces. He said, there was a chapter from him in this book. I couldn’t find a copy, so he brought it to me when we met for the first time at the Agile Testing Days in Berlin. The book is a gift for Jerry Weinberg’s 75th birthday in 2008. It covers a lot of stories about his life, his courses on PSL and the SHAPE forums, and how he helped to gain the testing profession more momentum. It’s a must read for any self-claimed student of Jerry.

Agile in a Flash: Speed-Learning Agile Software Development – Jeff Langer, Tim Ottinger und Susannah Pfalzer

This is not necessarily a book, but a set of cards. Each card has one aspect of Agile software development on it. It gave me some insights, and re-taught things I already had forgotten. I had the urge to introduce it to a client of mine for lunch and learn events. It worked to some degree. Since then I am reconsidering how to use it with clients. I think it’s awesome, but might be too dense for Agile beginners.

Computer Programming Fundamentals – Herbert D. Leeds, Gerald M. Weinberg

This book is 50 years old. Yet, I found it interesting to read about things that still hold true in the first few chapters. The book seems outdated at times, but it covers the field of software testing for the first time in our industry. After reading James Bach’s chapter in the Gift of Time, I had to dive into this book. I was glad to find a used copy, as you can’t buy a new copy of it. While the technology seems a bit outdated, the psychological insights about programming are still up-to-date. If this doesn’t scare you, then maybe one of these quotes I noted down while reading it:

All good rules should not be applied with unthinking faith.

One of the more dangerous occupational hazards in computing is the habit of working out a set of diagrams, formulas, and figures until some impressive statement like “twice as efficient” emerges.

If we produce a new vocabulary word (subroutine) we must not produce something sloppy or something that may be misunderstood or misinterpreted.

Knowledge of only the instructions on a computer will permit one to code; but to be a programmer of any professional standing, computer operation must be understood.

Facilitating Organization Change: Lessons From Complexity Science – Edwin E. Olson, Glenda Eyowang

When Diana Larsen visited us back in July, she spoke about a program called Human Systems Dynamics. One of my colleagues, Jens Coldewey immediately booked this certification course as well. I decided to first dive into the topic some more before coming up with a decision about it. This book covers some aspects of complexity thinking. It states that uncertainty is fine in self-organized systems, that you can work with containers, differences, and exchanges to bring in organizational change. The model seems to have some power. Currently I am working on getting the pieces from PSL together with this model from Complexity Thinking. I hope to get my thoughts down soon on it.

Ten Years of Userfriendly.Org – Illiad D. Frazer

I think userfriendly was the first comic I read online. This book covers ten years of it – nearly completely. It’s a pity that Illiad had to turn to different priorities recently. I don’t know when I started reading this book. It must have been back in 2009. I finally read through all the comics. It’s thick, heavy, and I liked it a lot.

Geschichten vom Scrum: Von Sprints, Retrospektiven und agilen Werten – Holger Koschek

This is a little novel on Scrum. My first thoughts were that this book started a bit too slow for me. Over time I enjoyed the tiny tale about the land of scrum where unicorns use Scrum for any project. You join a dragon trap team which uses Scrum to build a flexible dragon trap. Along the way the unicorn – the Scrum coach – explains some insights about Scrum to you. An awesome story, a nice book, unfortunately just available in German. The Power of Scrum could be an alternative for business people, but this is one goes deeper on the topic.

Die menschliche Seite des Projekterfolgs: Was Softwerker über (verborgene) Denkautomatismen und -modelle in der Projektarbeit wissen müssen – Peter Siwon

Another “only German” book. I think this is a must read for any German speaking student of Jerry Weinberg. It explains some of the things that we encounter in projects in a way that was easily accessible for me. It is nicely structured for an NT-type like myself, but might be too mechanic for an NF one. It covers the human side of project success as the title claims. The author digs really deep into the material, and tells a lot of stories about his studies of projects from about twenty years. A great read, but I think it’s a bit biased towards the German culture – which is why it’s ok to have it not translated, maybe. :)

Dilbert 2.0: 20 Years of Dilbert – Scott Adams

A selection of 20 years of Dilbert comics. Being comic fanatic, I enjoyed the insights about comic author life here. Adams describes how he got started as a comic writer, and how Dilbert took off. In Weinberg on Writing, Jerry writes that Scott Adams and Jerry had the same inspiration for some of their stories. Jerry for his writing, Adams for Dilbert. I love both of their styles.

Hope I could bring you some inspirations. I don’t mind about the count. If you would like to read more about my insights from different books, please drop me a line, and I might publish them more often in 2012.