Minicabs and Software development

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?

Back in the game

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.

Living prototypes

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.

Ménage à trois in kinky teams

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 Ménage à 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.

So whats in a name?

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'être.

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...