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.

• “Traditional” linear backlog planning we know from Scrum and eXtreme Programming,
• User Story Mapping, popularized by Jeff Patton. This takes into account User goals and actions. It can help you build a working application soon, taking into account as many goals as feasible,
• Dimensional Planning, popularized by Koen Van Exem. Like User Story Mapping, it focuses on the medium to long term. It helps to develop a Minimal Marketable Feature Set, trying to deliver a broad application in the simplest form possible (also known as a ‘Dirt Road’ solution).
• Kanban, popularized by David Anderson and others. This can be combined with the approaches above, but in this game we let participants choose to develop one Minimal Marketable Feature (MMF) at a time, where they have to determine what the next MMF is after developing the previous MMF.

creating a Minimal Marketable Feature

We played two rounds, in each of the rounds participants chose an approach to plan and deliver features. For some reason nobody chose “traditional” backlog planning. With User Story Mapping and Dimensional Planning, three releases are planned and executed in sixty minutes. With Kanban as many MMF’s as possible, one MMF at a time, as fast as our fictitious developers can develop them. The groups that used Kanban got surprises after each MMF, both strategical (e.g. external customers change their mind) and technical (developers have higher or lower throughput). The other teams got such surprises after each release.

What implications that has I leave up to your imagination, alternatively you can come play the game some time .

Dimensional Planning

The game ran reasonably well for a first time. The participants had good fun and learning, especially in the first round. We got good suggestions to run the game differently the next time. Using the same set of stories for the two rounds acted a bit as a spoiler. The team that tried kanban in the second round finished very quickly; they had done dimensional planning in the first round, and were very quick to determine MMF’s and develop them.

This supports of course the theory that combining those things can be valuable, but makes playing the second round less fun. The team that tried kanban in the first round had no previous knowledge of the features and needed a lot more time – basically they went through the product vision again for every MMF, which was quite time consuming.

The Kanban part of the simulation needs a bit more work. We are probably going to develop a different set of cards that visualize throughput and one piece flow better. Due to the developerless nature of the game, an MMF completes at once in the simulation, which feels strange.

This week we will play the next iteration, as part of our Agile Product Development training. Probably only one round, with User Story Mapping and Dimensional Planning. The audience here is mostly non-technical people (C*O, business analysists, testers and some developers) and we focus on effective and efficient ways of release planning and story writing. We might introduce Kanban and dimensional pull on the side, with comments and ’show don’t tell’. I was inspired by seeing how Wim van de Goor and Stefan van den Oord used a task board during their Scrum Board Game to track and show progress of the workshop itself.

Thanks to the participants for giving us critical and constructive feedback, and Marc Evers for editing drafts of this post.

Willem and Marc introduce cultural patterns that can be found in software organizations. By understanding the cultural patterns then you can better adapt your practices.

The presentation starts off a bit slow, but picks up after the introduction. At the time we were incorporating some feedback about our presentations, most notably that we said too little about ourselves, so that the audience had difficulty understanding where we are coming from, and why we had to say something about the subject.

The videographer and editor did a good job at choosing the shots – shooting a pair presentation with one camera is challenging, especially since Marc and I are on opposite sides of the projected slide. The last part of the presentation was helped a lot by questions from the back of the room, I remember Keith Braithwaite and David Anderson (you can hear them faintly in the background) and there were one or two others. Next time I guess we could repeat more of the questions so they are more audible on the video.

A surprising thing we ran into was that Agile was not as mainstream as we thought – a surprising small number of participants put up their hands when we asked whether they were using (at least some) practices connected to Agile Software Development. Luckily, the patterns are independent of this, so we hope those who were/are doing something else get value from seeing various ways to organize development. It’s all about choosing an approach that fits and makes you more effective.

In hindsight the presentation became more graphical and less textual with each iteration. We’ve left the presentation alone for some time, and now have new ideas on presenting the material, as well as some new ideas on how to place various approaches to organize development. We’d love to hear from you about opportunities to perform new iterations…

And even that is not enough. Systems thinking for me is one of the tricks we can use to get people to create a whole systems perspective -together- . And then the people present also have to be able to carry out the interventions they find.

Sitting in a room and inventing interventions for others to carry out is not my cup of tea.  I have done some management consultancy in the past, with and without systems thinking. It was difficult to make change stick, even when we interviewed a representative number of people to create a broad enough perspective. I guess it was because it was us, internal and external consultants, who made the final picture, collected data and suggestions, and then make some of our own. That meant not all suggestions and systems pictures were ‘owned’ by the people who were supposed to try them out… These days I would do something like that differently; for instance by organising an open space and targeted workshops, where all of the results are created in the room. Reports, if any, are made by the participants and/or are merely a textual summary of what was said during the workshop, with diagrams that were created on the spot.

Jurgen writes:

“With his book Complexity and Management Ralph Stacey convinced me that top-down systems thinking is a management fad. Weinberg’s diagrams may be useful to understand communication problems in an organization, but managers shouldn’t think these diagrams can help them solve those problems. Managers cannot directly control a social system by adding or removing relationships, nor by enabling or disabling communication. Managers are part of the system themselves, and communication simply happens. They can draw circles and lines until their fingers turn blue, but diagrams will never properly represent what happens on and off the work floor.”

Diagrams of Effect and other systems thinking tools have helped me most when I applied them with my peers on things that we had influence over. Note that influence is not control – the quality of ‘improvements’ we imagine have to be judged by their effect. So how do you get to properly represent what happens on the work floor?

Invite the “work floor” with their managers to tell stories and create diagrams plus possible improvements together.  We have been experimenting with systems thinking in technical training. In an object-oriented design training last week the developers invited a senior manager to the systems thinking part of workshop. In a short time many stories were told, diagrams were drawn -together- and possible improvements were identified.

We are busy articulating why we believe this approach works. I hope to post soon on how this seems to work, and how we arrived here. In the meantime, we’ve published our first technical training that includes participants doing systems thinking (managers are invited too, of course ) besides programming and design excercises.  We have incorporated forms of systems thinking in our explanation. It seemed to help in and now we are taking the next step.

We have good hopes the improvements everyone found in last weeks’ training will stick: the people who have to do most of the work to make it happen were present. That includes the manager. Developers can also draw circles and lines until their hands are blue – it is easy for developers to forget the hard work that goes into seemingly effortless management.

Finally, managers can make things happen that developers’ can’t.  For instance freeing up budget for training, build servers, deciding how new developers are hired and getting customers to talk to each other and to developers. So get everyone in a room, and don’t let them out until they found stuff that could possibly work

“So, why bother?” I asked him.

“I’m productive, but I would like to do it with less stress”. I can understand that. And then I  thought that by thinking about more productivity and less stress, you might achieve they opposite. I’ve met some very relaxed people. Were they thinking about stress? Probably not. Not thinking about stress may be like not thinking about a banana. You’ve probably read about research where they ask people to not think about something a banana, for instance, and it turns out they think more about it when you ask them not to…

Take Getting Things Done, for instance. The book has as subtitle “the art of stress-free productivity”. I have the book, and have tried it a couple of times. To me, it seems to have too many moving parts. Even if you take just one part, it might cause you stress. For instance, Johanna Rothman just wrote how Inbox zero is hard for her. GTD states that you should end every day with an empty inbox.

I tried that a couple of times, and after a while I could not get it to work either. In the mean time, I was stressing about it, worrying that I was not working to the norm I had set myself… Thus achieving the opposite of what I set out to do.

So, before Marc got around to explaining that The art of getting everything done by putting it off to tomorrow, and the main principles are of his shiny new tool, I came to the conclusion that it might be best for me to eat my own dogfood, and apply to myself what I tend to advise to teams these days:

Reflect, find out what works for you and do more of it (and do some experiments every once in a while to see if something else would work even better).

Trying out another methodology would not work for me at the moment, because, I might be worrying if I was ‘doing it right’. Asking if you’re doing it right is often the wrong questions to ask… And following a methodology to a T might give you more stress, and thus less productivity, instead of the other way around.

So don’t think about stress, I wish you a relaxed day!

I particularly liked the draft on Financial Options, it explains a number of not so intuitive financial instruments and techniques (e.g. naked short selling and futures) in such a way that I find them easy to understand, and possibly explain them to others. Not a bad thing to have in turbulent financial times. Chris’s goal is to make them  understandable by ‘basically everybody’ – I encourage you to go and read it, and give him some feedback on bits you don’t understand.