This year and the next (2013 recap)

2013 was an exciting year for me as far as tester stuff goes. I jumped into a lot of new stuff that I hadn’t done before, that’s sort of my style. Being in an uncomfortable area seems like a good thing, it really pushes you (me) to explore and learn and grow.

I have been instructing BBST classes with AST for about a year now. I got an email from Michael Larsen one day asking if I had time to lead a class, oh and he was going to be away on vacation for the first week. I said yes of course. Why turn something fun like that down, really? That’s the brief story of how I started being a lead instructor for BBST classes.

This year marked my second CAST and first Test Retreat. For the second time, CAST was a formative event. The conference is really really good, what’s even better is getting to hang out with friends after. This is where the magic is. Test retreat is what lead to me getting to WHOSE2013. I did a session on tester skill lists, and it just happened that other people there were interested in the same thing. Who’d have thunk it. Test retreat also spawned a book club that I’ve been enjoying a lot. Next year I’d like to go to two conferences, I’m not sure what the second will be though. Maybe QAOrTheHighway.

I worked with Michael and JeanAnn a lot this year while contributing sessions for WeekendTesting Americas. Weekend Testing is a great thing for so many people. Participants get a free place to work with groups on new testing topics once a month, facilitators get a place to pursue whatever topics are interesting to them at the moment. All it takes is a good idea and 2 hours of your Saturday. I’m looking forward to more of these next year.

Writing is not something I’m particularly comfortable with, most times it is a struggle. So, because of that, I started writing more often here. Writing and reading a lot really help to make writing easier. I also started to do some writing outside of my personal blog. I’ll be writing one other place, at least for a few months, early next year. I want to thank Matt Heusser for that opportunity.

I’m not really sure what 2014 will bring, but whatever it is I probably won’t say no. There are a few really interesting in the air right now and if any one of them panned out I’d be pretty happy.

book review: Taiichi Ohno Workplace Management

This book was a bit of a digression for me. I have read a lot books this year, but very little about management topics. This is a big hole in my software tool kit, so the change up was definitely welcome. Workplace Management is a book about managing the manufacturing process, well, sort of. Workplace Management is the text of a series of recorded interview with Taiichi Ohno about work he did at Toyota over his career.

Despite the fact that this is mostly about manufacturing, there is a lot here that is applicable to the software world. Obviously I’m not the first person to say that. The phrases ‘lean’, ‘stop the line’, and ‘just in time’ are pretty common in most software dev shops now. This book isn’t an introduction to lean, or kanban, or kaizen concepts so if you’re looking for that you may want to start somewhere else.

Here are a few of the big ideas I took from the book:
Do kaizen when times are good
It is so easy to get lazy and mentally slow down when times are good. Life is comfortable and releases are happening consistently, paychecks are on time (start-ups can be tricky) and there is never any after hours work. Taiichi thinks this is the most important time to figure out what you can tighten up and optimize. If you can be lean when times are fat, you should have better prepared to survive and thrive when times are lean. An interesting aside, Ohno also mentioned that you must make people feel the squeeze for them to generate good ideas.

The wise mend their ways
There is a full chapter for this topic. To me this is about honesty, ethics, and virtue. People make mistakes in the best of situations. In the book, Ohno mentions that even smart people with good intentions will be make mistakes and be wrong 3 out of 10 times. The phrase ‘the wise mend their ways’, to me, is about recognizing what isn’t working, being open to being wrong and failing sometimes, and trying something different immediately.

Direct observation rules
Through the book, I don’t recall Ohno emphasizing measurement at all. Maybe he did, I just don’t remember it. He did however tell many stories about being on the gemba (where the work happens), with customers, and with other companies in similar lines of business. He emphasized being there with the workers to observe, learn, and lead. The software world is mostly obsessed with measuring everything, so this was a refreshing point of view for me. My main concern here is about convincing people at higher pay grades that observation is a useful alternative, or at least supplement, to measurement.

Jido is a Japanese word (concept?) meaning automation with a human element. I recently wrote about this very topic for stickyminds, so seeing that this idea has a word in another language was interesting. In the Toyota system, this was embodied by having people watching auotmatic looms. If some problem was to occur, the person would press a button that would shut the machine off to prevent defective products from being made.

Mess with your employees a little bit
This part bugged me a little bit, I just chalk it up to cultural differences. There is a segment in the book telling a story about Taiichi calling a floor supervisor into his office. Once the supervisor made it to his office, Ohno scolded him for coming so quickly and telling him that if he were able to do that, then his employees must not need him. I think this sort of behavior is disingenuous, but again…culture differences.

WHOSE 2013 recap

WHOSE 2013 was held at the offices of Hyland Software December 5-7, 2013.

A note first, this is my own experience of the workshop. I’m sure there will be other experience reports popping up soon, and they may have different, but perfectly valid personal experiences to share.

Jess Lancaster, Jon Hagar, Doug Hoffman, Jeremiah Carey-Dressler, Nick Stefanski, Pete Walen, Rob Sabourin, David Hoppe, Chris George, Alessandra Moreria, Justin Rohrman, Matt Heusser (facilitator), Simon Peter Schrijver (facilitator), Erik Davis (facilitator)

Day One
Day one began with presentations from:
Jon Hagar on current industry resources for skill lists and education resources such as ISO standards, IEEE standards, SWEBOK, and ISTQB.

Matt Heusser spoke on the goal of the workshop, defining what a skill is, discussion on how and if we should model the skill list any particular way. The working definition we came up with for skill is any activity which can be isolated, demonstrated, evaluated, developed , and observed.

After presentations, we went around the room and did introductions and a brief statement of why we were there, what we planned to contribute, and what we hoped to take away from the event.

List creation
After this we began creating and categorizing the skill list. This activity took place by individuals writing single skills on index cards over the course of 45 minutes or so. I’m not sure how many cards we ended up creating, but I would guess it was over a hundred. Some were very similar, and some overlapped to a degree. We categorized the cards by theme (examples: social, tech, test design) and this categorized list became version .000001 of our skills inventory. Every skill noted was something someone in the room felt relates directly to the activity of software testing.

After this we formed groups and began to get the categorized list into a wiki. This initial version was a working definition of a skill, and a few resources of where someone could go to learn about that skill. At the end of the day, each group presented on what the work we had done. We were mostly unhappy with what we had at that point.

Day Two
Day two began with a brief recap of the previous day and some talk about new tactics we could take. We “mobbed” one skill as a group and came up with a very good example of what would be the basis for the remaining work. This new style of skill list was significantly more time consuming to create, but, in my opinion, has far more value. We continued working in groups in this style for the remainder of the day with another recap at the end of the day. This work was mentally exhausting.

Day Three
We was a half day which ended at noon. We spent the day closing the workshop. This consisted of talking about the remaining work (who was going to do and how would it get done), and closing remarks.

Some personal notes
Being in a room full of smart people, all actively working side by side to improve the craft of software testing was an amazing experience for me. I have never participated in a facilitated LAWST style workshop before, originally this was intended to be in that format. Groups formed and gelled very quickly, so there was little to no need for facilitation. I heard comments by folks that have been to and facilitated many LAWST workshops that WHOSE was unlike any other workshop they had been to.

The CDT community has a reputation for being contentious and having a certain amount of infighting. I witnessed absolutely none of this. Groups had cordial, open discussions with disagreements without any negativity or personal attacks. I think that is an important thing to note.

Day two was long and exhausting, I hit a wall around 2 and was struggling to produce good work after this despite a constant flow of coffee. This kind of work is far more difficult that I imagined prior to the workshop. A monumental effort was put in over the three days and I’m proud of what was created. It will take some time to get the work into a more complete, presentable state, but I’m looking forward to that day. Feedback and contribution from the testing community will make this living document even more valuable.

Book review: Two Books on writing

Like most people, I haven’t written much of anything since the required English curriculum. That curriculum, more than anything, robbed me of a desire to write. Part of what I’m doing here at my personal blog and over at StickyMinds, is a lesson in learning to write things people will read and enjoy, but also to have it not be so difficult every single time. To help get things moving, I’ve read a couple books about writing, Weinberg on Writing: The Fieldstone Method, and On Writing: A Memoir of the Craft.

There are many many books on writing, it seems that every big name author has one. These two were at the top of recommendations from friends, so that’s where I started. Both of these books are fantastic, I really enjoyed and recommend them to anyone that wants to try writing again. These two books are similar in some regards but very different in others.

On Writing by Stephen King begins with a story about his development as a writer from his youth to present day. After the story, King goes on to talk about many aspects of writing he thinks are important. This book is written by and for fiction readers, but there are lots of ideas that will transfer to non-fiction writers as well. There are sections about adverb usage, dialog development, and story development. One of the parts that stuck with me the most was King’s description of ideas as fossils that must be unearthed. First they must be located and excavated, but after that you have to delicately clean the ideas up with smaller picks and toothbrushes.

Weinberg’s book, Weinberg on Writing: The Fieldstone Method covers this excavation and unearthing process in detail. As a novice with no particular method to employ when writing, this book was a life saver. The fieldstone method is a method Jerry uses to describe the process of finding, shaping, organizing, and forming ideas into something people will read.

This book draws a parallel between writing something and building a stone wall. Each idea is a stone that fits into the wall in some way. Stones come in all different shapes, sizes, and materials and each fits into a special place in a wall.

Weinberg on Writing: The Fieldstone Method was a a great reference book for me. I didn’t read the chapters in order, or even read the whole book. I had authentic writing problems to solve and was able to browse to the relevant chapter.

These books are both invaluable, I don’t regret the purchase at all. One thing they won’t do for you however, is practice. Stephen King recommends writing 1000 words per day in his book, I don’t recall Weinberg making a recommendation in his book but I’m sure he would recommend something. You don’t get good at running by reading about it and you don’t get good at writing by reading about it.