I planned to write individual posts about new and upcoming workshops, but the rate at which we get invited and accepted to conferences this fall outstrips my ability to post new entries I have to post now, before the conferences themselves are over… I hope you’ll join us for at least one of these. We’ll be doing some hard-core programming workshops as well as more enterprise and facilitation oriented sessions this fall.

First up is Scan-Agile next Thursday and Friday in Helsinki, Finland. Marc already wrote about our Story Testing workshop.  I’m also very much looking forward to participating in the Scan-Agile Open Space, which now has its’ own day.  The main reason for me to return to Scan-Agile this year, is that last year it had very strong participants (and presenters, but good session organizers are only part of what makes a conference worthwile). Having my own unit tests ripped to shreds by critical participants was interesting and valuable. So I’m glad this year all participants get more space. We had some discussion on Twitter about ‘is kanban a failure mode of lean? (and what that means if it is so)’ that merits more than 140 characters… should make for lively open space as everybody involved in that discussion will be there . If I haven’t motivated you to join us, check out Vasco Duarte’s series of motivational posts about Scan-Agile.

Next up is the Practical Product Lines conference , October 20 and 21 in Amsterdam, Netherlands. There we will be hosting a value stream mapping workshop, as described by Marc. We decided to try out more conferences outside our regular schedule of agile conferences – preaching to the choir is fun, and helps us improve our understanding, but going out into the world and sharing what we’ve learned is at leas as valuable. We thought it would be interesting to bring our understanding of value stream mapping, and take participants’ experiences with product lines, should provide an interesting mix.

Freek Leemhuis of Devnology asked us to send in some proposals for the Devnology community day, saturday November 7 in Baarn, Netherlands.  We did, and they chose three of QWAN’s sessions for the program:

Refactoring to concurrency (with Scala) grew out of a series of commits I did for a product I’m developing with Marc, micro-ISV style. We needed some background processing to make our application more responsive, and I wanted to take small steps, be sure that it worked and have everything covered with tests. So I first refactored, until introducing concurrency was just a one character change. This session shows you how to do the same thing, with scala or another language.

Flying Horses – cleaner code in other languages. This session was inspired by a dojo description from Emily Bache (I don’t have the link handy right now, will insert it later). Rob ran with it and tried it out at Agile Open Holland last month. We’ll bring an application written in one language, everybody gets their laptops, a pair to program with and translates that to their favourite language. At first as literally as possible, and then make it ‘more like their language’. Then we will discuss what makes code, e.g. pythonic, javaic, C-sharpish etc. based on the examples we just created.

Give your code some love is a demonstration (a series of prepared katas) of us doing tiny refactorings on code that looks allright at first glance. Tiny refactorings then show that there are quite a lot of things we can do to make the code express its’ intent better. This session was heavily inspired by Ivan Moor and British Mike Hill ’s Programming In The Small workshop at the software craftsmanship conference in London earlier this year.

Jfall, conference of the Dutch Java Users’ group, November 11 in Bussum, Netherlands, sees Rob and me doing TDD As If You Meant It, inspired by Keith Braithwaite’s session of the same name at, again, the software crafsmanship conference in London. Keith kindly gave us permission to reuse the name. We are happy to see more people applying unit testing. Very few, however, seem to be really doing Test Driven Development. In this demonstration we hope to give the audience a taste of what test-first programming can do for you.

Xp Days Benelux, November 23 and 24, Mechelen, Belgium I already described Retrospective Hero with Nicole Belilos of Task24 and Agile Politics – (re)discover the politician in you at XP Days Benelux with Emmanuel Gaillot of Pyxis

and Finally, XpDay London, December 7 and 8th where I’ll be pair facilitating the Open Space with Rachel Davies.

Wille Faler asked on Twitter earlier this week about how people who go to conferences a lot do work. All of the conferences above are one, maximum two days, that leaves plenty of time in the rest of the week to do ‘actual’ work.  The other thing is, writing is a poor medium (for me at least, even though my blog does seem to travel reasonably well these days) to show our passion for software development, going out to conferences helps us connect with other people who are equally passionate about our profession. And sometimes this then leads to actual work. Which leads me to the following:

Shameless plug:

At the moment I’m looking for a new project to work on, either as a developer, agile coach and/or project leader. contact me if you know of a place where my skills would add value. Also, all of the sessions above and more are available as customized in-house training.

Sandra, one of the product owners, explains her point of view, Serge listens intently as facilitator

Now, lets' hear the second group of product owners, with their position

Nicole and I thought it would be fun do design a simulation game around facilitating retrospectives. At first we came up with a sort of board game, but after some brainstorming we thought a role-play would work better – our board game was turning out to be a bit too simplistic for our taste.

These are the benefits we proposed for our session at XP Days Benelux 2009, November 23/24:

• Learn new techniques by applying them to a simulated real world situation
• Experiment with techniques you already know – do something different with them
• Hold an emergency retrospective to ‘get to the bottom of it’ and come up with sustainable solutions quickly.
• Get some fresh ideas to do group reflection on emergency situations and longer timespans

At XP Days we have an hour and 45 minutes, for the try out at Agile Open we decided to see what we could do in a 60 minute timeslot to get as much feedback as possible on our game ideas. For the XP days version we were thinking about playing two simulation rounds, in which the participants get to deal with a) facilitating during an emergency situation and b) facilitating a retrospective over a longer period (weeks or months).

We were most curious about facilitating in an emergency; what we expect to learn from these simulations as hosts is observing facilitators ‘in the wild’ under controlled conditions and seeing how they behave, and what techniques work in which circumstances (we have our preferences, but they do not necessarily end up in the simulation). For the longer-term retrospective part we still would like to do a trial run. contact me if you’re interested in hosting it.

Therefore we designed a role play that happens in a Bank, something went terribly wrong and after the facilitator comes in on a monday morning he or she is asked to facilitate a ‘hero retrospective’ : find out what went wrong quickly and get the group to agree on some actions.One or two participants play facilitator, while the other participants play roles like product owners, helpdesk boss, development team and systems administrators. We give everybody an overview of the situation, and then each role receives an envelope with a more detailed description of what happened from their point of view. This leads to a group situation where everybody has partial information, so one of the challenges for the facilitator is to surface all the relevant information quickly. (I won’t say much more, because I fear that would spoil the simulation in case you come and play it…)

We creatively brainstormed the situation and roles based on our own experiences. And it worked. One of the players asked me ‘does this happen?’ about something that I experienced during a meeting; some of the assignments and poses of the roles seem far-fetched, but things get political when people have to divide resources, and as a facilitator you’d best be prepared to not be surprised about that

You might say ‘that is not a retrospective’, and you may be right; that is something that we want the participants to figure out and discuss in the debrief. And at Agile Open they did. Participants found that for effective facilitation you need to find a technique and style that fits you, the participants and the context. Some ‘participants’ preferred a ‘businesslike’ style, focused on only content, while others seemed to prefer also getting the mood of the people on the table.

In writing this sounds like knocking down an open door, but the emergency role play was pretty intense, with at least one facilitator behaving differently from his own expectations. We really did manage to create a stress situation .

Now we have to pick up the pieces and figure out what to do next with the simulations and the workshop. The participants gave us a good amount of useful feedback. The roleplay worked well, so we are going to keep that, but how to fit it into an overal workshop seems to, ehh, depend . We introduced two techniques before the simulation, and encouraged the facilitators to use one of those two. Next time we may only chose one, and see how that compares between groups, or alternatively (especially in an in-house course where we have more time), start out without a specific suggestion, roleplay and learn from the debrief, maybe explain a technique and try again, and see what difference that makes.

In reviewing the session for XP Days, Pierluigi Pugliese suggested we add observers to the list of roles, and give them specific instructions. That seemed to work well.

Jorrit shares his observations with the group

Since we are operating a kind of pull system for workshops, we asked ourselves beforhand: what do we want to learn from the try-out (does the simulation work? This is the first roleplay I helped create.), and what is the least amount of work we need to do to get that feedback. Therefore we created all the role descriptions in dutch…

Deborah Preuss wanted to participate, and while she speaks and understands a couple of languages, dutch is not among them. So we improvised and gave her, as an observer, the task to observe and interpret body language. Because of this the players learned about the effect of finger pointing, and that they were doing it without realizing it… The debrief was interesting. Deb noted that at some point several players’ body language indicated they knew enough and were finished with the discussion.

Deborah observes body language of one group

From the players’ perspective that was partially true: some of the players were finished with the discussion, not because they were satisfied, but because they realized they had nothing to gain by the meeting, as their concerns went unheard (and unacted upon).

For those of you who asked me what Retrospective Hero was, and what it was about, I hope this cleared it up a bit. I welcome your questions and suggestions. For those of you who participated or observed, we’d love to know what you feel about the game after a few weeks.

In any case, we hope you join us at XP Days Benelux 2009 to experience the extended version

“You have some experience writing unit tests, but wonder how you could get more out of unit testing. Register for the Mastering Unit Testing training to experience how test driven development can make development faster and more enjoyable. You’ll learn how working test-first lets you create better designed code, and understand why unit testing techniques that are ’simple’ in theory can be difficult to practice. Past participants have experienced less defects in production code, as well as higher velocity, which leads to happier clients and more fun in your job!”

See the Mastering Unit Testing page on the iLean site for registration and details. The first course is scheduled for September 24 and 25. After that we’ve also got our Mastering legacy code, November 16 and 17, also in Antwerp.

Televox by d.billy

photo found through Photo Suggest

The Trousers of Reality Book Cover

Barry Evans works as an independent consultant and writer, and is based in France and the UK. I met Barry a few years ago at Agile Open in Belgium, when he was working as a senior coach in BT’s large-scale Agile introduction. Now we’ve done an interview to find out more about his new book “The Trousers of Reality”.

Willem: So Barry, When did you start thinking about writing a book?
Barry: I have always been a writer. I come from a literary family and it was always something I wanted to do..
Willem: what triggered you to write this one?
Barry: I started writing this book when I realised I had something to say and I had enough life experience behind me.
Willem: what experiences in particular inspired you?

Barry Evans

Willem: In your book, you discuss a number of techniques, besides Agile also NLP, Systems Thinking and the Theory of Constraints. How do they help to improve business and private life?
Barry: I talk about things like NLP because it allows us to communicate better – this is useful everywhere.
NLP in particular concentrates on seeing the other persons point of view – it is not hard to see how this skill is useful talking to both your colleagues and your significant other.
Willem: indeed.
Barry: As you get good at it in one situation you must get better at it in all others – it is a skill that takes constant practice.
Willem: like playing the piano, programming, or writing….
Barry: Funny you should mention that – I use almost the same example in the book.
Willem: I swear I haven’t read it yet:). I’ve just been thinking a lot about deliberate practice recently.

Barry: When I looked at Agile and my experience as an Agile coach I realised that what Agile was doing most was clearing the lines of communication and trying to get rid of presuppositions on every side.
Willem: so that fits nicely with NLP then.
Barry: NLP is concerned with just that and has proven tools, so I said to myself – why reinvent the wheel.

Willem: that makes sense.
Barry: It also fits into systems thinking which shows how things are interrelated. You need to be able to see outside your job, categorisation, sphere of influence, interest, skill-set though.
Willem: yes, and that is a hard soft skill to master.

Barry: When I started looking at these things I noticed that they all had an intersection point and that interested me greatly.
Rather than the ceremony of Agile I started to ask myself why does it work and isn’t it interesting that other things that work all seem to intersect at a subset like a huge Venn diagram. In this intersection I started to find things that worked everywhere – therefore back to the work/life thing.
In fact that started to be my litmus test. The things with real value tend to work across borders of every kind or they are parlour tricks with limited shelf life.
Willem: so how do you distinguish one from the other?
Barry: In my experience with Agile and software development I began to realise that too much was being hung on which tribe you belonged to. Tribalism is the great enemy. My mission with the book is to tell people that whatever tribe you think you belong to that there are things that just work and it is power to understand why they work.
Just clinging to a tribe will leave you out in the cold sooner or later – it blinds you to what is really happening.
Ritual and ceremony were the target of Agile and they seem to have crept in under the door again – I want to call it before it is too late. Indeed NLP has the same problems and the same solutions. Understand the principles and why you are doing what you are doing…. If you really understand it you can turn it into a process for convenience; but you must know when and how to change that process.

Willem: how do you distinguish people who follow “the rules” by rote from those who genuinely want continuous improvement?
Barry: Well the quick answer is experience. It is also trust. If you are a business you hire people who genuinely know what they are doing and who are not afraid to tell you home truths. There is no lazy way out.
There are thought leaders and professionals who are clearly interested in making things work. Identify them. It is also important to develop your own ability to distinguish – based on experience and knowledge. I say in the book to beware the “One Truthers”. Look for flexibility and things that work in variety of environments. Be suspicious of spin and hyperbolic claims. In the end it comes down to Einstein’s advice – Everything should be made as simple as possible, but not simpler. Whereas Occam’s tool was a razor – Einstein uses a vice to similar effect.

Willem: The one topic you cover in the book that we haven’t discussed so far is the Theory of Constraints. How does that fit into all this?.
Barry: There is a chapter in the book called “The Key”. It explains what these things are and ties them together. Essentially TOC allows you to examine cause and effect and is a tool to work your way out of assumptions and constraints.It is great for helping you to understand your current reality so you can start to step up into systems thinking.

Willem: what have you learned from writing the book?
Barry: That writing books is great fun and marketing is hard work. Of course I did a lot of research and as I said in the book the real secret to life is to keep learning. It opens possibilities and opportunities. This is the great thing about what we do if we are involved in IT – we keep pushing our own boundaries of knowledge and what we think is possible.
Willem: yes, that is what got me into IT in the first place. Marketing folks would say that marketing is fun and writing a book is hard work, though .
Barry: Part of the secret of managing people is realising that what you like to do, or do not like to do, does not necessarily map onto other people. You must have empathy but at the same time realise the others feel differently to you. It makes it fun to work with people you do not understand, when you see that lack of understanding as a new model of the world to learn about. And you can be delighted that there is always someone out there you can work with who will like to do the things you do not – great teams are made of this sort of interaction.

You can find out more about Barry Evans and this book at The Trousers of Reality’s website.

It has behooved the XP Days Benelux conference to allow playing of devious political games in its program. Join Emmanuel Gaillot and me on November 23 or 24 so that you can (re)find the (dirty?) politician in you.

“Cheney Satan ‘08″ by futureatlas.com

Photo found through Photo Suggest

(Well, you don’t have to get as dirty as the photo suggests, but you will have to put up a fight for your cause )

We will play politics – in a game you will represent a political faction that tries to get an alliance of agilists to spend money the way you prefer.  Convince others to vote for you so you can carry out your program, or choose another party to do what you want for you… Will you be trying to convince the voters to spend money on conference organization, advanced agile research, business 2 business schmoozing, or something else entirely?

After playing the game we will debrief our experiences and draw parallels with everyday work. It may be that you are already aware of the politics around you.  In that case the game can help you understand more about your behaviour.  It may be that you believe your work has nothing to do with politics.  Think again… it may be that you are a “spoiltician” – someone who has “delegated” that dirty politics to others (e.g. your boss . This game will show you how political many common project decisions are. Whether you care about corporate politics or not, they have an impact on your worklife. Regardless your status, be it an opinion leader, a reckless reformer or “just a programmer” in the silent crowd, this workshop is for you!

Benefits:

• Learn when politics happen
• Get a better grasp at why politics happen the way they happen
• Experience your own behaviour and that of others – it is the situation that is politically charged more than you
• Try out various political strategies and safely observe their possible outcomes
• Have fun!

In case we haven’t convinced you to join, maybe we can offer you a bribe or a kickback? (In case you are american, we may also have some pork available for projects in your home state, to be executed by the companies you love )

Agile Politics Workshop, November 23 or 24, XP Days Benelux, Mechelen

Zed and Carry are programming an online catalogue for Amazing Widgets.  If they deliver new features for the catalogue faster, their company will make more money, because they can outsmart the competition and draw more paying users to their site. Sure, they have a customer, but he’s on holiday at the moment; he might return for another post . Right now Zed and Carry are chugging through a long list of feature requests the customer left them, so they would not be bored while he was away…

So far they have not made much progress. Carry and Zed are wondering why they are going so slow. Carry read this post by GeePawHill saying “the biggest single determinant in today’s production is the quality of yesterday’s production.”

yesterdays quality is the single biggest determinant of todays' quality

That sounds mysterious. Carry wonders how to write good code today, if everything has already been determined yesterday… It seems kind of hopeless! She was taught in school that the number of lines of code a programmer wrote in a day was a measure of productivity. Now she was wading through file after file, looking for the one line she needed to change. If only the code were smaller, the variable names were not all spelled like I, J and cmd and that whenever she was debugging she would not need to remember over 15 classes at once… All of the decisions they took in a hurry to get the new features in production before the customer went on holiday were now haunting them like the ghost of christmas past…

What determines yesterdays' quality: bad variable names, many dependencies, flawed design decisions and the number of lines of code

They stare at each other for a moment. Zed says “what if today’s internal quality was better?”. What would our code like, and what would it mean for us? Carry dreams away. ” If today’s code were better,  we would have less dependencies and much less code, and everything was so clearly named that I knew where to start working immediately. But I don’t know where to start refactoring! It’s all tangled together, I don’t understand what half the code is doing, it just sounds like a dream. And I don’t have time to work on that dream, because we have to hurry! The customer will return from holiday soon, we need to show some progress. Hmm, Zed goes. I think if we stared naming the variables better in the bit we’re working on now, we could see some improvements soon, it would make our work for this afternoon and tomorrow already a bit easier. With the refactoring tools we have it’s not dangerous at all, and we can always get the previous revision from version control if necessary. We could spend part of our increased speed tomorrow on some other improvement.

If internal quality goes up, speed will increase. This can free up time to improve (but you have to make a conscious choice, hence the decision square). With time available for improvement, internal quality can improve, given you choose relevant improvements and have agreed what improved internal quality means. The 'condensator' symbol indicates there may be a delay. Try to choose improvements that improve internal quality quickly - that helps motivate further improvements. If this works you will get a snowball effect: you will go faster and faster, while delivering ever better quality software.

“That would be great”, says Carry “I’d really like that. But I’m scared to break features that are already working. With all these dependencies I don’t know what might fall over when I refactor. Remember the trouble we had with the helpdesk after our last release? Hmmm… Would you be willing to help me clean up the design in the part I’m working on?”

“Sure”, says Zed, “Why not, I can’t go any slower than I am now, and maybe together we can come up with a way to add some tests as well. I’ve been aching to write some of these microtests, I’ve done some exercises but I just can’t figure out where to start. I’ve heard that it can help you focus on the design as well, and the refactorings would be a lot safer – Come to think of it, I still don’t fully trust our refactoring tool, it seems a bit wonky at times; some refactoring up front would make it easier to add tests, so having your help to refactor would be great, it would be a lot safer that way”.

Test Driven Development, Pair Programminging and Refactoring improve today's quality, so that we can go faster later today or tomorrow. Pairing supports refactoring, Refactoring supports Test Driven Development and vice versa. This leads, amongst other things, to Better Variable Names, Less Dependencies and code that expresses its intent more clearly. Pairing and TDD also help prevent and eliminate defects, but that is a subject for another story.

Carry and Zed sat together, changed some names, did a few commits and eventually found a place where they could start writing a test. To their surprise, adding a few more tests was easy, and they were surprised at how little time it took to actually do these things. Carry had some time left at the end of the afternoon to continue reading GeePawHill’s post:

“If you want to increase the productivity of your team, then do these three things:

write a microtest that fails before you change any code;

adopt a “no-pair no-keep” agreement;

establish a shared understanding of internal quality.”

Zed was happy they did this as well. Tomorrow, they could go even faster! He was almost thinking of working alone again tomorrow and skipping the tests, but thought again. He wanted to go at least as fast the day after tomorrow…

Tomorrow, today will be yesterday. Any improvement we can make today, however small, will help us go faster tomorrow.

After thought

For a long time I’ve been planning to illustrate the value of test driven development through diagrams of effect here.  We’ve been using this to ’sell’ the benefits of TDD to course participants and folks we mentor for a few years now, and it’s been remarkably effective. The essence is simple, as Marc Evers put it:

“If we work on the same code as you today, and we write tests and pair when you don’t, We’ll be drinking beer in the bar, while you’re still inside fixing bugs”

Well, that’s the benefit for programmers. I haven’t met product managers or customers who dislike getting better quality software sooner either

Undoubtedly, the speed with which this post was written (as well as the lack of pairing and TDD that goes with writing prose in the flow) merit improvements. Your suggestions and comments are most welcome.

The source has a 15 point list of things to pay attention to when listening. That’s a bit much when you’re in a frustrated or other emotionally charged state and looking to cool down… However, there is always the old ‘no silver bullet’ to give you some hope to get started:

[..] developing quality listening habits. There is simply no silver bullet for doing this. Countless studies have shown that NOT using old habits atrophies the neural net that produces the habit and REPETITION develops new neural nets that create new habits. So the first step is to bring cognition back into the picture.

snowshoe hike at Mt. Rainier by Troy Mason

photo found through Photo Suggest

Some of these things I already know in other forms, but it doesn’t to hurt to see similar things worded differently, it makes it stick better with me under stress. Creating new habits is something that works, even for a hard skill like communication. It ‘just’ takes lots of deliberate practice. And mistakes learning from events is part of the ‘fun’.

Be aware that the list from the source is a list of habits, numbered lists habitually give me the impression of a series of prescribed steps…

Habit 1) “establish your motives upfront” was working for me, more or less. Since I had debated this before I ‘just’ needed to establish whether my motives had changed. It seems my motives for my opinion have not changed, I’m just not sure whether I am as motivated to participate in the discussion again.

I got that from examining habit 2) “Be present” I just could not get myself to be present and stay on the game. If I had been a little more present earlier, I could have followed the suggestion:

If you have pressing needs it may make sense to jot them down quickly so that your mind is not trying to “remind” you to deal with them.

Trouble was, I had plenty of time and no pressing needs on a sunday. So I procrastinated jotting stuff down. Staying around the house with a continuing cold, a lack of sleep that won’t go away. Well, that explains why I was not present… I also felt a burning desire to write, and I  haven’t felt that in a while… Maybe it was just fever

Didja Ever Have One Of Those Days . . . also published as ‘Let Sleeping Dogs Lie’ by Faith Goble

photo found through Photo Suggest

Of course, all of these habits are interdependent. I was experiencing lots of emotional spiking, and was not prepared (4. be prepared for emotional spiking).

Emotional spiking is the result of the introduction of an emotion that is relationally dissimilar to your present state due to the conveyance of emotionally stimulating content or verbiage. This is unique to each person and can really be represented by everything under the sun. Cursing, certain value thresholds, particular subject matter such as sex or violence, etc… The key is to know your own hot buttons and MENTALLY PREPARE yourself with respect to how you will handle them if they arise

Emotional spiking is a strong indication that I’m not being fully present. I’ve been told that people who have been trained to kill go for a walk when this happens – an unpredictable action by a well-trained killer can be lethal…. David explains the reason for this:

The spike in emotion is your body preparing you for protection because it thinks it is in danger and the result, as of that moment, is unpredictable. So it fires up the engines to get ready for the worst.

There is a solution, but that takes lots of training. By now I’ve learnt that through training I can generate the results I want in more situations. However I expect there will always be situations in which I can not. I ‘just’ strive to reduce them. This is one of the ways it can work:

By mentally rehearsing how you will handle any of these situations, you can and do INSERT predictability into that scenario and your subconscious will go easier on the hormone release and cooler heads will indeed prevail.

What works for me is talking to another person (say, my triad or my partner), that usually helps to get some perspective.

A drunken view of a Sydney apartment block by Ian James Grant

photo found through Photo Suggest

If and when I did something unpredictable, I reflect on it with people I trust. I can then use the experience from previous situations constructively.

I took lots of breaks. Watching the judo world championships (I don’t watch sports normally) on tv. Habit 15) seems to be working for me:

Keep a clear channel – Breathe, focus and take breaks if necessary. Realize that your mind is going to be working very diligently and frantically during a prolonged discourse. Keeping a clear head can become increasingly difficult as time wears on.

Applying habit 12) Constantly seek rapport online is still a puzzle for me. It might be why I shy away from contributing to mailing lists for instance. Commenting on weblogs and responding to comments here seems doable. The space seems more confined and most people I write to I’ve met in person. Twitter seemed to provide that for me as well, but it might be more treacherous than I thought at first…

Without good rapport you will only receive inhibited information with a ton of gaps, so constantly seek to establish and keep rapport.

On to habit 11) Seek effectiveness rather than validation. It may be that in social media the balance between effectiveness and validation is different than in other ‘media’ (e.g. face to face). This seems like kicking in an open door (I’ll have to look up the british or american equivalent of that dutch saying later..), but doing is easier than knowing…

[...] Realize that it is OK to be wrong, we all are at one time or another. By seeking to learn and grow rather than win a pyrrhic victory at all cost you will exponentially improve your communication effectiveness and the quality of your life.

I’m curious what your strategies and experiences are for dealing with (online) debate, or if you’re attracted to some of the listening habits I did not mention. I was bad at listening for quite a while, but I seem to be improving. One habit at a time.

William K. Black, the former litigation director of the Federal Home Loan Bank Board who investigated the Savings and Loan disaster of the 1980s, discusses the latest scandal in which a single bank, IndyMac, lost more money than was lost during the entire Savings and Loan crisis. He will examine the political failure behind this economic disaster, in which not only massive fraud has taken place, but a vast transfer of wealth from the poor and middle class continues as the federal government bails out the seemingly reckless, if not the criminal. Black teaches economics and law at the University of Missouri, Kansas City and is the author of The Best Way to Rob a Bank Is to Own One. (Run Time: 1 hour, 38 min.)

It’s a long video. I don’t normally watch these poststamp-sized videos on the web for long, but this one is worth it. If you’re wondering why I’m posting it here: it’s systems thinking in action, you can almost see the diagrams of effects while he’s talking. An other thing that struck me (once again) is the power of “go out and see for yourself” (called genchi genbutsu in lean), and what happens if you don’t do it, or even worse, if the hierarchy in a company prevents it… Mr Blacks’ example of the S&P auditor who was forbidden by his boss to go and look at actual loan files, but instead had to create a credit rating out of thin air is striking. I won’t spoil any more, just go and see this video for yourself .

I found this to be one of the better researched sources I’ve found recently about the financial crisis and its’ consequences. I’d be interested to hear what you think of it, as wel as more sources.

I didn’t get it. But I gave Marc a hand anyway, because we had previously decided that QWAN values:

supporting someone who has a passion over discussing the business case at length

Variazione in scala di grigi by Eric Perrone

Why didn’t I get it?

Marc had a problem that he needed solving for himself, and he was obstinate about it, while I already had solved that thing for myself. Or so I thought…

We started building, and me not being that interested in the product helped. I kept asking: what is the Minimum Viable Product? What do we need to do to go into production, at least to start using it for ourselves? When can we invite others? How could we generate revenue out of it?

While we were building together, the idea for the product already started to shift. Even though neither of us could really use it yet. Just by looking at the things’ user interface, I’d say to Marc: “If I were to work with it, this-and-this would take me too much time (and turn me away)”, and then we’d have a discussion and things change.

Eventually, when we reached the point that we could deploy it in such a way that we could both use it, I started using it too.

And then I got it… I thought my needs were already covered by what I was using, but Marc’s idea was just slightly better than what I was using already. And that leads me to a puzzle: many potential users will have the same idea as me: they already have a solution that works for them, so they are not going to try this new thing out… How do you get someone who’s already got a solution to try out something new that might work even better?