Many moons ago I wrote a story about Collin the Hackney minicab owner was managed to destroy his business from some foolish decisions. If you haven’t read it, then this post will not mean much so I encourage you to do so before continuing.

Thanks to Ed Blackburn, I am now finally getting around to responding to this, I suppose I have left you all hanging long enough..

I chose the act of driving to the Airport as a deliberate metaphor as many of us can relate to such an activity. The drive to the Airport usually means driving on busy roads and for some distance, essentially a task that is full of unexpected delays. Most of us would balk at thinking we could nearly half the drive time to the airport or even attempt to accurately predict our arrival time. Though this happens every day in business, in situations with even more variability.

There are several unfortunate things going on here for Collin.

1. First and foremost Collin shows no understanding of variation. A goal was set based on beating the competition, not actually based on reality of what is possible within the system of roads driving to the Airport.
2. Performance in a system such as this is a lottery due to natural variation. All drivers will have both good and bad days due to events outside their control. Setting goals in this environment will yield winners and losers naturally, and will mostly be orthoganal to driver talent. Collin, by selecting the fastest drivers again ignored variation and for most part selected lucky lottery winners.
3. Unintended consequences of goals and bonuses. When Collin offered a bonus for 30 minutes to the airport, he created a pseudo goal and focus for the drivers, which forced them to break the rules to achieve it to the detriment of the customer. In fact all other goals such as pleasent journey, passenger safety, road rules and courtesy were abandoned, because the new goal with reward took precedence.

Have you experienced similar situations in your job?

In the git help pages it says

The name of a new directory to clone into. The “humanish” part of the source repository is used if no directory is explicitly given (repo for /path/to/repo.git and foo for host.xz:foo/.git). Cloning into an existing directory is only allowed if the directory is empty.

So if you do need to do this, then a work around is:

Clone the repository without checking out the contents to a new folder

git clone -n <repo>

Then move the git folder to where it needs to be

mv .git <existing folder>

Then force a check out the contents

git checkout -f master

Warning: This come with no guarantee of success. Works on my machine…

Simple collaboration game that introduces lean thinking concepts flow, batch size and constraints.

I first introduced this game at Barcamp London 2010 as an abbreviated version of the “dot game” (created by Allan Shalloway, who in turn created it as a cut down version of another game – LSSC Europe 2010).

Setup

book or 2 of post-it notes

3 pens

Watch/Clock/Time keeping device

room + table & chairs

minimum of 5 participants + facilitator (who plays role of customer)

laptop to graph results (or a white board to make them visible)

a pre-prepared sample post-it note containing patterns of Circles Triangles and Squares. (see below)

It is important that the circle pattern is easiest to draw, the triangle pattern is most difficult and the square pattern is of medium complexity.

Process

In a straight line, position the 5 workers along the table this will simulate a typical linear work flow. They will be working together to produce a copies of a sample post-it note (prepared The people will perform the following tasks in order:

1st person – BA peels post-it notes and passes to second person

2nd person – draws the circles as shown in the sample and passes to third person

3rd person – draws the triangles as shown in the sample and passes to fourth person

4th person – draws the squares as shown in the sample and passes to fifth person

5th person – acts as Tester (only accepts defect free post-it notes). Hands completed post-it notes to the customer (facilitator) hands defects back to the appropriate person to rework.

A timekeeper starts a stopwatch when the process kicks off and records time of a few key moments.

1. Start time

2. Time until first batch is completed (cycle time)

3. Time until total work is complete (lead time)

4. Total number of defects

5. Total number of completed post-its

6. Number of incomplete post-its along the production line (work in progress)

The process is run 3 times, preferably with different people or at least with people in different roles so as not to get accustomed to the work. I cap each round to a maximum of around 5 minutes. The goal is to get 30 defect free post-it notes delivered.

Cycle 1

Process is run with a batch size of 10. Which means that the 1st person peels 10 post it notes before passing the 10 post it notes to the 2nd person, who completes all 10 circles before passing on to the 3rd person… and so on down the line. Ensure that the 1st person keeps pushing work down the line, even though he has peeled 30 post-it notes, this is typical production like behaviour. Facilitator needs to enforce activity, “we don’t want people idle” “we are paying you to work, not sit around”

After the round has finished, record and display results and discuss the observations as a group. Typical observations and discussions:

• Piles of work forming in front of 3rd person (triangles) – This represents a bottleneck. What are the parallels in software?
• Large amounts of work in progress – This represents Inventory and cost, and potential waste. What are the parallels in software?
• Chaos and mayham. Lack of communication
• Batch size. Where do we batch work in software? (releases, analysis, UAT, “projects”)
• Lead time / cycle time. What is this in software? Are long lead times bad? What are the implications of long lead times?
• People will be idle (the tester and Square drawer will be starved of work)

Cycle 2

Process is run again with a batch size of 1. Which means 1st person peels a single post-it note and hands it to the 2nd person who draws the single circle and passes onto the 3rd person and so on. As before, we enforce activity. Work is pushed down the line from the rate the BA can peel post it notes.

Again the results are recorded and displayed and observations discussed. Typical observations include:

• Bottlenecks remain although piles of work are less. Discuss how this could be improved (limit the rate of work pushed into system and/or pull work)
• Less work in progress
• Less Chaos and potentially more communication
• Lead time will reduce (cycle time will stay the same)
• People will still be starved of work
• more units completed
• Tester will see more completed post-it notes and can give more feedback to workers. Defects will decrease (slightly)

Cycle 3

Process is run for a final time again with a batch size of 1 although work is now pulled as necessary. Which means the 1st person will not peel another post-it note until the 2nd person requires it, and the 2nd person will only pass the post-it down the line when the 3rd person (the constraint) requires it. This effectively ties the rate of production to the rate the constraint can produce. Also it is time to build quality into the system, the team now re-positions to form a square, rather than a straight line. The tester becomes a QA and monitors each work step for quality providing feedback immediately upfront rather than at the end.

Again the results are recorded and displayed and observations are discussed. Typical observations include:

• No piles of work in front of triangle worker
• Work in progress dramatically decreases (costs decrease)
• Number of completed post-its goes up
• Lead time dramatically drops
• Less defects
• People are not working as hard but more effectively. Yet more work gets done more quickly and cheaper! (Paradox)
• More collaboration.
• Pull verse pushing work. Automatically adjusts the rate of production to the slowest member (the constraint)
• Benefits of Economies of flow (doing one piece effectively) verse Econoomies of scale (batching work)

Firstly let me say that I have never used Biztalk (except for a brief personal experience back in early naughtys.. but I didn’t inhale). So I have always fretted over attempting to convince architects not to use it as I could not speak from experience. Sure I had heard about all the pain that people went through on a daily basis (Thoughtworks rescues many such installations) and the general concensus was to run in the other direction as quickly as possible. Historically I would have treated this as a technical argument, but I think the solution is a lot simpler.

So let’s pretend for a second that you have a “messaging” problem, let’s not get bogged down too much with the details. Safe to say you probably arrived at this problem through accidental complexity of using a database as your integration strategy. After time you had loads of services and applications tightly coupled together through database schema. Hundreds and hundreds of tables, stored procedures and nightly batch jobs later, you end up with a big ball of mud that only few people really understand. Cost and risk of change is high, as small changes require entire system tests as impacts ripple through the system. Basically nothing gets done very quickly!

You may have even dug your way into further accidental comlexity with SOAP and an amazing Service Orientated Architecture. Now you services are tightly coupled with XML and your business processes locked in stone. This spaghetti junction of services has lead to a high cost of change. Basically nothing gets done very quickly!

To be fair, you may have also had some essential complexity, with hundreds of services needing to collaborate with each other. Each requiring their own formats and transformations.

Enter BizTalk. Now I am not going to say a bad word about Biztalk, that’s not the point. In fact, I’ll even go as far to say that it is an amazing product (having never used it). It will solve all your problems and eventually it will solve EVERYBODYS problems, because that’s what Microsoft want and that is the point. More featues will keep being added, it will even one day do HATEOS REST, because the cool kids do it. Heck it probably even does it now for all I know.

One thing it will never be is.. simple!

Not everyone will understand Biztalk, they can’t possibly, it’s too complex, it’s too big, it requires specialization. All your systems will have requirements funnelled through a single messaging platform and only a handful of people will be able to do the work. You will have created a huge bottleneck for work to pass though and… Basically nothing gets done very quickly!

So let me tell you a little story about a local company called Hackney Minicabs… and for those not living in London please feel free to substitute any names, cab company, locations and airports near you.

Now Hackney minicabs was a modest local cab company owned by an East london born ‘n bred geeza named Colin. Times were tough for old Colin! Increased development from the Olympics meant more competition and of course he was still recovering from the global financial crisis melt down a few years earlier. Colin’s business thrived on Airport runs, “Speediest trip to the plane innit” was their proud tried and trusted slogan which backed each and every business card of Hackney Minicabs.

But with the increased competition the bread and butter airport run was under attack and Colin knew he had to make serious moves to secure the future of the business. Hackney Cabs quoted a time of 50 minutes which was the average time to the nearest airport, Stanstead, but Colin knew this could be improved upon to at least 30, surely, and began to put his mind to work to reach this goal.

Now first off Colin knew that minicab driving was not the most rewarding or fulfilling job and his drivers were mostly uneducated or lacked necessary visas to work unhindered in the UK. Colin thought that clearly they lacked the motivation to do outstanding work. So, to launch the the new “30 minute airport run” campaign, came an advanced driver compensation incentive scheme (ADCIS), which would pay a bonus to any driver who hit the 30 minute target with diminishing returns to the current average of 50 minutes.

After a week of the new improvement program it was clear that it had been effective on only half the drivers who had improved on the average, some considerably, but none had hit the the new target. Clearly there were drivers who could not be motivated and Colin did not want these type of people involved in his company and promptly dismissed them! The remaining better workers were given extra shifts to cover the gaps until new and more motivated drivers could be found.

Another week passed and Colin let the improvement program continue, with mixed results, times were disappointingly average at best. Since these were the best drivers, Colin thought he would pull one of the better drivers aside and ask what could be done to help him improve. “My minicab is SO old and gutless” the driver replied. “A-ha”, Colin thought, clearly the problem was with the tired old cars they used. This was an important revelation and so obvious, better cars meant faster airport runs and most importantly better customer satisfaction.

With immediate effect, hard earned saved funds and a loan from a local shark, Colin shelled out for 5 new cars from a local dealership at a price that couldn’t be refused. Fortunately he had a mate, who knew a mate, who knew a mate, who got brill deals on the new high performance MPV he saw on Top Gear last month. Within a couple of weeks the new fleet was operational and Colin’s confidence was riding high.

The times began to roll in 55 minutes, 60 minutes, 65 minutes… this was crazy, despite the faster engine, stiffer suspension, racing tyres and turbo the times were slower than ever? What was wrong? Colin pulled the same driver aside in a performance review and asked why? “The car is so new and shiny, I’m driving more carefully so as not to damage it”. This was certainly an unseen side effect. After some coaching and pleading with drivers to ignore the state of the cars, times began to drop, although only enough to bring the average down to 48 minutes. However to Colin’s dismay, this was no way near the target of 30 minutes.

Through the chaos there was one driver who was consistently better than most. Young 22 year old Zubair, another local Hackney lad who had charisma and obviously the skills and drive to achieve the goal and who regularly achieved 35 minute airport runs. Colin appreciated his talents and sent him forth to train the other drivers in the passion skills needed to turn the business around.

Amazingly times began to tumble, the following week airport runs hit 45 minutes, 42, 40 and then 38 minutes, things were looking good. Colin cracked the bubbly, finally he was on the road to success and the local market would belong to Hackney cabs once more.

Unfortunately, the following months ended in misery, two of his best drivers were arrested speeding and lost their licenses and several long time customers complained of rushed and uncomfortable journeys with bags being hurled into and out of the cab. Business was suffering and customers were defecting to the competition in droves. Crippling loans had to be repaid and cars had to be sold, word had got around that Hackney Cars was not a good place to work.

The rest of this story is a sad tale of loan sharks and broken limbs and not one that needs to be told. But what can we learn from this?

After nearly six months without a camera, after my Nikon D40 was stolen from our Hotel room in Ibiza, I have finally splashed out and bought a replacement. I was not looking for a full DSLR, but something more portable yet still in the pro-sumer space. A good friend of mine Hamish had been using a Canon G10, which took great photos and was nice and sturdy and the new Canon G12 10MP

model looked very appealing.

I had heard a little on the Micro Four Thirds system and I felt this probably offered me a little more longevity than a standard portable. The other cameras that peaked my interest in this space were the Sigma DP2

, the Olympus PEN E-PL1

, the Sony NEX5

and the Panasonic Lumix DMC-GF1

.

I began comparing these cameras on various review sites and weighing up the cost, features, megapixels and image quality. After a while I was more confused and felt no closer to a decision. Then I remembered the Flickr camera finder which allows you to search all the photos on Flickr by their EXIF data. I was able to view the types of photos that people were actually taking with these cameras. This made things much easier and now one camera stood out as more than all the others their users took the kind of pictures I like to take.

and the winner is…

Now I’m off to shoot some pictures, I’ll return with my first impressions soon.

Recently on a project we had the pleasure to work with a colleague of mine Alex McNeil, in what I thought was a very interesting and successful way of developing UX friendly designs.

The story starts off with a familiar tale, we had just been given a set of designs from an external design agency, which according to the client developers had a history of excruciatingly painful changes. Even more so, was that the so-called “web” designs, were semantically incorrect, ie having a radio buttons for optional choice fields, or standard editable text fields for static read only data.

The marketing department loved this design agency and would fall into the habit of requesting 1001 changes, which would ultimately blend changes in behaviour as well as aesthetics. The poor developers would only find this out through constant revision after revision of print outs of the designs, just to notice that “that check box is now a radio button, because the field is no-longer optional”. You get the picture…

So how did we turn this around?

1. Taking control of the designs – almost day zero of the project we took ownership of the designs and proclaimed that all changes must now go through our designer Alex, the BA and developers. Changes were still welcomed, but now we could control their arrival.
2. A Living Prototype – this idea was born from chance more than anything during the project inception after estimates were presented to the client. In short, our estimates were far too long, in fact they needed it done “next week”, an impossibility! The client would not move on this date, and when asked why the date could not be moved it was due to a national sales conference. They needed something to demo. Ahah! What we needed was a living breathing working prototype (more than a wireframe), that looked and behaved like the real thing but could be done in a week, whilst the real application proceeded along it’s merry way.

So how did this work technically?

Although we were using Asp.Net MVC and string template, this same technique can apply to any templating engine that allows you to partition and include sub-templates within other templates.

We first created a “Demo” controller, from which Alex could begin working from and creating static html templates, styling and any “fake” javascript functionality. The master page and sub templates which were to be shared later on, were placed in relevant view folders matching the expected future controllers.

/static/js/demo.js

/static/css/real-style.css

/controllers/DemoController.cs

/views/Shared/master.st

/views/Demo/index.st (drives out sub-templates, master.st and real-style.css)
/views/Demo/page2.st
/views/Demo/page3.st

/views/Real/indexSectionA.st

/views/Real/indexSectionB.st

/views/Real/page2SectionA.st

/views/Real/page2SectionB.st

/views/Real/page3SectionA.st

As stories were picked up and played and “Real” controllers introduced, the new pages could pick up the shared sub-templates (with styling) and inherit all of Alex’s goodness. More and more of the sub-templates were included as more and more functionality delivered.

/static/js/demo.js

/static/css/real-style.css

/controllers/DemoController.cs

/controllers/RealController.cs

/views/Shared/master.st

/views/Demo/index.st

/views/Demo/page2.st

__/views/Demo/page3.st

/views/Real/real-index.st (uses sub-templates, real.js, real-style.css)

/views/Real/indexSectionA.st

/views/Real/indexSectionB.st

/views/Real/real-page2.st

/views/Real/page2SectionA.st

/views/Real/page2SectionB.st

/views/Real/page2SectionB.st

As complexity grew in the “real” controllers and changes in the type of data sent to the sub-templates, the demo controller was brought up to standard so that it could send equivalent data into the view.

The greatest benefit of this living prototype method is that, because the app could be demonstrated working much sooner, it enabled many iterations of feedback before the actual stories had even been played. This lead to far fewer changes in behaviour at implementation time. Given the chance this is a technique I would definitely use again in the future.

My fellow Thoughtworker Greg recently posted about our revolutionary experiences and experiments with team formation and delivery at our current client.

I wanted to expand a little more on a subtle and incredibly important point that has lead to the success we have been having. Our wall, as described by Greg, has only a single central delivery column “in progress”. It is what happens here that makes our new team formation a kinky success.

Traditionally in perhaps an XP style team, you would have dev pairs assigned to a story, which is then handed off to a QA, who writes defects against the story, which the dev pair fix, and is retested and so on. We decided this doesn’t work… well at least for very long anyway!! Before long (usually towards the end of a release) cards and defects get piled up into one big traffic accident of a story wall. Any “Individuals and Interactions” goes out the window, whilst we cling to the ceremony of raising defects, reading defects, closing defects, explaining defects, re-opening defects, explain what those changes to the acceptance criteria were you missed whilst at lunch. What is all this craziness? It shouldn’t be this hard? Delivering software, should be sexy!

Sexy?

In our new team, we have Threesomes, some times several at once, and I’m not sure what that is even called (never was that adventurous)? No longer are there dev pairs, now there are only delivery threesomes, two developers and a QA. This is the subtle and overlooked part. It is only as this combined unit that a story is delivered.. together as one intertwined collaborative ball of sexiness.

So what are the logistics of this? Surely people will be sitting idle?

Firstly there is the story huddle, which I won’t go into great detail as this deserves its own blog post. The acceptance criteria are read together as one team, we get the breaking news on the story and a shared idea of what will be done and expected.

Next the dev pair formulate a plan on how they will deliver the story to the QA. This is a valuable pairing technique, known as micro-tasking and usually involves a bunch of stickies. The stickies break the story up into more vertically sliced, micro end-to-end business functionality (not technical functionality), which can be individually showcased.

The dev pair continually share, showcase and communicate with the QA, who continually explores and probes the virgin behaviour that is just delivered. This continues until the the development work is complete.

Now the crux. If development has finished and QA has not, then the dev pair then submit to the QA, who instructs them at their will to do all that they desire and more. When and only when the QA’s appetite is fully satisfied and final climatic showcase has ensued, can the dev pair return to the awaiting pile of stories.

Although, our new threesomes are not faithful within their new found relationships. If when a story is finally complete, there are no more stories to pick up, then attention is shift to new meat in the BA. The developers or QA, remove their current hats and get stuck in with the juicy task of analysis. (There’s probably a metaphor in there somewhere, but I won’t go there.)

Finally, if we find our dev pair has finished entirely too prematurely, and there is nothing more that can be done with our QA. Then we still do not pick up new stories, but go off to satisfy ourselves, with trusty old tech-debt cards.

Has this Menage a Trois been successful?

As Greg pointed out, we have only yet raised one solitary defect since October. This was caught and fixed within the Sprint the story was played.

Thought I might kick off my blogging life, besides the obligatory “hi mom – will this thing last” post, with an ever so brief description of the title of my blog and Raison d’etre.

Developing – a play on words really, overloaded to mean developing (my software development), developing (my photography/film) and developing (as in early childhood/cognitive development and what I most want to get out of this blog)

the – definite article no explanation really.. (geeky I know)

right – another play on words. right (as in correct) and right (as in right hand or creative side of the brain)

brain – the thing that I am hoping to change by blogging

Earlier this year, I found myself in a vicious cycle of attempting to read, watch and listen to every possible source of developer news available. From blogs, twitter, news, podcasts and video casts, on a wide range of topics. The information was in many cases taking a one way journey in one ear and out the other, so to speak, and worse still the more I consumed the more I realised I was missing out on (hence the viscious circle).

The epiphany came to me after listening to, ironically, a podcast by Tom Kelley from the Stanford University ETL series titled Young at Heart: How to Be an Innovator for Life. Tom gives some excellent tips for increasing your level innovation and creativity, the take away points being;

• Think like a traveller
• Treat life as an experiment
• Cultivate an attitude of wisdom
• Use your whole brain
• Do what you love

This really struck a chord with me, so I read his book The 10 faces of innovation The Ten Faces of Innovation: Strategies for Heightening Creativity

. The logical conclusion was basically, I consuming too much information, I had no time to think, no time to create. So hence this blog was born.

So the first step… admiting you have a problem…

Hi may name is Christian and it’s been 56 days since my last podcast…

Thought I would give this blogging thing a try. I wonder how long it will last?