Markus Gärtner's Blog, page 3

Imagine…

Imagine a world of work in which we no longer fight about agile or not agile, Scrum or not Scrum, Kanban or not Kanban.

Imagine a team that continuously adds value while providing the needed information for the business to have the company thrive.

Imagine what would be possible in such a world, and what would stop working.

I think at the heart of agile software development once stood this imagination, resulting in all the different things we see in the agile cosmos today.

Unfortunately, this imagination sort of has been replaced by all the discussions we have around this vs. that. To maybe bring back these initial driving thoughts, I send you off to the weekend with your own imagination, hoping that you will bring back that agile essence next week.

Release trains – let’s critique the metaphor

A couple of years back, while I was involved in a group that eventually created the ScALeD principles, we were of course discussing the benefits of the different scaling approaches out there. One of the participants – I think it was Andreas Schliep – mentioned to me that the release train concept in the scaling approach that Mike Beedle always referred to as S_Fe was pretty clever. Since I spent some amount of time on trains in the past twelve years, I tend to disagree. Let’s see how I perceive the release train metaphor based on my experiences in the German train infrastructure.

The only picture I managed to take upon arriving in Bielefeld Hbf. after riding the ICE train called Bielefeld.Linear tracks

I recall an earlier critique I heard from Dave Snowden. Basically, he said that a train runs on linear tracks, and oftentimes it’s impossible to change directions when you are on a linear track. Why is that a bad thing?

The agile world tries to address complex problems. Complex problems can be defined as “you will find out new things along the way”. Well, if you’re on a train on a linear track, and find out new things that might shift your desired destination, it’s hard to change course. Obviously.

But it gets worse when you experience the train situation in the real world. This week, I was headed to Dresden from my hometown close to Bielefeld. Before October there used to be a direct train connection from Bielefeld to Dresden. But since October that line no longer operates, so I need to take a different route over Berlin. Usually, it’s a 3-4 hour train ride to Berlin, then another 2 hours to Dresden.

Unfortunately, there has been a crash of trains on the tracks towards Berlin, and the cleanup activities will take another week or so before the fast route is enabled again. So we were diverted from Hannover to Uelzen over Stendal to Berlin. Since there had been snow on Monday in Germany, some trains were running late, so I was glad to hop on a one-hour earlier train heading toward Berlin. I arrived there three hours later than initially scheduled. Why?

All trains were diverted between Hannover and Berlin through that route. This also affected the counter-direction from Berlin to Hannover. On the route, there is a single track serving both directions with some points where trains can pass by each other. So, between Uelzen and Stendal we spent the majority of time mainly waiting for by-passing trains on the single-track course.

Relating back to release trains, if you want to or have to change course, make sure there is enough side-track capacity. Otherwise, you will spend most of your time just waiting.

But it gets worse.

Trains are on time

Anyone who has recent experience riding a train somewhere in Germany probably laughed at this headline. I hear similar stories from some other countries, yet I also hear on-time pride from other countries as well. On my way to Dresden this year, the single-train connection up until October managed to get me seven minutes ahead of schedule to my destination three times this year. Since I had some spare time this week, I was thinking through why this is so rare.

If you have a train scheduled to stop at three stops along the route, people that want to ride that train show up around the scheduled departure of the train. If the train arrives seven or even twenty minutes ahead of schedule, it will stop there until the planned departure to make sure to get everyone on board.

On the other hand, if the train runs five or twenty minutes late, well, there is close to no measure to get ahead on that lost schedule.

But it gets even worse. Since that one train is now late, the remainder of the schedule for the train station, indeed the whole journey is now messed around with. Assume your train is twenty minutes late, but another train in the same direction was scheduled just ten minutes behind your delayed train. Since the other train can’t overtake the late train, that train will also be delayed by at least ten more minutes.

And for all the three stops your train makes on its journey, the schedule will be screwed up further for the net effects in play.

Then, consider the train running to its final destination before changing directions, and heading back to its origin. Those twenty minutes of delay will have a postponement effect on the later run as well. Anyone who has boarded the famous doubled-ICE trains from Berlin towards Düsseldorf or Cologne knows this.

So, relating back to release trains, if you slightly have to postpone a release train for whatever reason, be aware of the ripple effects that will cause – especially when the coordination of multiple interdependent component teams is necessary to catch up, you will likely be in a situation pretty similar to the ones in real-life trains in Germany.

But it gets worse.

Getting ahead of the schedule? How?

How was I able to arrive seven minutes ahead of schedule in the first place? Well, I’m so glad you asked.

Here is an abbreviated schedule from that train run as I recall it:

BielefeldHerford (1 minute stop)Minden (1 minute stop)Hannover (20 minutes stop)Magdeburg (15 minutes stop, change of travel direction)Köthen (1 minute stop)Halle (Saale) (5 minutes stop)Leipzig/Halle airport (1 minute stop)Leipzig (20 minutes stop, change of travel direction)Riesa (1 minute stop)Dresden-Neustadt (1 minute stop)Dresden Hbf. (final destination)

As you can see, there are several longer stops along the route. Some of them were quite purposeful, for example, Leipzig Hbf. has a dead-end train station. So, trains run into the central station, but can’t directly continue their journey. Instead, the train driver needs to exit on his end of the train, go all the way to the other end of the train, and turn everything ready before the train can leave the station again, having changed its travel direction for the passengers. In Hannover usually, there is some material re-supply for the onboard restaurant as well as some personal change halfway along the route.

My point is, if you want to occasionally be able to deliver early with a release train, you have to buffer your schedule by a lot.

Bottom line

So, the bottom line is, that in my experience trains are rarely on time for the systemic effects that take place when you have dependencies and deal with them appropriately. Trains are rarely on time because no traveler wants to have too many buffers built into their schedule, and if something unexpected happens, it’s hard for trains to change course in a meaningful, yet time-saving way. That’s why I think the idea of a release train is a terrible to start with.

Remembering Jerry Weinberg: More Secrets of Consulting

It’s been four years since – sadly – Gerald M. “Jerry” Weinberg passed away. Ever since then, I struggled with some public mourning about him, until recently I had just the right idea. On a weekly basis, I will publish a review of a book I read that Jerry either wrote himself or is about some of his work. Today, we continue the topic of consulting as I picked More Secrets of Consulting – The Consultant’s Tool Kit published by Dorset House in 2002.

More Secrets of Consulting builds on Jerry’s Secrets of Consulting, yet, can be read stand-alone, I suppose. What I recall vividly from this second consulting book is the courage stick and the Law of Strawberry Jam:

The Law of Strawberry Jam
As long as it has lumps, you can never spread it too thin.

page 3

as opposed to the Law of Raspberry Jam stemming from his earlier book:

The Law of Raspberry Jam
The wider you spread it, the thinner it gets.

page 2

Jerry had a particular model throughout his book depicted with several icons. He introduces it as Virginia Satir’s tool kit consisting of 16 elements:

The Wisdom Box: the ability to know what’s right and what’s not right for me.The Golden Key: the ability to open up new areas for learning and practicing, and to close them if they don’t fit for me at this time.The Courage Stick: the courage to try new things and to risk failure.The Wishing Wand: the ability to ask for what I want, and if necessary, to live with not getting it.The Detective Hat: the ability to examine data and to reason about those data.The Yes/No Medallion: the ability to say yes, the ability to say no (thank you), and the ability to mean what I say.The Heart: the ability and willingness to put my heart into my work.The Mirror: the ability to see myself and to seek and use feedback.The Telescope: the ability to others and to bring them closer to my understanding than my naked brain and eye can manage.The Fish-Eye Lens: the ability to see the context, what surrounds me and others and influences us as we work together.The Gyroscope: the ability to be balanced to use all of my tools, and to be congruent and centered.The Egg: the ability to grow, develop and learn, using all the parts of myself that I need.The Carabiner: the ability to ensure my safety and to not take unnecessary risks. The Feather: the ability to tickle myself and others, and to not take myself or others too seriously.The Hourglass: the ability to make time for the good and to make good use of time.The Oxygen Mask: the symbol for a balanced life.

Each chapter in the book is dedicated to one of these 16 tools for the consultant toolbox.

Just reading through the description of the 16 tools in the consultant’s tool box makes me reflect on my past consultant and non-consultant life, and consider re-reading Jerry’s more secrets of consulting. The mindful eye probably has caught Satir’s congruent communication model in the 16 tools as well as Jerry’s open considerations for getting balance into his consultant’s life.

Among the lessons I cross over while skimming through the book, I find a particular reference to Lullaby Language in there. Terms like “always”, “never”, etc. hint at some kind of lullaby language being present. I found a recent example at a client. As winter approaches here in Western Europe, and we start to heat not only our homes but also our offices, the front door greeted me one morning with “Please always keep the door closed.” My remark “But I can’t enter or exit the building if I keep the door always closed” received a to-be-expected eye-rolling reaction, though.

As I work through re-visiting Jerry’s More Secrets of Consulting for this review, I sense the urge to re-read both his consultant’s books. I hope my just brief thoughts here may have you conclude similarly.

Some personal gem

Similar to the Quality Software Management series, I created a document with a listing of rules, laws, and principles from the consulting series of books for my own reminders and easier reference. Typos are mine, not necessarily Jerry’s.

Secrets-of-ConsultingDownload

Who knows what is good or bad?

At times, I find myself judging things around me. As I consistently identified as INTJ in the MBTI tests I took, this comes as no wonder for me. However, judging a situation can be a dimension in the MBTI preferences that I may want to work on, as I keep on re-discovering the wisdom of Taoism in my life. Let me explain with a quote from a Tao book.

When an old farmer’s stallion wins a prize at a country show, his neighbor calls round to congratulate him, but the old farmer says, “Who knows what is good and what is bad?” The next day some thieves come and steal his valuable animal. His neighbor comes to commiserate with him, but the old man replies, “Who knows what is good and what is bad?” A few days later the spirited stallion escapes from the thieves and joins a herd of wild mares, leading them back to the farm. The neighbor calls to share the farmer’s joy, but the farmer says, “Who knows what is good and what is bad?” The following day, while trying to break in one of the wild mares, the farmer’s son is thrown and fractures his leg. The neighbor calls to share the farmer’s sorrow, but the old man’s attitude remains the same as before. The following week the army passes by, forcibly conscripting soldiers for a war, but they do not take the farmer’s son because he cannot walk. The neighbor thinks to himself, “Who knows what is good and what is bad?” and realizes that the old farmer must be a Taoist sage. 

from the Tao Book and Card Pack by Timothy Freke

As the story tells, some things considered bad today may have another viewpoint tomorrow. When I judge a situation I take into consideration today’s state of affairs and how the world surrounds the situation. From a totally unaware origin, those same circumstances might suddenly change my today’s judgment.

This lesson is especially important in my coaching, and – to be honest – I am bad at this. Oftentimes I find myself jumping to conclusions – even in the previous sentence. Who knows what’s good or bad about my quick judgments? Sometimes maybe they help, and sometimes they don’t. It is what it is. In order to grow, I need to let go of thoughts that bring me down, or cheer me up and just enjoy the moment.

That’s one thing I wished I would be better at. But who knows what’s better or worse?

Celebrate failure

A colleague of mine shared something online that got my brain working. Just earlier I pointed out a lesson to another coach that I learned from Diana Larsen regarding errors or failures.

For the agile, an error is information; for the fragile an error is just an error.

— Benjamin Igna (@Numb3rPi) November 14, 2022

Let’s dig into this.

First of all, since I worked through some Jerry Weinberg books recently, I am tempted to bring up a favorite quote of mine:

No matter how it looks like, everything is information.

(I could not find that immediately in my reminders, unfortunately. Maybe I misquoted him here.)

So, errors are – among other things – first of all also information. Errors point us to problems in our processes that we may want to fix.

From here, it gets complicated. Since we designed the processes in our organizations for some time, we found pieces of them useful at the same time. However, we may also have become attached to how the process works – either because we had a particular role in designing the process and don’t want to let go, or because it has served us well in the past at some point.

This puts us into some particular psychological problem. Do we want to let go of the past, and try something new? Or don’t we want to make that investment? Unfortunately, if we find ourselves attached to the processes, we may have some sentiment toward the processes, and start to argue from an emotional standpoint rather than a logical one.

Even though, there might be some people in the room trying to argue from a logical point of view, emotional and logical arguments can’t convince one about the point of the other.

Diana Larsen taught me a while ago that we should instead see errors, problems, and failures as learning opportunities. Rather than feeling depressed because we realized that we made a mistake, we should yell: “Hooray! I can learn something new!” This kind of positive mood also keeps our brains in a problem-solving state where we can actually imagine a way to fix the underlying problem.

So, compared to more traditional thinking, we celebrate our failures and mistakes in Agile in order to be able to learn from them and improve as soon as possible. At least in my experience, if this crucial part of the Agile mindset is missing, a dynamic of information hiding for fear of punishment comes up, exposing us to less openness and respect among each other.

So, celebrate your mistakes, as you can learn new things from them.

Remembering Jerry Weinberg: The Secrets of Consulting

It’s been four years since – sadly – Gerald M. “Jerry” Weinberg passed away. Ever since then, I struggled with some public mourning about him, until recently I had just the right idea. On a weekly basis, I will publish a review of a book I read that Jerry either wrote himself or is about some of his work. Today, I picked the classic The Secrets of Consulting – A guide to giving & getting advice successfully published by Dorset House in 1985.

The Secrets of Consulting is a classic book of Jerry’s. As the subtitle suggests, it’s not merely just about giving advice, but especially more so about receiving advice from someone else. At first thought, I notice, I hardly remember anything attributed to this book. While going through the table of contents and especially my reminders document, I come to realize how many of the Secrets of Consulting lessons I internalized and no longer attribute to the book per se.

“No matter how it looks like, it’s always a people problem.”, Rudy’s Rutabaga Rule, when you solve the number one problem, the number two problem gets a promotion to the new number one, and the like are all lessons I regularly notice, re-visit, and cite.

Jerry has collected a thoughtful set of lessons for everyone in this book, it seems. Not only does he cover the consulting business, but also the everyday advice that we might find ourselves offering. Of course, there is also a strong connection to the consulting business, but don’t fool yourself into the trap of thinking you won’t take away anything from this book if you are not a consultant at your current job. If you are, you will be surprised to find lessons about marketing and sales here as well.

My personal stories include one occasion when I reached out to Jerry and asked him about the 9th law of marketing:

Spend at least one-fourth of your time doing nothing.

The Secrets of Consulting, page 177

I had reached out to ask him how he meant that. He replied explaining that he meant that as a consultant we should take our time to re-process our engagements before jumping into the next consulting engagement. Rather than keeping us too busy to reflect on what is happening, we should dedicate time aside to do exactly that.

Another deep lesson I had was during PSL when I went for dinner with Jerry and Esther Derby. Over the course of dinner, I brought up my current coaching engagement. Both pointed out a lesson from Secrets of Consulting to me, that I did not incorporate back then. In essence, it had to do with the psychological contracting towards the client. I was glad to learn that early in my career, yet, I continue to learn this lesson with improvements from engagement to engagement.

So, no matter where you find yourself, in a consulting job or not, to some extent we are providing advice to our outside world. If you want to see pathways to improve here, this book is a great starter, and I strongly recommend reading it.

Some personal gems

Jerry signed my copy of Secrets of Consulting when I met him back in May 2011 during my Problem-solving Leadership course.

Similar to the Quality Software Management series, I created a document with a listing of rules, laws, and principles from the consulting series of books for my own reminders and easier reference. Typos are mine, not necessarily Jerry’s.

Secrets-of-ConsultingDownload

What worried me about running, tested features

I recall when I read the #noestimates book, there was a concept that felt strange to me – and it still does. Without spoiling too much, at one point the concept of running, tested feature (RTF) is introduced. Let’s explore my thoughts together.

What is a running, tested feature?

So, the basics are, a running, tested feature is similar to something of value for the customer or user. In the book, the author makes the point to primarily measure the progress of a product on the product upon running, tested features, something of value to the customer or user.

Of course, a particular might not be in the position to work on running, tested features during the Sprint or cadence. Then that team will have to break down that valuable thing into smaller pieces that they feel comfortable delivering and have these smaller, probably not-valuable things in their Sprint or cadence.

Still, we continue measuring our progress on those valuable things.

What were my thoughts?

Don’t get me wrong here. I totally buy into the idea to work on smaller things, if you are not able to deliver something valuable to your customers or users out of the box.

On the other hand, isn’t there an opportunity laid bare in front of our eyes? If we as a team strive to improve continuously toward the goal of being able to work on only running, tested features, something valuable to our customers and users, wouldn’t we be better off? We might not be there, yet, and there may still be a huge gap before we are eventually able to deal with only running, tested features, but isn’t striving towards that kind of perfection the thing we should be working on as our top priority?

I think it is.

And then, I had a deja vu when I was reading about stream-aligned teams in the team topologies, and three other types of teams. It was the same lack of perfection perspective, that bothered me there as well.

Agile Songs – Let there by Scrum

Sometimes while reading along song lyrics, I get some silly inspiration. One of these days, recently I listened to Let there by Rock by AC/DC and got the following idea for an Agile version of the lyrics.

(original lyrics)

In the beginning
Back in 1994
Man didn’t know ’bout a Sprint Review show
And all that JIRA, oh

The corp man had the waterfall
The consultant man had the RUP
No one knew what they was gonna do
But Sutherland had the news, he said

Let there be plans, and there was plann’ng
Let there be dailies, and there was the Daily
Let there be review, there was review
Let there be retro, there was retro
Oh, let there be Scrum!

And it came to pass
That Agile development was born
All across the land every Scrumin’ team
Was blowin’ up a storm

And the Scrum Coach got famous
The Product Owner got rich
And at every conf’rence there was a superstar
With a seven year itch

There was fifteen million stories
Learnin’ how to poker
And you could hear the fingers pickin’
And this is what they had to say

Let there be plans, dailies, review, retro
Oh, let there be Scrum!

One night in a firm called the Easel Corp
There was a 42 velocity Scrumin’ team
And the chatter was good and the chatter was loud
And the CEO turned and he said to the crowd:
“Let there be Scrum”

Remembering Jerry Weinberg: The Psychology of Computer Programming

It’s been four years since – sadly – Gerald M. “Jerry” Weinberg passed away. Ever since then, I struggled with some public mourning about him, until recently I had just the right idea. On a weekly basis, I will publish a review of a book I read that Jerry either wrote himself or is about some of his work. Today, I picked the classic The Psychology of Computer Programming in its Silver Anniversary Edition from 1998, the original being published in 1971.

The Psychology of Computer Programming is another of Jerry’s books that I hardly remember anything about. So, let me go through the table of contents and maybe skim through the book. I might be ending up picking references here again.

The book is split up into four major parts (if you don’t count the epilogue as its own fifth part):

Part One: Programming as human performance is separated into the chapter Reading Programs, What makes a good programmer, and How can we study Programming. Part Two: Programming as a social activity is split up into chapters on The Programming Group, The Programming Team, and the Programming Project. Part Three: Programming as an individual activity consists of chapters on Variation in the programming task, Personality factors, Intelligence or problem-solving ability, and Motivation, Training, and Experience. Finally, Part Four: Programming Tools has three chapters Programming Languages, Some principles for programming language design, and Other Programming Tools.

The book initially was intended to serve as a basis for a training course, or at least did not forbid it. You find questions for reflection at the end of every chapter. My 25th-anniversary edition also has additional notes 25 years later on each of the chapters, including the foreword.

The beginning of the first chapter directly catches my eye:

Some years ago, when COBOL was the great white programming hope, one heard much talk of the possibility of executives being able to read programs. With the perspective of time, we can see that this claim was merely intended to attract the funds of executives who hoped to free themselves from bondage to their programmers.

Oh, boy, those lines aged pretty well. Or not so much, depending on what your current hopes are.

From the outset, the title of the book is pretty self-explanatory. Since managers could not read code on their own, they had to understand how programmers tick. Thus Jerry wrote about the Psychology of Computer Programming for managers to make better decisions for their programming staff. Personally, this makes me wonder why I rarely encounter a manager that read some of these lines in the half-century since Jerry published the original edition of this book – or who does not act as he read it.

Similarly, the questions sections at the end of each chapter are split up into two main categories: for managers, and for programmers. Just going through the table of contents, I recognize that Jerry wrote about all these before being largely influenced by Virginia Satir’s teachings later in his career. In essence, he captured his wisdom and experience here since having worked on programming teams and organizations since Project Mercury was set out to put a person into the Earth’s orbit, where he collected his first experiences as a programmer – and as a computer (one of his early job titles).

Throughout the book, you will likely encounter some programming languages, some facts, and some deep questions as well as a personal reflection by Jerry 25 years after having written the original, and how it stood up the test of time. While reading through the reflection on his original epilogue, I get a bit sad though:

[…] if you’d like to share some of your ideas, observations, or experiences with me, go to my website and send me e-mail. You should always be able to reach me from there, at least as long as I’m still around. Hopefully, that will be long enough for me to write a Golden Anniversary Edition of The Psychology of Computer Programming.

Sadly, it wasn’t long enough for the Golden Anniversary Edition, but I recall sending Jerry many e-mails over the years that he was still around. Matt Heusser once put it to me this way:

It’s always amazing to get e-mail from Jerry.

Indeed, Matt, it always was something special.

Testing and Management Mistakes: The Inner Team

I found this old draft blog entry while going through some older blog entries. Since this has been laying around for many years now, I figured, it should be time to publish it now. Enjoy.

A couple of years ago Michael Bolton started a blog series on testing and management mistakes, to which I contributed four follow-up blog entries with an introduction, replacing blaming with placating, congruent responses, and causes. All of this was based on a single psychological model, or better, my understanding of it after having read through most of Jerry Weinberg’s work.

Recently I started to dive into some topics in psychology. While working through work from Schulz von Thun, I remembered this series when I crossed the idea of the inner team. I decided to revisit the original conversation and discuss it in the light of the inner team.

Schulz von Thun describes the inner team as a collective of personalities that each of us develops and carries with us. In any conversation, we face the struggle of forces for or against an argument. We also have a team leader, which could be stronger developed with some of us, or weaker, thereby yielding to different responses – sometimes even incongruent ones depending on the inner team member that cries the loudest at any given time.

Let’s revisit the conversation of the project manager asking a tester to work over the weekend, and take a closer look at the inner team within this tester.

A note of caution: I derived the following inner team conversation completely on my own. Since this conversation will vary from person to person, even from one communication partner to another, it is likely that you will find different team members in your inner team.

I will also put the original conversation in blockquotes to distinguish between the external communication and the one from the inner team. There are several team members raising their voices during the whole internal conversation. I will introduce them just in time when they enter the (inner) scene.

Magnus the Project Manager: “Hey, Tim. Listen… I’m sorry to give you only two days notice, but we’ll be needing you to come in on Saturday again this week.”

As a first reaction to Magnus entering the room, Tim puts up an ensemble of inner team participants: the subordinate employee, the husband, and the critical thinker.

The husband: “I haven’t seen my family for eight weekends straight. How can he dare to even consider approaching me again?”
The subordinate: “Oh, be careful. It’s your boss. You can’t talk against him. He will fill out your job evaluation when this project gets finished.”
The critical: “C’mon! This will never happen! This project has been delayed the past two years, and anyways, Magnus is wasting more time drawing these Gantt charts than actually managing the project!”
The husband: “Exactly. And our two children already forgot my name!”
The hero: “Sure, but without us, Magnus may be doomed. I am the only one that can save this project! And I will!”

The inner team is unsure how to deal with this struggle. There is a lot of conflict potential. Tim feels he has to respond. His inner leader did not yet solve the situation. So, he takes the approach to spend minimal effort on external contact with Magnus while trying to settle the conflict of his inner team.

Tim the Tester: “Really? Again?”

Magnus: “Yes. The programmers upstairs sent me an email just now. They said that at the end of the day tomorrow, they’re going to give us another build to replace the one they gave us on Tuesday. They say they’ve fixed another six showstoppers, eight priority one bugs, and five severity twos since then, and they say that there’ll be another seven fixes by tomorrow. That’s pretty encouraging—27 fixes in three days. That’s nine per day, you know. They haven’t had that kind of fix rate for weeks now. All three of them must have been working pretty hard.”

The hero screams: “Yes, this is our chance to get lots of fixes out the door and rescue our face from so many disappointed customers.”
The husband: “Yeah, or we could be the hero for our family and actually be an example for the kids.”
The subordinate: “But it’s your boss. He will be so proud of you, probably giving you a raise in your next evaluation.”
The critical: “Oh really? Do you think those stupid developers this time really fixed the bugs and did not introduce any new ones? We’ll be continuing to come in on weekends for the next months at this pace.”

The leader steps onto the stage, takes the last comment from the critical and responds:

Tim: “They must have. Have they done any testing on those fixes themselves?”

Magnus: “Of course not. Well, at least, I don’t know. The build process is really unstable. It’s crashing all the time. Between that and all the bugs they’ve had to fix, I don’t imagine they have time for testing. Besides, that’s what we pay you for. You’re quality assurance, aren’t you? It’s your responsibility to make sure that they deliver a quality product.”

The critical jumps right in: “Oh, really? You don’t think there will be any problems happening there? Despite the builds failing. This weekend will be a total waste of time. I think we should go with the husband’s suggestion and pass on this.”
The quality advocate appears on the stage: “But we really should help the team to see the quality they build.”
The husband jumps in: “I think this can wait until next week. We will be able to show the quality of the product by then still.”
The critical: “Well, and we really can’t test quality into a shitty product after the fact.”

The leader picks up again on this critical comment and responds to Magnus:

Tim: “Well, I can test the product, but I don’t know how to assure the quality of their code.”

Magnus: “Of course you do. You’re the expert on this stuff, aren’t you?”

The quality advocate shines on his mentioning: “Of course I know.”
The quality advocate pushes the husband slightly off-stage.
The critical is still screaming out loud: “Forget it, it’s too late. We should have started days ago on this.”

Tim: “Maybe we could arrange to have some of the testing group go upstairs to work more closely with the programmers. You know, set up test environments, generate data, set up some automated scripts—smoke tests to check that the installation…”

Magnus: “We can’t do that. You have high-level testing to do, and they have to get their fixes done. I don’t want you to bother them; it’s better to leave them alone. You can test the new build down here on Saturday.”

The husband fights his way back on center-stage: “Really, your wife and your kids miss you for all the weekends you have been absent from the family business.”
The remaining characters stay silent.

Tim: (pauses) “I’m not sure I’m available on Sa…”

Magnus: “Why not? Listen, with only two weeks to go, the entire project depends on you getting the testing finished. You know as well as I do that every code drop we’ve got from them so far has had lots of problems. I mean, you’re the one who found them, aren’t you? So we’re going to need a full regression suite done on every build from now until the 13th. That’s only two weeks. There’s no time to waste. And we don’t want a high defect escape ratio like we had on the last project, so I want you to make sure that you run all the test cases and make sure that each one is passing before we ship.”

The hero gets spot-lighted: “You see? We really can shine here.”
The quality advocate: “Really? The builds are failing. Shouldn’t that be enough quality information to deal with now before we put out the heavier quality tools?”
The critical turned red and explodes: “What kind of heavier do you mean? The test suite is total crap and not covering anything if at all.”

Tim: “Actually, that’s something I’ve been meaning to bring up. I’ve been a little concerned that the test cases aren’t covering some important things that might represent risk to the project.”

Magnus: “That might be true, but like I said, we don’t have time. We’re already way over the time we estimated for the test phase. If we stop now to write a bunch of new test scripts, we’ll be even more behind schedule. We’re just going to have to go with the ones we’ve got.”

A new figure appears on stage, looking professional with glasses and a binder of notes, the quality professional: “Well, test automation and scripted tests are one thing. If we think we’re overseeing something, maybe we should explore the product more.”

Tim: “I was thinking that maybe we should set aside a few sessions where we didn’t follow the scripts to the letter, so we can look for unexpected problems.”

Magnus: “Are you kidding? Without scripts, how are we going to maintain requirements traceability? Plus, we decided at the beginning of the project that the test cases we’ve got would be our acceptance test suite, and if we add new ones now, the programmers will just get upset. I’ve told them to do that Agile stuff, and that means they should be self-organizing. It would be unfair to them if we sprang new test cases on them, and if we find new problems, they won’t have time to fix them. (pause) You’re on about that exploratory stuff again, aren’t you? Well, that’s a luxury that we can’t afford right now.”

The quality professional throws his binder into a corner and leaves the stage fuming.
The husband can’t stay quiet: “Your family needs you more than this shipwreck.”

Tim: (pauses) “I’m not sure I’m available on Sa…”

Magnus: “You keep saying that. You’ve said that every week for the last eight weeks, and yet you’ve still managed to come in. It’s not like this should be a surprise. The CFO said we had to ship by the end of the quarter, Sales wanted all these features for the fall, Andy wanted that API put in for that thing he’s working on, and Support wanted everything fixed from the last version—now that one was a disaster; bad luck, mostly. Anyway. You’ve known right from the beginning that the schedule was really tight; that’s what we’ve been saying since day one. Everybody agreed that failure wasn’t an option, so we’d need maximum commitment from everyone all the way. Listen, Tim, you’re basically a good guy, but quite frankly, I’m a little dismayed by your negative attitude. That’s exactly the sort of stuff that brings everybody down. This is supposed to be a can-do organization.”

Tim’s leader has completely disappeared from the stage set. Magnus is coordinating Tim’s inner team at this point. His last comments bring up a spotlight on the hero and the quality advocate, eventually leading to him replying:

Tim: “Okay. I’ll come in.”

Some closing notes

Magnus basically is taking over the stage direction here from Magnus. n the dialogue you can see different players being the loudest in Tim’s inner team, eventually coming to the forefront and leading to his responses. Since Tim is letting Magnus take over the direction of his inner team, he eventually is convinced to agree to come in over the weekend.

Virginia Satir had a similar model of a stage set and different actors in our head in one of her books where you can see the scene play come to life. To get out of this dynamic, both Satir and Schulz von Thun start by handing back the role of the stage director to Tim. For that to be successful Tim’s stage director or leader needs to be confident about the direction he wants to go after listening to all the complaints and remarks from the different actors, and finally deciding firmly on how to proceed.

Since this blog entry is already pretty, I don’t dare to explore a more constructive conversation here. I will leave filling in the constructive blanks to my dear, hopefully now better-educated readers. I really look forward to reading about some of the stage plays of your inner teams in this situation.