Agile Lab - Training, Coaching and Consultancy

And now you're here...

Sent from my BlackBerry® wireless device

...And now you're here

Sent from my BlackBerry® wireless device

Interesting

http://www.guardian.co.uk/stage/2012/jul/20/timon-of-athens-paul-mason?mobile...
Sent from my BlackBerry® wireless device

Remind me to buy this:

Paul Mason - Why it's kicking off everywhere
Sent from my BlackBerry® wireless device

Wednesday, 18 July 2012

Purposelessness

The failure to recognise the virtue of purposelessness is the starting point of industry"s problem. To the managers and engineers who set the dominant tone in industry, purposelessness is anathema, and all their impulses incline them to highly planned, systematized development, in which the problem is clearly defined. William H. Whyte - The Organization Man Sent from my BlackBerry® wireless device

For all the Scotch we drink, what's in between is not the forty or so years but...

Sent from my BlackBerry® wireless device

Monday, 16 July 2012

Late and Over Budget: Commitment and Consistency

Commitment and consistency is a big thing in project management. It’s the reason that calling a book “Late and Over Budget” has any kind of power. Here’s the gist. Plans are poor models of the world and, very importantly, they don’t exist. But very often, when people think about project management, they imagine that what project management is, the whole point of project management is delivering according to a plan – on-time and to-budget. Even though plans don’t exist, plans are in great danger of becoming something. A plan is in great danger of becoming a commitment.

On the whole people like to stick to their commitments. Robert Cialdini’s book “Influence: The Psychology of Persuasion.” Has a whole chapter on “Commitment and Consistency.” This chapter is hard to write because it just feels so wrong suggesting that any kind of success can come from not honouring your commitments. In one experiment that Cialdini talks about in his book, people who made a very low-grade commitment – they agreed on the phone that charity was a good idea - were EIGHT TIMES, let’s say that again EIGHT TIMES more likely to agree to volunteer for a charity collection in a follow-up phone call than people who weren’t asked the original question. What this experiment, and lots like it shows is that we all desperately want to honour our commitments and be consistent with our beliefs. Why are we all so desperate? Because we don’t want to be regarded as either dishonest or insane, and on the whole, that is how society regards people who don’t keep their word.

Commitment and consistency is a huge thing and even though plans are vague, poor models of the world; even though plans are created at a point when we have the least knowledge about a project, they tend to get interpreted as commitments. Estimates tend to get regarded as commitments, as promises.

Why? Why would so many people continue to treat plans like this despite all the evidence that plans do not get adhered to? I think there are a couple of reasons. Firstly, the people who are pressurising project managers to commit are themselves under pressure to commit. The only way they can think of to relieve this pressure is to pass that commitment onto you. They too imagine that it is part of the identity of a manager of projects to deliver on-time and to-budget.

Secondly, I know this is controversial, but that doesn’t mean it isn’t true. There is something comfortable about having your employees permanently in a situation where they are in danger of failing to honour their commitments. It puts them on the “back foot”, it makes them more compliant and more eager to please.

The flip side of this is that many, many project managers are spendthrift with their commitments. They are consistently “optimistic” and “positive” in their estimations of how long a project might take. They are willing to make promises about delivery on the vaguest of specifications. Because of a desperate urge to please, to appear positive, to look like a team player. They promise the earth when they haven’t even checked if they can deliver pizza. They promise to deliver on a project at a point when they have absolutely no idea when they can deliver or not.

What’s the answer? The answer isn’t to duck commitment. The answer couldn’t be to duck commitment, not only because there is little chance we could resist the urge to commit for very long but also because ducking commitment goes down very badly with senior management. The answer is rather to commit to the right things.

COMMIT TO MEASURING AND REPORTING REAL PROGRESS

This is the most important one. Keep explaining what is really happening. There are a bunch of things that you have to do every day as a manager of a software development project to do this. You have to have a daily stand-up meeting and at that meeting you need to track the real progress of work. The best way to do that is to break the work down into stories and plan it in iterations and not allow extra work to creep into iterations, all that good Agile stuff. If you do that, at the end of each iteration, you will have a number. Number of stories, if they’re roughly the same size. Number of ideal days, number of complexity points if you’re getting fancy. It doesn’t really matter. What you also need to have is a backlog of things that you are going to do that is numbered in the same way. Using those two numbers you can do some fancy predictions. You can divide your actual progress by the number of things left in your backlog and get an estimate of how many iterations it is going to take to get through your backlog. Let’s say your project has been going for four months and it’s got through 16 stories, you’ve got 20 stories still on your backlog. Guess what? That project is very likely going to take another 5 months.

So, that’s why iteration planning and counting velocity are so vitally important. This is the one thing that you really should be comfortable committing to. Real progress.

Things your bosses will try to do to stop you reporting real progress:

That can’t be your real progress, you must have counted incorrectly

When the bosses don’t like the progress that you tell them about they will try to get you to count things differently. They will especially try to get you to count half-done things, they will try to get you to play fast and loose with your “definition of done”. Don’t let them do this. I’ve given in and done this, it’s a disaster.

You are not a professional, you are bad man, you are a pitiful fool

It’s your fault, if you don’t buck your ideas up you’re out. This is the clincher. What they are actually saying is “lie to me or I’ll fire you.” They probably don’t know that’s what they’re saying. They probably aren’t going to fire you. Do you know how hard it is to recruit project managers who are any good, even in the most dire of economic climates. Unless you really are in the most desperate of job markets, don’t lie. You’ll only be in a worse place if you do. Actually, even if you do lie to them, don’t lie to yourself. Even if they do persuade you to count work that’s just been started as “99% finished.” Don’t lie to yourself. Tell yourself what the real figure is. Try to mention the real figure, even if you instantly follow it with the inflated figure that your boss has insisted on.

Yes, I know this is the real figure, but we can’t possibly show that to my bosses, what if we move these over here, multiply by PI and then take away the number we first thought of?

Let your bosses fiddle the figures (i.e. Provide a management steer) however they see fit. But always provide them with the real figures, then provide them with the “summary” figures.

I talked to every member of your team until I found someone who would tell me that things aren’t as bad as you say they are

Good, you’ve got no problem with members of your team being optimistic. But these are the figures.

I talked to an insane person that I met outside on the street and they said that this project shouldn’t take this long [Something like this really happened to me, OK, he was an insane person in the same office, but the gist was the same]

Good, that’s nice. These are the figures.

Can’t you ask the team to try harder?

Yes, I can (it won’t make any difference). These are the figures.

So, this is the commitment that you have to make if you want to stay sane, and also, very importantly, if you want to do absolutely the best job possible for your bosses, for your organisation and for the team.

I commit to consistently collecting and reporting the real progress of the team to the bosses.

Maybe you’re the kind of person who’s more motivated by the fear of bad things happening rather than of good things happening. If you are, let me try to scare you. If you don’t know how you are progressing in the project, if you don’t know how your team are doing against the backlog, you don’t really have any business not agreeing to whatever aggressive deadline the bosses suggest.

Here is some other stuff that you CAN commit to.

Plumb into Value

The bosses think that what’s important is that the project is on time and to budget. It isn’t. What’s important is that the project delivers value. For that reason whenever you can, you should push for the software that you’re working on to be delivered. The truth is that the value of software can only be realised after it has been used by its real users. Once that has happened and the bosses start to get feedback from real users, you will very often find the shape of the project completely changes. The endless vague features that were on “the plan” are suddenly forgotten and enhancements to a feature that you did release suddenly become far more important.

So here’s something else that you can commit to, whilst staying healthy and sane:

I commit to work with my team to deliver valuable working software to my project’s customers and end-users as soon as we possibly can

GetDirection and feedback from the product Owner and the Stakeholders

Along the way, you need to always make sure that you get a steer on what the priority is for the backlog. Hopefully, you should get this from someone called a “product owner.” But it’s my experience that lots of organisations don’t like the sound of this title. The term “product owner” sounds like someone who has real power. So many organisations either avoid appointing product owners, or give the job to somebody who clearly can’t do it – somebody very junior who’s not in a position to take a decision, somebody too senior who simply hasn’t the time to consider the detail, somebody who already has four other jobs.

Another vitally important way to get an idea of what is actually valuable and what is a priority from the bosses, is to hold regular showcases at the end of every iteration. These can be a rough ride and cause all sorts of problems. Turns out, very often, the bosses are far too busy to look at demonstrations of working software. When they do turn up, they are apt to make totally random comments. Also, you never get the same collection of bosses from one showcase to the next. Still it’s worth doing because it is the best of way diving what is actually valuable in the software your team is writing.

So here’s another thing that you can commit to:

I commit to consistently getting guidance on priority from my product owner and collecting feedback from my stakeholders

Work to Speed Things Up in the Only Way that Works – By Removing Blockers

Faster! Faster! This is a legal requirement! We’ve already promised this to our customers! You said it would be ready by now. You are not a professional. Goddamnit! Can’t you go faster? Can’t you all try harder?

Any of this sound familiar? There are actually very few things you can do to speed things up. Almost all of the things that get suggested by the bosses, adding more people or “resources” to the team, co-opting a hangar full of third-party developers on the other side of the globe, trying harder, typing faster (yes, really) don’t work. What does work though is finding out what things are slowing down the team and fixing as many of them as can be fixed. In Agile terms, these are called “blockers.” These should come out at the stand-up meeting that you’re running with your team every day. Some of the more “meta” problems will only come out at the retrospectives that you should be running at the end of every iteration. If you’re the kind of person who is good at keeping lists, you could keep a running log of blockers that come up in stand-ups and then assign actions and resolutions to them. You could also do the same in retrospectives. If you’re not so good at keeping lists, you can do a loose prioritisation of blockers from each stand-up by picking the top one or two that you’re going to work on each day after the stand-up and reporting the top three issues from the retrospectives at the end of every iteration to the bosses. What you find is that, very quickly, you rip through the things that you can change and end up with a list of things that you can’t change, and maybe even your bosses can’t change without making some kind of special effort.

These things should be the first things out of your mouth whenever the bosses start complaining about the progress of the team.

So here’s your final commitment:

I commit to consistently fixing the blockers that I can fix for my team and making sure that the bosses are always aware of the blockers that I need their help to fix

Commit to the Right Things

OK, so let’s review. Plans are fantasies. Bosses are going to try to get you and your team to sign up to these fantasies for two reasons. One: they’re under pressure from their bosses to commit to these fantasies. Two: people who are on the back foot are easier to manipulate. People who don’t meet a plan, even if was a totally fantastic, unrealistic plan feel bad about themselves and desperate to please. Signing up to an unrealistic plan, and guess what? - in software development, they’re all unrealistic - is an instant recipe for feeling bad and being late and over budget.

What’s the cure? Don’t sign up to an unrealistic plan unless you really have to (you probably will have to). When you do sign up to such a plan cross your fingers and toes and mentally understand the kind of dodgy manipulative bad-faith bargain that it is. At the same time, DO commit to the principles that I’ve outlined here which will actually help you and your team do the best that you can for your bosses.

1) Track the real progress of your team, calculate what that means for the projects progress against the backlog. Report this to your bosses, even when they don’t want to hear.

2) Deliver the software that you’re working on to the end users and customers as often as you can and as soon as you can.

3) Get guidance on priority and feedback on value from product owners and stakeholders in all the right places i.e. iteration planning and showcase.

4) Fix the blockers you can fix, report the blockers that you can’t fix to people who can fix them.

Labels: late and over-budget

"A climate of endemic crisis"

According to Tavistock, the formal system (contracts, plans, etc.) does not recognize the uncertainty of and interdependence between the operations of the building process. An informal system of management emerges for handling uncertainty and interdependence, but it produces a climate of endemic crisis, which becomes self-perpetuating.

Koskela, Lauri. Kagioglou, Mike. 2006. "On the Metaphysics of Production". Proceedings of the 13th Annual Conference on Lean Construction. pp. 37–45.

Sunday, 8 July 2012

Late and Over Budget: Introduction

Late and Over-Budget

Introduction

Why write a book with such a depressing, negative title? Part of the reason is that I tried to write a book with a normal, business-like title “Introduction to Agile Software Development” or some such, at the suggestion of an actual publisher. The trouble was that everything that I tried to write under that title seemed to be to be the most awful, deathly dull stodge. Trying to write about Agile, part of me somehow felt that I should write about it in “business bookese” even though that was not at all how I explained it in my training courses. It took about another 6 months, and a run-in (actually it was a phone conference so it was more of a hang-up/flounce-out) with a company chairman particularly lacking in understanding of the realities of the software development process before I started why I was having so much trouble writing a basic Agile how-to book. The central premise of a basic Agile how to book would, I suppose be, “use these Agile techniques and your life will be get better.” Only trouble was, guess what? It probably won’t.

My experience over the last few years has been working with software development teams, either as a “scrum master” – I don’t care what the zealots say, this essentially boils down to being a project manager – or as an “Agile coach,” doing my best to help development teams improve their process. Over this period I began to notice something slightly strange, or certainly different from what I’d been lead to expect. The majority of books that you read about project management, whether they be Lean, Agile or more “conventional” approaches to project management, such PRINCE2, talk about the enormous advantages that accrue from implementing whichever methods they are pushing. When bad experiences are discussed, they are only discussed as the “before” phase of a project which was then catapulted into joyous productivity.

This doesn’t really chime with my experience of being a project manager. The books simply weren’t describing the projects that I’d worked, no matter how closely we adhered to suggested methodologies, these projects remained places to go to experience pain. Perhaps this is what it would feel like if you were experiencing troubles with your life-partner and the only literature you could find on the subject consisted entirely of romances which ended happily ever after.

My experience of being a project manager is that no matter what methodology is being supposedly or actually implemented, no matter how bought-in to the methodology senior management, customers and stakeholders and team members are, there will still be a perception that the development team is not performing as it should: that it is late and over-budget and desperately needs to try hard and go faster. If you are a project manager responsible for software development and you disagree with this assessment, if you happen to be presiding over a software development team that is perceived by all those is manage it and pay for it as being professional, on-time, to-budget and essentially valuable to the organisation, I don’t really want to argue with you, go, enjoy this while it lasts, make hay while the sun shines. Maybe give this book a look some time in the future if things turn sour. They might.

The argument of this book is pretty much as follows.

1) 1. ) Late and over-budget is going to be the rule rather than the exception for most software projects that you ever work on. Most likely it isn’t your fault because:

2) 2.) There are at least three really powerful reasons why most project are LAOB (and maybe a fourth):

a. The complex, sometimes chaotic nature of the problems that software development tries to solve (we’ll talk later about the Cynefin framework)

b. The basic difference between models of reality i.e. plans, budgets, timescales and actual reality and the bizarre tendency of almost everyone to fixate and worship plans, budgets timescales, rather than reality.

c. Any team that is performing on-time and to-budget will tend to attract extra work at least at least up to the point where it starts doing badly (the Buckaroo effect).

d. Possibly because of point 3) below, it suits the management of your organisation to have software development continually perceived as being a “problem” (yes, I’ve read a bit of Machievelli).

3) 3.) This makes managing software development a miserable experience, largely because of the powerful desire of human to be consistent and deliver on their commitments.

4) 4.) Once you understand all this you can relax (a bit). Relax and do a better job. There are things that you can do to make your experience and contribution as a manager of software development a whole lot better.

a. You can do yourself and your team a favour and concentrate on committing consistently to things that you can actually deliver.

b. You can concentrate on delivering value to you senior stakeholders and customers and clients.

So this is the argument I’m going to try to expand on, explore and hopefully, finally prove. On the way, I will talk mostly about Agile practices for project management because those are the ones that I’m most familiar with and that I know from personal experience actually work. I’ll also talk about some concepts from Lean and Kanban, although that’s not my personal area of expertise. But, I’ll let you in on a preview, a big part of how start relaxing in step four is to focus on delivering real value to your stakeholders and customers. Of course this isn’t the whole answer sometimes the project that you’re working on delivers no discernible value to anyone, that the only value there is, is the empty value of delivering against the plan. In which case, might I suggest, you have to choose one of the 3 Rs – restructure, run-away or rot. Cheerful huh? We should probably move on.

LateandOverBudgetIntroduction.pdf Download this file

LateandOverBudgetIntroduction.docx Download this file

Late and Over-budget: The Root of the "Problem"

Late and Over Budget

The Root of the problem

“Life is Wiggly” – Alan Watts

“Essentially, all models are wrong, but some are useful.” – George E. P. Box

Here’s a little exercise to get us started. I got this idea from a book called “Sleight of Mouth” by Robert Dilts. Think of something that you could have done yesterday and didn’t do, go easy on yourself, don’t think of something your rarely do, or you’re not likely to do, think of something everyday, that you could have done. Now think of something that you did actually do. OK, this is the really important bit. Look at these two things in your mind, the thing you could have done and the thing that you actually did and try to notice differences between them. How are you absolutely certain that did the thing that you really did? What is there lacking, or different about the thing that you didn’t do that makes you certain that you didn’t do it?

When I do this exercise as part of training courses I get all sorts of interesting answers, people tend to miss the mark of telling me exactly how they know that one thing in their mind was real and another is not real and rather move straight over to explaining why a series of things that “should” have been done didn’t get done. For example, I could have gone to the gym, but instead I stayed at home and watched TV because I actually like watching TV and I don’t like going to the gym, even though I know I should. This in itself is an instructive exercise to do on any project – look at the things that didn’t get done and ask “why” (a way into the Lean concept of the five whys) but it it’s slightly off the point that I’m trying to make.

When I tried this exercise I didn’t go back to something that happened the previous day, I went back to something that had happened in the previous hour – lunch. I sat at my desk and thought about the lunch that I’d had – chicken soup, and then I thought a bit about the lunch that I could have had – a bacon sandwich. Then I thought about what was the difference between the two. How was I certain that I had had the chicken soup for lunch and equally certain that I had not had the bacon sandwich. And the thought that came to me in answer to this was genuinely an inspirational, eureka moment. I know that I’d had the chicken soup for lunch because I could remember spilling it on my shirt!

At this point your heart maybe sinking, with the slight suspicion that I am a lunatic, but trust me there actually is an important point about project management, especially management of software development projects. To generalise, how did I know the difference between a “plan” that hadn’t been executed: have a bacon sandwich for lunch; and a “plan” that had been executed: have chicken soup for lunch. I was certain that the chicken soup plan had been executed, because there had been problems with it – the stain on my shirt. Unexpected trouble that will result in extra work to make things all right is a very, very good indication that an attempt has been made to execute a plan.

This difference between the clean elegance of plans that have not been executed and the dirty troublesome-ness of plans that have been executed is the single thing that makes project management so stressful and difficult. Almost every job advert that I have seen for a project management position, almost every group exercise that I’ve ever done that tries to get from people what they expect from a project is running well will contain the phrase “On-time and to budget”. And if you ask those people what they take “on-time and to-budget” to mean, they will invariable answer “delivering according to a plan.” These same people, when you ask them what constitutes a “bad project” will talk about projects that a “late and over budget” and that “don’t go according to plan”.

This is really weird. If we stick with my examples of the chicken soup and the bacon sandwich, which lunch are they praising? The bacon sandwich, the one that didn’t happen. But this is the big question – which lunch actually fed me? Well, that would be the lunch that didn’t go according to plan, the one where the costs ran over, embarrassed us professionally (I can’t even drink soup without spilling it on myself) and took far too long (once you take the shirt clean-up into account). Yes, that’s right, the messy troublesome option was the one that actually nourished me.

How on earth could this happen? How could we get ourselves into a situation where there is almost universal agreement that delivering on-time and to-budget, to a plan is a good thing and almost no mention of delivering actually value, even if it be in a messy fashion?

The first problem is that we never really see the real world or experience it with our other senses, we simply see and sense models of it. The real world, as the religious thinker and philosopher pointed out, is “wiggly”. But our plans and our models almost never are. Our plans feature clear discrete steps, straight lines, and if we are being really sophisticated, possibly a curve or two. Because we don’t see the real world, but rather these beautifully sleek models and plans, the things that we become emotionally attached are – guess what? The models and the plans. Even though it is only the messiness of the real world that can feed us.

The second problem is that when we get together in organisations, we take our love of models and plans and fear of the messiness of reality with us. There we work to “reify”, I’m almost tempted to type “deify”, these plans. We start treating them as if they are the real world.

Notes for next time:

Planning doesn’t change the world

The best that a good plan can do is act as marshalling point for resources to discover value.

What to do:

Focus on delivering actual value.

Understand how to be useless, unprofessional, evil, bad, wrong and valuable.

What to do if the only value is delivering on the plan.

Tunnelling towards value. Run away.

LateandOverBudgetLifeIsWiggly.pdf Download this file

LateandOverBudgetLifeIsWiggly.docx Download this file

Friday, 6 July 2012

Blind thinking - any of this sound familiar?

As I gradually became more and more familiar with the ways of this blind thinking I came to the conclusion that the success of my whole enterprise hung on my ability to emerge from it. For I realised that it made learning by experiment quite impossible. The essence of experiment is to have some desire or plan and then to try various methods of bringing about what one wants always keeping in mind the first intention and comparing what actually happened with what was expected to happen. My blind thought, however, having set out full of intentions, would, with the first unexpected incident, become distracted and set off in another direction, like a child who goes to fetch something but forgets its plan because it finds something more interesting to do on the way. Apparently it could not hold the unexpected happening in mind side by side with the intention and so revise its method in order to fit the new facts. So it was that I set out boldly saying, 'I will experiment with life and so make for myself rules about how to live,' and I had plunged into experiences only to find when I came out that I could conclude nothing from them, and could find no rule for future guidance, because I could not put my knowledge of the experience side-by-side with my intention and see where I had been wrong. All I could do was drift blindly from one experience to another, vaguely hoping that if enough things happened to me I would eventually learn wisdom. I never realised that I was making the same mistake again and again, simply because I did not know how to emerge from blind thinking into that state of seeing in which reflexion and the drawing of conclusions were possible.

Marion Milner - A Life of One's Own
Sent from my BlackBerry® wireless device

Thursday, 5 July 2012

Narrow Focus

Now I thought that perhaps I could explain in part what it might be which drove me to that narrow focus with which I had tried to face all my life problems. For by narrowing my attention down to a point I no doubt increased my capacity to understand the small part I was actually looking at, but I also increased that dark area outside its concentrated beams, in which ideas might remain unrecognised, and therefore liable to all the fantastic distortion of blind thinking. Thus the more I turned my attention to details in order to save myself by scrupulous care from these monstrous fears of failure which lurked in the wide field, the more terrible the monsters became and the more terrible they became, the more I dared not face them, which alone would have destroyed their power.
Sent from my BlackBerry® wireless device

Tuesday, 3 July 2012

Outline for a Book - anybody think this looks interesting? Late And Over-budget, a Real-World Survival Guide for Project Managers

The Difference Between Dreams and Reality - Life is Wiggly

“I have a plan” - “So what?”

Planning changes nothing
If you don’t have a plan for changing your plan, you don’t have a plan

Do the “Chicken Soup Exercise”

What is the difference between things you thought about doing and things you actually did?
I know I really had the Chicken soup because I spilt it on my shirt

A plan is thinking about about having Chicken soup, it isn’t actually having Chicken soup

Actually having Chicken soup is a messy business

Thought goes in straight lines, real life is “wiggly”

Consistency - the Hobgoblin of Little Minds

Doing what you say you’re going to do is a powerful human urge

If you don’t do what you say you’re going to do, people will think that you’re either mad or evil.
Getting other people to “keep their word” is a powerful way of controlling them.
People attach huge value to delivering on a plan - even more value than delivering something valuable!

We are after all NOT Professionals

The Cynefin Framework

Simple - Journeymen (but does this kind of work really exist?)
Complicated - Craftsmen, Professionals
Complex - Consultants
Chaotic - Artists, Researchers, Philosophers

To be Good at your Job, you must realise that you are not good at your job

Bullies, psychopaths and other senior management will try to trick you into thinking you should be good at your job, it makes you easier to manipulate

What you CAN do, Reporting, Sorting, Counting and enabling the 3Ts (Talking, Thinking, Typing) a set of rules you CAN commit to

A clean, well-lighted place
This really isn’t rocket science
Stop trying

A Beautiful Mind and the Buckaroo Project (Junking your project for fun and profit, misery and loss)

Projects tend to get given work until they start to break
Projects tend to have their resources stretched temporally and geographically until they start to break
Most development teams start off broken, if you get them working, someone will break them

Table 2’s Butter Bean - if you prod it and play with it, it will die

This is probably something to do with John Nash and equilibria

The Power of Negative Thinking

Everyone (i.e. idiots) hate short-sellers
What project management is not

No military metaphors please
Fuck ""trying hard", I mean, seriously, that's your "strategy."
Delivering value and discovering value vs delivering on a plan

Level 0 people management
The art of the possible

People in glass houses shouldn’t order custom-built windows

Noticing things

Letting your petri dish go mouldy
Playing with the goo on the pressure chamber floor
Do you know funny thing about this angina drug?

Northern Line Southbound at Charing Cross

You are here
And as usual you are wishing you were
Somewhere else but then Look how beautiful the black women are
Admittedly, in the next carriage.
Sent from my BlackBerry® wireless device

Sunday, 1 July 2012

"I began to guess that my self’s need was for an equilibrium..."

“By now I had reviewed all my past attempts to find happiness by following the instructions of mental training experts. Gradually a conclusion began to emerge. Instead of, as always before, assuming that they were right and therefore my inability to read the promised result must be due to my own weakness, I began to ask whether this really was the way to find what I wanted. I had been continually exhorted to define my purpose in life, but I was now beginning to doubt whether life might not be too complex a thing to be kept within the bounds of a single formulated purpose, whether it would not burst its way out, or if the purpose were too strong, perhaps grow distorted like an oak whose trunk has been encircled with an iron band. I began to guess that my self’s need was for an equilibrium, for sun, but not too much, for rain, but not always. I felt that it was as easily surfeited with one kind of experience as the body with one kind of food, and that it had a wisdom of its own, if only I could learn to interpret it.”

Marion Milner, A Life of One’s Own