Markus Gärtner's Blog, page 17

The Satir Change Model and Kaizen

Right before Christmas I crossed a write-up of Al Shalloway about Kanban being the integration of Deming, Ohno, Goldratt’s Theory of Constraints, Satir and Nonaka. At a similar time I finished Jerry Weinberg‘s most recent book Experiential Learning Volume 3 – Simulation. Jerry explains the Satir Change Model in such a great way, that I would like to elaborate a bit more on the relevance of the model particular for Kanban.

Status Quo

The status quo is the state that you are currently in. Everything is quite comfy, you don’t need to bother about things outside your personal experiences that could go wrong. You can rely on different givens, and everything just works out well for you. Weinberg describes this state as “everything being familiar and in balance”. The status quo is “the outcome of of a series of attempts to get all the outputs of the system under control”. But the balance in that outcome might come at a cost:

[That] balance may require various parts of the system to have an unequal role in maintaining that balance.

In his blog entry, Al Shalloway writes about people preferring to work in their comfort zone. I consider the comfort zone as the late status quo that you are working in. You can lean back, do business as usual, and don’t have to cope with such things as foreign elements that kick you out of your comfort zone.

Foreign Elements

As Weinberg describes it, “change takes place in an unending series of cycles”. What causes such a cycle to start changing behavior is a foreign element. That foreign element is not particularly a sudden crisis, but rather the “sudden realization that things have been very unhealthy”. Or to put in Weinberg’s words from his book Secrets of Consulting:

It may look like a crisis, but it’s only the end of an illusion.

(Rhonda’s First Revelation on page 149)

Such a foreign element is out of control of the current system. That’s why it’s a foreign element.

There are many things that could yield a foreign element. The death of a person near to you is the beginning of the realization that something (or someone) has to step in that gap that will be created there. The missed deadline in your project plan might cause you to run around like headless chickens asking everyone to work overtime to please the customer by appearing to work. And finally, the introduction of transparency in terms of a visualization on a Kanban board can lead to a foreign element that causes programmers to start helping out at the perceived testing bottleneck.

Yes, that’s right. The introduction of a the first practice in Kanban – visualize your workflow – alone may lead to an foreign element. In the end, Kanban claims to be an evolutionary change method. Taking Weinberg’s picture from before – “change is an unending series of cycles” – it is inherent to Kanban that it introduces a foreign element for the first cycle to begin. Or stated in another way: Whatever you observe, gets changed – a problem every anthropologist is aware of.

Chaos

What happens in the chaos stage of the Satir Change Model is merely the try to cope with the foreign element. Depending on the foreign element, people in the system might reject the foreign element to cope with it, ignore it, hide form it, or actively fight it. What characterizes the chaos stage in the Satir Change Model is “that predictions no longer work”, “old expectations are not fulfilled”. “The Old-Status-Quo system has been disrupted.”

As a reaction on this, people might become scared, hiding from the foreign element, neglecting it, deny it, or deflect it – effectively playing the Hot Potato game. Weinberg describes that “people try random

behavior, or try reverting to even earlier behavior patterns, perhaps from childhood.” What’s remarkable about people in the chaos stage is that their thinking ability might be reduced since they will argue from an emotional viewpoint, not from a rationale one. In the end, fear, is an emotion, right?

More interesting, people might reject the foreign element so much, that they end up at Old-Status-Quo behavior. They might inflict the element to someone else, or might cope with it in a different manner only to get back to their comfort zone. In the end, it’s very comfy there.

To get back on my earlier example of the Kanban board, the board should be hard to reject. In the end, it tells the story of the old process. It makes things transparent. It will help you and your team overcome the temptation to revert to your Old-Status-Quo. That does not mean that Kanban inherently will lead to better changes, or lead to changes at all. That means, Kanban implemented well will make the rejection of foreign elements as they occur hard. That might also mean that Kanban implemented badly will lead to worse behavior than your current status quo. My gut feeling tells me that the recent addition of leadership to the Kanban practices yields from enough bad Kanban implementations because it needs leadership to help the team overcome the tendency to reject the foreign element they see and hide from on their boards. Kanban implemented well also means to nurture a culture of change.

Integration and Practice

During the stage of integration and practice, people will try various things to cope with the new foreign element. They will try out new things to overcome the short-comings of their old predictions. While productivity might have sunk during the chaos stage, in the integration and practice stage it will start to fluctuate. People will need a lot of slack-time to try out new things, and overcome a certain hump of pain. Some things will turn out to be bad ideas, others will work greatly.

Weinberg writes about the concept of a “transforming idea” that “AHA!”-moment where you stand up and say, “I learned something.” Weinberg describes that “just as the foreign element marks the beginning of chaos, the transforming idea marks its end.” When you had your transforming idea, you start to practice over and over to become even better at what you were doing. Of course, all along this process, you might find yourself facing the foreign element that your transforming idea was not that transforming in the end, does not scale, or leads to sub-optimal results. Then you might fall back into the chaos stage, and start to try new things. You might also find yourself getting back to the Old-Status-Quo. But a change to a higher potential of productivity needs the transforming idea and a certain time of practicing it. The transformation and the practicing turns a “good idea” into a great one. “here is where we can create an environment to perfect a good idea, or reject one that turns out to be bad – rather than demanding immediate perfection.”

Reflecting back on Kanban, it’s mandatory to establish a pull system that will create just enough slack-time to perfect your good idea, or reject it. The pull system creates the environment that helps you perfect the transforming idea, or play around with it enough to be able to reject it.

New Status Quo

At the end of the integration and practice stage stands a new stage of comfy feelings, where your new predictions will work. We will have reached a new comfort zone, a new status quo. Of course, just until you realize the next foreign element, and the cycle starts anew.

Conclusion

As you can see, Kanban makes use of the Satir Change Model a lot. Its practices and principles help to deal with foreign elements. For example, I left out the discussion on the Kaizen culture – a culture of small changes. Kaizen helps to cope more easily with foreign elements – foreign elements that are small enough though. It does not prevent you from Kaikaku – larger changes – when you start to realize larger foreign elements.

2012 retrospective – Addendum: The articles

Happy New Year!

I was not going to blog about this, but it turns out that this twitter conversation between Lisa Crispin and Meike Mertsch prompted me to it. So, here are the articles I wrote in 2012. Since I write in two languages, I decided to separate them between my English and German articles. I also try to just mention the ones that were published in 2012, not necessarily written.

English articles

We are not alone – Agile Journal

Unfortunately I can not find the article online any more. It’s a piece that I wrote in 2010, I think. Most of it was prompted by an email discussion I had with Michael Larsen on the lone tester. That inspired some advice on how to realize that you need help from someone else, and how to find that.

Getting started with ATDD – Overcoming the biggest mistakes right form the start – InformIT

For this one, Lisa Crispin prompted me to do a write-up on how to get started. Some of it is inspired by chapters 9 through 12 in my book, all of it goes beyond that.

Why Specification Workshops work – InformIT

In this one I describes what specification workshops are, and why they work. As I had just read Harry Collins’ Tacit and Explicit Knowledge book at that time, I saw his model from epistemology applied in specification workshops.

ATDD as a third-level XP practice – InformIT

In this article I discuss whether ATDD is a third-level XP practice, meaning that you can bring in some of the benefits only, if you have stuff like continuous integration and a fully automated build in place.

Test-driven Test Code Development – Unit Testing Page Objects – Methods and Tools

In this article I show how to use TDD for your page objects in Selenium. You are test-driving your support code, right? Yeah, me, too.

Can we say no? – The Testing Planet issue 7

This one I wrote on my way back from XP 2010 inspired by Are your lights on? from Don Gause and Jerry Weinberg. I raised the point of us testers and programmers being in charge to say no to unreasonable claims like working overtime for 10 weeks in a row.

From Test to Driven to Design – The Testing Planet issue 9<

In this article I describe the xDD maturity model. If you know me, you should know what that means. If you don’t, you should read it.

German articles

Agiles Testen: Ein Pfad hin zur Teamunterstützung – ObjektSpektrum 02/2012

In this article I describe what agile testing is, and paths that lead to supporting your team as a tester. My personal experience indicate that especially German testers have great problems with that.

Kanban für Tester: Evolutionäres Qualitätsmanagement – ObjektSpektrum 04/2012

In this article I wrote a little narrative with my colleague Arne Roock on Kanban. We join a tester new in a Kanban shop, and see his experiences with the method.

Anforderungen als Leichtkost – ObjektSpektrum Onlinethemen-Special Requirements Engineering

In this article I wrote together with Meike Mertsch about different lightweight ways to requirements.

“Wir brauchen mehr Qualität” – Systemische Effekte hinter den unfairen Fragen – ObjektSpektrum Onlinethemen-Special Testing

In this piece I apply Systems Thinking to counter unfair questions such as “we need more quality”, or “why haven’t you caught that bug?”.

That’s it. Eleven articles. Sounds ok to me (and I think I can do more.)

2012 retrospective – The books

After some reflections on my professional life, and the conferences I visited, I would like to go for the books that I read next. I will do this part of my personal retrospective in the same way I did it last year.

2012 has seen many new books. It seems no one can hide from the influencing that Lean Startup had on the products out there. That said, I also read a lot of books in beta from LeanPub. I purchased and read some books while they were written in 2012. So, you will not find all books on the platforms that I used like LibraryThing and GoodReads.

Flawless Consulting – Peter Block

As much as I loved Jerry Weinberg’s Secrets of Consulting series two years back, I also loved reading Peter Block’s Flawless Consulting. The key lessons I took away from it were how to negotiate the verbal contract with the client, and that I shouldn’t take anything personally that happens before 6 pm. I think it’s a must read for every consultant. Unfortunately I read the second edition, and figured only later that there is an updated version out there with content that came out in the past decade. If you are buying the book, check for the latest version.

Miteinander reden Band 1 – Friedemann Schulz von Thun

One of the German books I read this year. In fact, I read the whole series. It’s a book series on communication psychology – one of the fields that seems to be not well known among technicians. The first book introduces the concept of listening and speaking with the four ears – context, relationship, self-revelation, and plea. Schulz von Thun claims that we speak and hear with different emphasis in these directions. For example, someone that hears too strong on the relationship ear will lightly be offended by a message that was intended more on the context. Much of it resonated for me to the stuff I learned from Virginia Satir.

The Lean Startup – Eric Ries

These days, it seems hard to escape the validated learning mantra, and probably everyone going to conferences has heard about the Build-measure-learn loop. My colleagues spoke enough about it for me to start reading Eric Ries’ book. It was an eye-opener, and eventually led to some thoughts on how a tester contributes in a startup.

Miteinander reden Band 2 – Friedemann Schulz von Thun

While the first book in this series introduced the four ear concept, this one set out to settle misunderstandings. Schulz von Thun describes were communication can go awry, and how to settle it, using a scheme with four corners, where two oppositional positions with extremes can be settled. It was an eye-opener for me again. The main point is that we sometimes end up in extreme positions where such dogma is not useful – especially when dealing with other humans.

Tacit and Explicit Knowledge – Harry Collins

I think this was a recommendation from James Bach from CAST 2011. In the book, Collins describes that tacit knowledge can not exist without explicit knowledge. He also explains the limitations of making tacit knowledge explicit. Especially when it comes to explaining some domain knowledge or technical knowledge, I noticed that writing a document is indeed a bad thing to do (like I didn’t know before-hand, but the book explained to me why). Collins also explained for me that manual testing is not going to be replaced by automation – just like the choice of bread, the recipe, and the eating are still manual decisions even though we have invented automation in terms of bread baking machines. We can automate the kneading, but not everything – just as in software development, or writing.

Miteinander reden Band 3 – Friedemann Schulz von Thun

In the final book in this series, Schulz von Thun uses the metaphor of an inner team to describe how we act and react in different situations. He describes how we can train our inner team, make ourselves aware of the different team members, and even change the settings – and our responses – to end up in more congruent communication. I think the whole series is a great addition to Satir’s lessons.

The principles of scientific management – Frederick W. Taylor

What? Yeah, I read this one. Back in May I was intrigued by an internal discussion about Taylorism in Scrum. The main point was, that the concept of ProductOwner and ScrumMaster take away some of the thinking from the Team. Thereby this yields to a tayloristic separation of thinking and doing. At some point, no one knew what Taylorism was, nor were we able to find any definition about it. My colleague Arne Roock read Taylor’s freely available book, and inspired me to read it as well. The writing is old, and at times hard to read, but it was worthwhile reading it – just as I recommend reading Winston Royce’s paper on waterfall (read up to the final page, not just the second graphics).

The New Comedy Writing – Step by Step – Gene Perret

This was a recommendation from Gojko Adzic when I attended ScanDev. Perret describes by-and-large how to write good comedy. I tried to incorporate some of the lessons into my presentations. So far, I think I failed to do so. Maybe I should read that other book that Gojko also recommended, and really try it out. Great book, indeed, but plan in some time to try all these lessons out. I unfortunately didn’t.

Influencing Patterns for Change – Royce Halladay, Kristine Quade

This is one of the books in the Human Systems Dynamics series of books. It was a quick read for me, and inspired some new insights about organizational development. Especially as Halladay and Quade provided some tools to think about organizational change, this is a must-read for any change-agent.

Thinking Fast and Slow – Daniel Kahneman

Another recommendation from CAST 2011. This book describes how we make choices, and the different biases that are involved in anything us humans do. Kahneman did a lot of investigation and research using gambles in the past 40, maybe 50 years. He describes about the psychology involved, and introduces his model of two thinking modes – one being analytical, the other more driven by fast responses. Whenever we can, we avoid the harder analytical approach, Kahneman claims – like when you drove to work, and can’t remember how you got there.

LiftOff – Launching Agile Teams & Projects – Diana Larsen, Ainsley Nies

These two ladies describe their approach to launching an agile introduction. Even if your project is already underway, the two day workshop proposed in this book should be worth checking out. Beyond the concepts of values, purpose, and alignment you will learn how to get the right team going with your project, and how to create the right vision from the start.

Adventures in Thesisland – The 5th Piled Higher and Deeper book – Jorge Cham

Finally an update from one of my favorite online comics: PHD comics. Although I already read most of the cartoons online in the past few years, it was great to have them together in one larger book. Oh, and I also own the other four volumes, of course.

Quiet – The Power of Introverts in a World that cannot stop talking – Susan Cain

This was a recommendation from Jurgen Appelo at ALE 2012. Cain describes in her book different introverts and how they discovered their strengths. She also has a compelling message on how us introverts influence others who think while they talk. I learned so much from this book about my own preferences, and how I can contribute to an intense discussion. It’s worth reading this book – not only as an introvert I think.

The five dysfunctions of a team – Patrick Lencioni

This was a long “need to get” item on my reading list. When I met J.B: Rainsberger and Ruud Wijnand at XP 2012, I had to order it right away. Overall, it took about two days for me to read this fable. I was a great thing. Lencioni describes the five dysfunctions of a team as absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to (team-) results. I was already familiar with this concept, but reading about it in a fable made me aware of the times when I suffered from the same dysfunctions – or even worse, when I contributed dysfunctional to a team. Ever since I can make myself aware of it, and seek to build a better team around it.

About Coders – Geek & Code

Another book from one of the web comics I read (yeah, I read a lot of them). The Geek & Code comics usually resonate around one concept in software development. They use coders to explain different things like continuous integration, or a CI system. At times this might seem dysfunctional, but I see the comedy lessons from Perret’s book above applied. Besides, they’re funny as well. :)

How to tell if your cat is plotting to kill you – The Oatmeal

Oh, another web comic. I love the Oatmeal comics. For example I go nuts every time someone mistakingly uses “to” or “too”. I attribute it to the Oatmeal since I read this comic. This book is full of kittens. So, in case you don’t like the Oatmeal, you might eventually love the kittens.

The three signs of a miserable job – Patrick Lencioni

Another recommendation from J.B. Rainsberger and Ruud Wijnand at XP 2012. This book describes the three signs that eventually lead to job frustration, and how to improve work. Lencioni claims that you need to get rid of anonymity, irrelevance, and immeasurement in order to overcome high staff rotation at your workplace. This can be achieved by getting to know your personal, helping them see where they help someone else in their life, and how they can assess this help on their own so they know they did a great job without the need of the manager to tell them. I think there is a lot of lessons in here to learn for good team building.

CAD Volume 2 – Tim Buckley

Another one of my online comics. The second volume was sold out for the longest time. But when Buckley published the fourth volume in late 2012, he also put up a re-print of the second volume. I had to get both, together with a Zeke plushy.

Discover to deliver – Agile Product Planning and Analysis – Ellen Gottesdiener, Mary Gorman

This is the first of the books that is not yet available. I was happy to receive an up-front copy of it. In the book, Gottesdiener and Gorman provide a model with structured conversations, seven product dimensions and other tools that help you to explore and discover your product. A book worth reading from my point of view, especially since it builds the bridge from business analysis to specification by example and ATDD.

The Retrospective Handbook – Pat Kua

This is the book that inspired the idea for a 2012 retrospective. Kua describes a lot of things to be aware of when you are facilitating a retrospective. Kua describes not so many different activities for retrospective, but provides different tools for the facilitator. Definitely worth checking out, especially if you haven’t read the other two retrospective books from Kerth and Larsen/Derby.

Experiential Learning Vol. 1-3 – Gerald M. Weinberg

Yeah, Jerry didn’t write a single book this year, he wrote three of them. With Experiential Learning Jerry provides the baseline for his Problem-solving Leadership courses, AYE, and all the other courses he’s offering with various folks. The basis for the courses lies on experiencing the training, and deriving your own personal lessons for you. That said, if you attend PSL next year you might take something completely different from it than what I experienced in 2011. Ever since reading the first and second volume in this series, I plan to incorporate some of the lessons into my trainings. Thus far I have ended up with a combination of the 4Cs from Training from the back of the room and Experiential Learning with good success. I think I can extend this in the years to come.

Explore It! – Elisabeth Hendrickson

It was long overdue that Elisabeth wrote a book. With Explore It! she has done very well. Once I was informed about the upcoming, I ordered it in beta, and read the first beta in a few weeks. Five updates later, I have received the final version that is going to production right now. I started recommending the book ever since then. Hendrickson explains by-and-large how to use charters in Exploratory Testing, how to setup your sessions, and how to plan and follow up on different sessions. She also explains different variables in the application – some of which that you can see, others which are not so obvious. Oh, and she explains how to use her test heuristics cheat sheet well.

The Elf who Learned how to Test – Mike Talks

I saw this on twitter last week. I directly checked it out. A neat little story about a Christmas elf that learns how to test toys for Santa Claus. Loved it, and it was for free.

ATDD by Example – Markus Gärtner

A shameless plug, but since I reviewed the book, and decided to read it once more from cover to cover before it goes to production, it would be unfair to leave this from the list. I think the worst thing that can happen to an author once his book is published, is that he wins it. At the time you finish your book, you have read it often enough to hate it – at least it’s the case for me.

2012 retrospective – The conferences

Following up on yesterday’s blog post, where I do New Year’s resolution in Alistair’s style, today we will take a closer look on the conferences and peer workshops I visited in 2012. And I fear there are many. I remember when I sat with my colleague Meike Mertsch in early October, and we had brainstormed conferences we could submit talks to. In the end, we knew we had to cut that list down to a reasonable size, even before counting them. There were about 50 conferences on our list.

Here are the ones I visited in the past year. I tried to group them by theme, not by date.

Testing conferences

Oh, dear, there have been plenty of those. Where should I start?

There were several new events this year on software testing. Take for example TestBash where I facilitated Testing with a stranger with Huib Schoots. The second TestBash is already scheduled for 2013, and I like a lot what Rosie Sherry put up with her Software Testing Club.

Then there was Let’s Test where I did Charter my tests! for the first time. It was so awesome seeing what is possible on context-driven testing, even and especially in Europe.

And last but not least, there was the Test-Coach Camp – an unconference on coaching testers. We did two days of open space, and I took some new insights away from it.

Test-Coach Camp preceded CAST 2012 where I did a workshop on Beyond Testing. With Let’s Test earlier that year, and CAST I somehow sensed that context-driven testing seems to have lost some of the energy – at least for me. I hope there is some new energy coming up next year.

It was different at EuroSTAR 2012 where I did the Beyond Testing workshop again. There seemed to be so many aspiring testers around, and a lot of people that I could teach a thing or two. In the end, it seemed to be a get together of some old friends.

Oh, and I got to do some keynotes this year for the first time. First, there was the German Testing Night where I did a German variation of Agile Testing – What is this anyways?. For the Ukrainian Testing Days I did the same again. And then there were the Agile Testing Days where I presented on a meme from the Matrix movie: Adaptation and Improvisation – but your weakness is not your technique.

Oh, I nearly forgot the Software Quality Days where I did a presentation that I did the first time at the Agile Testing Days in 2009 called Agile Praktiken in einem traditionellen Umfeld. That content seemed a bit far away, though – especially since I switched jobs since then.

Finally, there were two peer workshops. GATE No. 2 and DEWT 2. At the latter one I did a lightning talk on What I learned from coaching a context-driven tester – a story about how my colleague Meike Mertsch and I do coaching, and what I could tell worked for her and me.

Developer conferences

Oh, and then there were a lot of developer (and coaching) conferences as well. A lot of times I did Agile Testing – What is this anyways? there: ScanDev and XP 2012.

At ALE 2012 I did Testing with a stranger on the software that was developed in parallel to the open space. It was quite nice to provide someone real the feedback from the tester group, and we probably should have joined the development sooner.

Another unconference was SoCraTes, which I helped organizing in both years now.

The remaining developer conferences appear to be German. At JAX I did Von Benutzerzielen zur ausführbaren Spezifikation, and at XP Days Germany we had an interactive session with Von ATDD zur Outside-In Entwicklung.

Three times I paired up with one of my colleagues. At Mobile Tech Con I did Testen mobiler Anwendungen – von automatisiert bis manuell together with my colleague Sven Günther, and together with Meike Mertsch we presented Einer für ale, alle für einen at Karlsruher Entwicklertag and W-JAX.

Looking over this list, I think I will go for more German testing conferences next year. There seem to be just a few right now. I hope I can help to change that.

2012 – A personal retrospective

Four more (whole) days are left in 2012. As the world seems to turn a bit slower in these final hours of the year, I decided it’s time for some personal retrospective. Since I read Pat Kua’s Retrospective handbook this year, I decided to do some writing about my year on my blog as a personal retrospective. I will cover the books I read and the conferences I visited in later blog entries. This blog entry will stuff that happened during the year.

The book

Oh, yeah, I eventually finished my book and had it published back in July. It was a bit weird to walk into a bookstore in the states, and see it on the shelf while I was at CAST in San Jose, and when I came back one week later, I was unable to find the book in a bookstore in the country I grew up. Well, since then I try to keep a pile of books as give-aways for talks and conferences near to me.

You could imagine that once you have published a book, you love to read reviews of it. That holds to some extent. Of course, you love to read twitter comments (that are positive), reviews (that are positive), but most likely, you start loving the stories you hear from readers. That said, one conference attendee, Inge, at the Agile Testing Days approached me, and told me that she had handed over my book to her programmers, and they are now addicted. It’s these stories that make up for all the stuff you read on bad twitter comments and bad book reviews.

On the road

With the publication of the book, I also started to be more and more on the road. According to TripIt I was on the road for 305 days in 2012, on 109 trips, traveled 80,487 kms while visiting 35 cities in 9 countries. Yes, you probably counted right, I was not at home every weekend. Especially once you consider that I had taken four weeks off during June.

But where have I been to? There was of course Germany, the States, Sweden, the UK, Ucraine, the Netherlands, oh, and Austria. I think Denmark and Poland also count as visited countries, even though I merely traveled through them on my way to other destinations. All of them were business trips. But what about family time?

The Baby

Then there was Nico.

Born on June 6th, my son is filling our home with some pleasures.

Weight loss

As part of my readings this year, I read about the Four Hour Body. That said, my weight in early January 2012 was 112 kgs, and went to a low in June at 87,9 kgs. I lost about 25 kgs in five months. How did I do that? Mostly, I gave up on sugar, and did some other neat tricks. After about three years of exercising up to six times per week, I figured it’s my diet that I need to change.

Since June I try to experiment with food to find out what is a steady diet that I can keep my weight at. That said, since then my weight loss is stagnating, and I feel good about it. I gave up at reaching 20 % body fat once I figured out I would probably on an all-time low of 81 kgs then.

Running

Since early 2011 I started running. Being on the road a lot means that regular exercise beyond running is a pain. At one day in early July this year, I had the farthest distance ran, so far, which is at 25 kms right now. Since then I exercise for a run next year near my hometown.

BBST

Oh, I nearly forgot this one. I finished all four courses on black-box software testing this year – the forth being the instructor’s course. Doing all this stuff in parallel to my traveling, the baby, and the exercising was still a drag, but it worked out in the end. At times I have been exhausted from it – even with the final review of my book in parallel – and I had to take time from other stuff to get this all done. Suffice it to say that I am comfortable with few sleep.

That’s it for the time being. These were the major events that took place for me this year. There were more, tinier things, that piled up to something, maybe. Mostly, I think these events are not worth mentioning. I will go for the conferences next.

The best programming language

Since it was shortly before Christmas, I put a wish on twitter last week:

Anyone who wants to give me a gift for x-mas, consider writing a programming language where “if (* == true)” results in a compiler error.

This inspired some ideas on the twittersphere, and I decided to bring this topic to the Hamburg Software Craftsmanship user group on last Tuesday. Here’s what we brainstormed together: The best programming language, ever.

I need to elaborate a bit on some of them.

Disclaimer: Don’t hate me, I’m just a messenger.

if (foo == true)

I hate looking at code like this:

if (foo == true)

This really should be simpler than that:

if (foo)

There are also more convoluted examples of this. I dare not to mention them. As far as I would say, this should be rejected from the compiler.

else
else

is really ugly. I don’t know why to use this to start with. If you can’t hold, use a guard clause, and deal with the else path directly. It will make you happier. Oh, and don’t care about the “single exit from function” paradigm. Only people led astray talk about such non-sense. else is worse.

foo ? whenTrue() : whenNot()

Really, like else before, stop using this crap. You no longer work on 80 x 25 screens, do you? Well, sorry, if you do. But The tenary operator is merely a bad replacement for a conditional with an else. Stop using it. Period.

if – else – if – else

Vertical code is even worse. I think there should be a check on the cyclomatic complexity during compilation time, rejecting code that has a deeper level than 5. Right, maybe such a language won’t become mainstream, but then again, maybe we shouldn’t hire mainstream programmers to start with.

throw null

Yeah, really. That works – or maybe worked a while ago. I didn’t check with later versions of Java. I think Nat Pryce made me aware of this. It ends up in a NullPointerException when the Java exception handler tries to print the stacktrace.

i++ + ++i

For all those friends of C/C++-style languages, this might give you a headache, since the results may vary from language to language, and sometimes even from compiler to compiler (depending on the optimization level you enable).

switch (true)

Yeah, I heard this the first time. NEVER USE THIS!

switch (true) {
case a:
// code when a is true
case b:
// code when b is true
case c:
// code when c is true
default:
// "else"
}

Assignments in conditions
while (b = readLine() {

Really? Wtf! No one should write such low-level code nowadays anyways. Stop it, please.

Stuff we couldn’t agree on

There were other stuff that we couldn’t agree on like the never ending vi vs. emacs debate (emacs ftw!). This included checked exceptions, curly braces, and other stuff which seemed to matter for one language only (mostly PHP or Java). Take a closer look on the picture above for these. They are marked with x’s.

So, did I get my gift? Unfortunately not. But maybe someone will dare to build such a language for me – one day. What’s you favorite hated language feature?

The Three Signs of a Miserable Scrum implementation

Probably the ugliest thing about going to conferences is that you pick up a lot of books to read. That even held for XP 2012 in Malmö, Sweden, although I just attended the first day at the tutorial of J.B. Rainsberger & Ruud Wijnands on Agile Coaching. They recommended two books from Patrick Lencioni for my to-read pile at home, The Five Dysfunctions of a Team and The Three Signs of a Miserable Job. While getting close to finishing the latter one, I noticed that the three signs of a miserable job map easily to signs that your Scrum implementation is miserable as well. Here’s the rationale.

Irrelevance

In the book, irrelevance is the second sign mentioned. In my daily work I consider this the probably most important early warning sign. When your team seems irrelevant about the work it is doing, then they are not putting hard efforts in it. They are unlikely to put in extra hours, probably working from 10 to 4, and will not care about the code they are writing, the product they are creating, or the customer to start with.

That’s bad.

Why? Well, if the product is not relevant to your team, then the feedback you get about the product will also be irrelevant. But Scrum is all about feedback. You get feedback every second week in the review meeting; you get feedback every two weeks on your team cohesion in the retrospective; you get feedback every day in the daily standup meeting; you get feedback every second during a pair programming session. But with irrelevant that feedback becomes a waste of time – for you and your team.

Instead, your team should know about the product, they should know the product backlog for the next planning horizon, and they should be able to know why the code they build today matters to someone. In the book, the manager Brian makes people aware about in which way their work is relevant to someone else. With T-shaped team members there are two dimensions in which individual team members make relevant changes to someone around them.

First, there is the product dimension. You should know at least the ProductOwner. As a team members it is even better if you actually know the end customer. Only then will you understand the troubles people can have using your product.

On the second dimension, in a team you contribute the larger product. As a T-shaped team member you have special skills, and a broad general basis of skills. With your special skills you contribute to the team, and help others be more effective. As a tester that means that you can teach your programmers how to come up with better tests. As a programmer you can help automate some particular daunting task for a tester. As a database specialist you can help your tester check results in the database. This is the reason why we prefer pair working a lot: by working together we become aware of how we contribute to the larger team.

Immeasurement

Although software engineering might be an idea which time has come and gone, without feedback on how relevant my work is to someone else, I won’t notice when I miss opportunities to improve my job. If I don’t know if a particular change in my behavior caused a particular change in the relevance of my work to someone else, then I will soon stop paying attention to my work, how it impacts others, and soon my work will become irrelevant again.

But, what should I measure on an Agile team? Considering the T-shaped team member discussion from before, the most relevant things are probably customer satisfaction and team mood. A while ago my then-colleague Bernd Schiffer wrote a blog entry on three different measurements for reporting success of an agile pilot to top management. In it, he proposes to use customer satisfaction, release burn-ups, and a happiness index like a niko-niko calendar. The first and the third measurements seem to be just about the customer and the team happiness. The second measurement is a bit more interesting though.

Why would we need a release burn-up? Because we forgot one other group of people to which our work is relevant as a Scrum team: the management. Especially when introducing a new methodology like Scrum, coming from a background of probably missed release dates, and undercommitment for a long time, a release burn-up provides management not only the necessary transparency for the team, but more meaningfully reminds the team from time to time about these dates.

And as the book The Three Signs of a Miserable Job recommends, I would also make it transparent to the team as a manager that you rely on them to deliver on time, and your team’s work is relevant for you.

Anonymity

That brings me to the final point: anonymity. If your teams don’t know their team mates, their manager, or their customer, then it’s unlikely they can build a good product for these people that should be relevant for them. If team members don’t know each other, they don’t know personal preferences, personal struggles, and they will have a hard time coming along with each other. So, celebrate your successes – every single sprint. Go out for dinner when you delivered a working product increment. Maybe head for a team event out in the evening. Enjoy yourself as part of that awesome team.

Even more, ask your manager to join you after the release has been delivered successfully. Maybe he can step in taking the bill that evening. This might sound touchy-feeling, but if you do work for an anonymous person, you are unlikely to put the best of your effort in.

Finally, if you don’t know your customer, if you don’t know his work, and if you don’t know how she is going to use your product to help them do better work, then you are speculating. Instead leave the office for two or three week, join your customer in the daily work, and then come back, and build the awesome product that she deserves. You will have a better understanding of what is needed, what is giving your customer a hard time, and surely you will have exchanged some war stories from previous products, and you will avoid stepping into the same problems again with your product.

So, according to these three simple measures, how’s your Scrum implementation going today?

What’s next in FitNesse?

The other day I was going through the first few drafts of the German translation of ATDD by Example – A practical guide to Acceptance Test-driven Development. Since some days I had been watching the list of issues that Dan Woodard and Arjan Molenaar were heavily working on some updated to the UI system, and FitNesse in general. Then Mike Scott told me that he just did a presentation at the Agile Testing Days, and used the recent version of FitNesse from the CI-server – and it looked awesome. Putting all together I decided to use new screenshots from FitNesse in the German translation. Until I get to update the English version of the book, here are some screenshots for the next version, which should be officially announced within the next week or so.

This is the main screen from the trafficlights FitNesseRoot. You can see the left bar is gone, the buttons moved to the upper side. Edit and Add are now two directly accessible functions, the remaining functions are still there, but hidden behind the tools button.

The tools button is indeed a menu. The structure is a bit cleaned up now. The functions are still there with properties, where used, and so on.

But the most interesting update is probably the replacement of the rendering engine with the potential to have a WYSIWYG editor when editing pages. Here is the new plain text editor.

And here is the new rich text editor. It looks like other wiki engines now.

The new test results page is also neat.

But probably most important is the new theming support. Here is the minimalistic topnav theme, that ships with FitNesse.

And here is the third theme that ships with FitNesse called mint.

There are also some other bugfixes and changes worth checking them out. Once the release will be out, there are going to be some release notes that will list all the changes that went into it. The theming support and the new wiki engine alone are worth the upgrade I think. This is a long overdue upgrade, and it goes in the right direction for business users to use an acceptance test framework.

Good work, you guys from the FitNesse crew.

Zero-order measurements – a primer

On my last blog entry I introduced some zero-order measurements for agile software teams which I use quite often. One reader asked for an explanation:

Could you elaborate more about zero-order measurements? What does it mean?

Here is the primer.

Actually, Jerry Weinberg writes about zeroth-order measurements in his book Quality Software Management Volume 2 – First-order measurement. He has more to say on the topic, and I must admit that I forgot most of the important things since three years ago when I read the book. So, this is my definition of zeroth-order measurements – or zero-order measurements.

A while ago Michael Bolton wrote a great introduction to the different measurement systems in his article Three kinds of measurement and two ways to use them. Let’s contrast zeroth-order measurements to first-, second-, and third-order measurements according to the definitions in Bolton’s article.

First-, second-, and third-order measurements

First-order measurement, [Jerry Weinberg] says, is what we need to get started. [...] first-order measurements “are unobtrusive, or minimally obtrusive, and can be used without a whole lot of fuss. They help give you a lot of important information that can lead to other information or, in the best case, to immediate action if needed.

First-order measurements remind me of Daniel Kahneman’s System 1 decision-making that he describes in his book Thinking fast and slow. While driving our car we make a lot of immediate decisions influenced by a lot of first-order measurements like how fast the car is running currently without looking on the meter. We do a lot of first-order measurements when walking in a crowded street. We measure the personal comfort zone of the people around us, and try to steer our way through the masses without knowing how far each of the other pedestrians is to us.

First-order measurements provide us with immediate action. We use them nearly subconsciously, and can make quick decision based upon them – even though these decisions will not always be the most perfect ones, but satisficing enough.

Second-order measurement focuses on questions like What’s really happening? and How is it changing? tending to be more quantitative, subject to more refined models, and generally busier than first-order measurement. It is often assisted by external instruments to supplement or refine direct sensory intake. In particular, metrics–mathematical functions that relate objects or events to numbers via a model–are second-order measurements.

Second-order measurements consist of replacement measures. For example, if we measure the amount of lines of code a programmer is producing as a replacement measurement for their productivity, we are not really measuring the productivity, but some clues that might or might not be proportional to the thing we would like to measure. Another example is code coverage in order to assess the quality of automated checks behind a particular system, or requirements coverage for the state of a traditional test project. We are not really assessing the quality of the testing being done, and we are absolutely neglecting the thought that there might be unstated requirements.

But Second-order measurements resonates to the car situation when looking at the meter in order to decide whether to slow down, shift gears, or find out more about the fuel consumption of your particular driving style.

[Third-order measurement] is the kind of precise, highly quantitative measurement that supports the physicist’s search for new natural laws. It helps us answer the question What happens? in a universal and general sense.

Third-order measurements provide the basis for laws. Laws in science neglect the human impacts like variability based upon individuality. These seem to really be on a even higher level than second-order measurements – like most KPI systems I have seen.

Zeroth-order measurements

With this background, what are zeroth-order measurements? Stating the obvious, they are one level more subconscious than first-order measurement. When I enter a project, and one of my zeroth-order measurements starts to alert me, I know that something is really screwed, and I have to raise attention to this problem or threat. It’s the thing that kept the kids from the plane in the movie Final Destination 2 – a sense that there is something obviously threatening even fatal to happen soon – and we must do something about it, now.

A zeroth-order measurement is a quick qualitative assessment based on my own experiences and my baseline from the various books I have read, that tell me whether everything is all right, or I should start to worry. They are a bit more than intuition, but intuitionalized the knowledge and experiences from my past and my peers. When they alarm me, I know it’s urgent, dramatic, and sometimes even fatal.

I hope this description and comparison helps to see the zeroth-order measurements for agile projects in the right context.

7 Zero-order measurements for agile projects

About two years ago I read Quality Software Management Volume 2 – First-order measurement from Jerry Weinberg. In it, he explains the differences between first-order and second-order measurements. The latter is a replacement measurement. Instead of measuring the thing, we measure something that we substitute for the thing that we are measuring. For example, measuring code coverage usually is a second-order measurement for test quality. It does not really measure the quality of the underlying tests, since you don’t know how many assertions lie behind the covered lines of code. In the same book, Weinberg also provides the concept of zero-order measurements for projects. A few months ago I was surprised that these seem to be focused on traditional projects, rather than agile ones. Since then I decided to come up with zero-order measurements for agile projects. So, here are some of the things I look for when entering a new client or company.

How much communication is not taken place due to team organization?

Team organization consists of how the teams are cut if you have multiple ones, how far apart team members sit, and how far they have to walk in order to get meaningful answers from other team members on the same team, on another team, or from their product owner or product champion. More often than not sitting people far apart leads to sub-optimizing, distrust, and silo-behavior. Things might get worse when you hire contractor teams from different companies, and ask them to work together. I saw teams sitting in the same physical room, but when it comes to information exchange, even ten meters become an impediment.

Can anybody on the project team deliver me a holistic picture of the problem that their application tries to solve for the business?

Agile software development takes into account the business problem. If I can merely get an overview of the piece of product a particular developer is working on in technical terms, I sense that the underlying is not understood well enough. If the problem is not understood, how can we be certain that the work we are doing is not a waste of time? Most of the time, I have to introduce ATDD, Specification by Example, and a holistic view on the business side of the program to fix that.

What’s the lead time between introducing a bug in the system and finding it?

Bugs are waste. The later we find them, the more waste we have in our process. The shorter we can keep the baseline between introducing a bug in the source code, and finding that bug with some automated checks or manual exploratory tests, the fewer waste we deal with in our process. Usually I dive deeply into the continuous integration system. How many unit tests are there? How long does the build take? How many external dependencies which the team might not have understood are there? Does the team use static code analysis? Pair programming? These all give some clues to the degree of technical excellence in the team.

How defensive act people on the project when I start asking questions?

I am quite aware that I can be very nit-picky and offensive at times. However, when I sense that people are overly defensive to my questions, I sense that the whole environment might be based on fear and mistrust rather than a trustful environment where people on the project can contribute meaningfully. It’s hard to act openly in such an environment. So I know, that my highest priority might be to shift the thinking from a Theory X to a Theory Y mindset.

What are the current experiments from the last retrospectives? Are they followed up on?

In order to continually improve, agile methodologies put retrospectives in place. As many thoughtleaders I think that regular retrospectives are the most powerful tool in any agile implementation – when done well. If it’s just another boring meeting with some boring or dreaded outcome, then there is probably another underlying problem that will keep the team from improving. In this situation we should fix the retrospectives first. Only then will emergent and continuous improvements start to step in.

What’s the state of the informative workspace?

Does the team have a physical board that invites team member to collaborate rather than manage and hide information in an electronic tool? How open is the team to provide information regarding their current state in the iteration? Regarding their state for the next release? How about the impediments and bugs fed back from production? The informative workspace should provide not only positive but also negative information, and team members should be open to answer questions regarding the state of the project, even and especially when there are clear problems i.e. in their velocity.

How empowered is the product champion, product owner or on-site customer?

Especially in hierarchically driven environment like most enterprises that I have seen, there are product owner in their so-called Scrum implementation that are not empowered, driven by the politics of the enterprise solely. That might mean that they simply work nine to five on the backlogs that their bosses provided them. That is not real empowerment, and the whole project will suffer from it long-term. When I sense a weak or poorly empowered product owner, I either try to fix the situation by talking to the upper boss, or by working towards replacing the product owner with the real product owner – thereby making the boss of all the ten product owner realizing that he really cannot do all the work on his or her own. Only when the product owner does make critical decisions regarding priorities and business value, is the team able to work effectively. Otherwise it will suffer from fighting the cases for the product owner or become demotivated by the ever-changing priorities in the different business areas.

These are my most immediate zero-order measurements when entering a new team or company. I think there are more, but these are probably the most important ones to start with. What else do you look for?