Posts Tagged ‘agile’

Conway’s Law

Wednesday, November 9th, 2011

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Magic potions Vs. Continuous improvement

Thursday, September 15th, 2011

In order to understand something, sometimes it’s easier to understand it by defining what the opposite is.

Recently, I was trying to explain to someone the fundamental principle behind continuous improvement was. Do you ever run into the scenario where you find yourself in a conversation and you hear:

“We need to build an X, it will solve all our problems and make our code bug free.”

Conversations like this, immediately sound off alarm bells in my head, because what’s essentially being suggested is a magic potion, a concoction to cure all ills, an elixir of eternal life or just plain old powered tiger scrotum.

The overuse of hyperbole and setting truly unrealistic expectations in software development only results in continuous disappointment, and slowly kills a team spirit and stakeholder trust.

Aim for steady incremental continuos improvement with small achievable micro goals, know when to pat yourself and your team on the back when they have achieved them, and make sure going off solo on a magical quest to slay a dragon get’s stigmatised and not rewarded.

Using Standard Deviation for velocity prediction

Saturday, April 2nd, 2011

Ever hear of the Two Standard Deviation rule (or the 2SD rule for short)?

The rule states:

There’s a 95% chance that a normally distributed variable will fall within 2 standard deviations (plus or minus) of it’s mean.

I was recently in a meeting where we were trying to predict velocity of a team. The team had collected 6 sprints worth of data, where they had completed, 20, 16, 5, 6, 4 and 12 story points (why the distribution was like this is another story).

Now the mean of the sprints is ((20 + 16 + 5 + 6 + 4 + 12)/6) = 10.5, which at first glance is what you might expect the velocity of the next sprint to be. But I wanted to go a level deeper and get a better idea of how accurate that was, so I used the 2SD rule.

Firstly calculating the standard deviation, I decided to write a small JS function to do it for me, if anyone can write a better one, I am always happy to see it…

(function(data) {

	var average, standardDeviation, i;
	for(i = 0, average = 0; i < data.length; i++) {

		average += data[i];

	average = average/data.length;

	for(i = 0, standardDeviation = 0; i < data.length; i++) {

		standardDeviation += Math.pow(data[i]-average, 2);


	standardDeviation = Math.sqrt(standardDeviation/data.length-1);

	return {average : average, standardDeviation : standardDeviation};

}([20, 16, 5, 6, 4, 12]));

So now we have 2 key pieces of data, the mean 10.5 and the standard deviation 5.9, lets apply the 2SD rule.

So standard deviation is 5.9 points multiplied by 2 is 11.8, making my minimum velocity -1.3 (is it possible to have a negative velocity?) and my maximum velocity 22.3.

The outcome of this is that I can say I am now 95% sure that the velocity will lye between -1.3 and 22.3 points for the next sprint.

Ok, that’s maybe not so useful, but it could be if I had more data and a slightly smaller bell curve (but it looks like we’re going through a Satir change curve at the moment).

Hiring programmers for their communication skills.

Sunday, January 23rd, 2011

Sterotypically for programmers, many many year ago I used to do martial arts.


I trained with a man named Nick Arnold in Canterbury college sports hall. I learned some valuable lessons from these few years of training. Once I trained with Nick’s trainer a man named Tony Felix.

Tony Felix was fairly legendary in the martial arts world. As the story went, he was originally a professional rugby player, with an interest in external martial arts. Unfortunately he contracted a serious life threatening disease so traveled to China where he sought out the most revered internal martial arts teachers, to learn from them. For many years he trained internal martial arts in the east and eventually recovered from his illness. Returning to the western world, he taught, had different jobs, from being a bouncer to being Wesley Snipes training partner and body guard. As I said, somewhat of a legend.

So the caliber of people I was training with there was very high, a lot of top students from other martial disciplines had traveled some way to come to this training session. In a stereotypical fashion of a high testosterone environment many of them were showing off. With various types of somersaults and high kicks. This made me feel slightly disheartened.

At the end of the training session, I went up to Tony Felix and asked him if he though it would be a good idea for me to go off and learn a single martial art really well before I got to the more advanced stuff he was teaching. I always remember his reply:

It’s much easier to take a good fighter and make him a martial artist, than it is to take a martial artist and make a good fighter.

For the last few days, this phrase has been ringing in my ears. Why? Because I have been interviewing.

There is a lot on the Internet about doing interviews and choosing who to hire. Personally I find Joel Spolsky’s interview guide to be a good general roadmap. Smart and gets things done is a good principle to live by, but it’s not so concrete.

For example sometimes I find myself in a position where I hear that someone is technically amazing, but that a candidate is not so good socially and this was why what Tony Felix said was ringing in my head.

I would like to take what he said and adapt it to the world of programming:

It’s much easier to take a good communicator and make him a programmer, than it is to take a good programmer and make him a good communicator.

It sounds obvious but sometimes it’s not. Think about it a moment. Perhaps a candidate has spent 5 years programming, that means he’s probably in the age range of twenty to thirty. But what has been doing the other fifteen years? Learning to communicate. If it’s taken fifteen years to learn to communicate and he’s still bad at it, then it will be a lot of hard work to undo that. Whereas if he’s a good communicator but inexperienced programmer, then in a few years time he will easily learn the programming skill but have the advantage that he can also communicate.

In the world of agile, where pair programming should become a day to day activity, communication and team work is key to being successful. Without it you won’t be able to create the innovation and productivity you need to survive.

So when hiring, communication is far more valuable than technical ability in the long term.

The google toilet.

Sunday, November 14th, 2010

When I was small I used to have a soft toy puppet version of Gordon the Gopher from TV’s Going Live!

As Gordon was a fairly large part of my then life, I went to all lengths to make sure he was fully integrated into the family. Part of this involved me building Gordon several miniature versions of common house hold white goods. The Gordon sized versions were mainly built from Toothpaste boxes, old sewing thread spools, straws and colored card. He had a washing machine to wash his various different coats, a vacuum cleaner (unfortunately Dyson had not invented his yet so this was just a plain old Hoover style one) and finally, in a fit of reality, racked with concern that he did not have anywhere to relieve himself, I built Gordon a toilet. The toilet was a fairly anatomically accurate recreation. It had a bowl, a cistern, a pipe connection to the cistern, and a small flushing handle.

What does this have to do with anything? Well recently I was lucky enough to come across this:



What the Fuck is this?

I can hear your brain exploding now.

Yes, that’s right my friends. This image here. This, is the future of toilets. The cisternless toilet.

One must assume that the reason for a cistern, comes from tradition. To get an effective bowl clean, a reasonable water pressure is required. Maybe in the past common households did not have this water pressure available which lead to the design of the high-up cistern, which then was moved down to the low down cistern. But now, in modern days, actually all that’s required is a simple valve to the local water system, that is controllable by the operator.

So where the hell am I going with this?

This problem is a brilliant illustration of a common modern day coding problem. The problem, at the beginning of a project you have certain constraints (i.e. low water pressure), then someone designs a system (i.e. the high cistern) to deal with this problem. Then someone designs a better system (the lower cistern), and then someone else designs a better more efficient but more complicated system (the cistern with two buttons for different flush types). But in reality, all that is needed is time, to wait for the constraint to be resolved, and then careful thought on what is actually needed, in this case, the simplest most elegant solution is just essentially a on/off tap.

This is why I call it the Google toilet, because it’s simple, elegant, robust, easy to maintain and repair, and it does exactly what you need it to do, without complicating the matter by giving you different options and choices to make (do I need a big flush or a small flush? hmm let me evaluate…). It reminds me of a talk on usability given by Aza Raskin of Mozilla:

Better practices : Another great Dan North Talk

Tuesday, November 2nd, 2010

Another great talk from the Simon Pegg of software. Don’t know how I missed this one and it’s slightly depressing that he was discussing this stuff back in 2007 and now it’s 2010. But anyway, I think his point about Lean production line development and software developement being different and more like car design development are very important and echo’d in the Poppendieck books. So sit down, get a cup of tea and take half an hour to watch this talk.

Life is one big game.

Monday, November 1st, 2010

I really like this Ted talk. I think when you think about it everything is a game. In that the definition of a game is a set of tasks that someone has to complete.

A very poorly designed game is called ‘everyday work’. A game where the reward levels are set too steeply. The rewards themselves are poorly thought out, the variability is low and worst of all it never ends.

It reminds me of a passage from the book “the one minute manager” by Ken Blanchard and Spencer Johnson.

“One night, for example, I was bowling, and I saw some of the ‘problem employees’ at work from my last organization. One of the real problem people, who I remembered all too well, took the bowling ball and approached the line and rolled the ball. Then he started to scream and yell and jump around. Why do you think he was so happy? Because he got a strike. He had knocked down all the pins.”

The rest of the book goes on to discuss that feedback is the difference between most work and the game. I think it is a little more complicated than that as the video above points out there are a few more reward mechanisms in place. But essentially the point is correct. Imagine if your job was as rewarding as a computer game or bowling? Everyday people would be happy to go in. This is how it should be, and it’s not a case of some people being lucky and some people being unlucky, it’s a case of job & reward design.

It’s interesting because I think some of the most compelling jobs are the ones where the design of the job is incremental and well thought out. Programming for example can be a very frustrating but reward experience for some people. The process of learning very small pieces and then being able to combine them to produce something much greater can be intensely rewarding. It’s very similar to a game we get small rewards for effort and then finally one large reward once enough time has been put in. The question with programming is where does your tolerance level lie? Some people have the patience to learn C++ without giving up at the more difficult hurdles like Malloc and pointers where as some don’t have that patience and are more adept at learning PHP.

Social jobs, for example counselling can also have a similar cycle but requires different skills, but essentially you see the same progression of small incremental rewards leading to a much larger reward.

My final great example of this is blogging, I wonder how many people would have a blog, if for example you didn’t have statpress to show you how many visitors you got per day?

So maybe tomorrow when you go into work, think about the design of your job and what you could do to knock down all the pins…

Scrum sucks… or some great videos on real agile and lean software production.

Monday, June 7th, 2010

He he. I’m sure I’ll get someone’s attention with that…

Obviously, scrum doesn’t suck, it’s just a large number of people misunderstand it, and get taken advantage of by ruthless ‘trainers’ who promise to solve all your problems with their magical new process. Maybe a more apt title would be “process sucks” but I like to enrage and make massive over generalised statements so there we go.

To back me up though, I am going to post these great talks by Dan North that I found recently. I’ve always been a big fan of his blog, and his articles about BDD and story analysis are massivly insightful.

Why your Agile roll-out is Failing - Dan North from Øredev on Vimeo.

Dan North - Our Obsession with Efficiency from Øredev on Vimeo.

Are sitewide redesigns counter-productive?

Tuesday, April 14th, 2009

For the last ten years I’ve made a living from implementing redesigned/rearchitectured websites, but it’s started to dawn on me that perhaps this isn’t the right approach to be going forward with.

As a coder I learned pretty quickly, the best way to debug something is the scientific methodical way. 

The first step is to identify the area of code/class which the bug is in,  this can be done in many ways so I won’t delve into my particular preference.

The second step once you have said offending class/method is to start logging and commenting sections out to see what fixes it. Now this is the step I’m interested in. 

Depending on your skill level with the language on first pass you may have a ‘hunch’ as to what the problem is so you’ll go straight for the quick win, you’ll change a variable and retest to see if it fixes it. If it works ‘woo hoo’ -> moveon. If not then go to the beginning and start blindly commenting out and testing variables, you may be in for the long haul.

The key though, and if you spot someone not doing this it either means they’re exceptionally competent or exceptionally inexperienced (read:  stupid, a moron, dimwitted, a duh) is that you do one test at a time.

The reason, if you change more than one thing and then retest and it works or breaks, how do you what did what? You don’t.

So a question: when as a company you do a sitewide redesign, how do you expect to know which elements for your redesign worked and which didn’t? Answer: You don’t. You hope that the successes outweigh the failures and that your client decides to pay you regardless. It’s very similar to the problem of knowing if your advertising is successful.

What secret successes went to the grave with this building demolition?

So rather than doing sitewide redesigns just for the sake if it, It would be far more prudent to take the existing site identify key areas which have both flaws and successes and start drawing up experimental alternatives to be designed and built, which can then be a/b tested and analysed in the existing framework and then ported easily into a new design ethos. This way there would be no more of the ‘hit it and hope’ mentality plaguing web design today.

The future of Agile project management tools.

Sunday, February 8th, 2009

robbie-the-robot-20020500Project management comes in various guises. Throughout my freelance and perm-ilance career I’ve worked for central government in Prince2 environments, advertising agencies with XP environments,  cowboy coding environments, no environment at all with the code stored on various people’s desktops and lastly Agile environments, which seem to be the flavour du jour.

With all of these methodologies comes various different tools to help you get the job done, from MS project & MS excel, Google spreadsheets & docs, adobe connect, sourceForge (resultsSpace2 from Sapient), Jira, BaseCamp, fogzBugs,  and most recently Mingle, a product of the company Thoughtworks. These are all products that do pretty much the same things.

They all have their merits and scalability, but I was thinking of what the next generation of project management tool and it strikes me that these key features will be required (in brackets is the software that already does this):

  • agile project management wall (Mingle) (- with a UI that makes it more like a mind map),
  • IRC style chat rooms (Mingle)
  • Video conferencing & Skype facilities (unknown as to who does this currently)
  • Generic upload capabilities of unlimited size (BaseCamp, mailbigfile etc.)
  • ScreenCasting abilities (Fog creek co-pilot, adobe connect, jing)
  • Time estimation tools (fogzbugs)
  • SVN repository (Sourceforge)
  • bug/task tracking (Jira, fogzbugs, mingle)
  • inline text editing (squizz CMS)
  • packaged Audit trail output(dump)
  • track changes style document/image commenting (MS word)
  • visual screen capture and comment - for bug tracking (Fogzbugz)

Anyone who can put these all into one nicely wrapped up box will come out on top (for the time being) and be able to sell their wares to all of the big agencies, IT consultancies and small players. Having all of these at your fingertips will significantly help to improve the painful process of client centric agile software development.

Also one major feature will be online/offline syncronisation whether using adobe air, wpf or google gears it is up to the vendor.

Most importantly in this world of GDD (global distributed delivery) and 24 hour timezones and economic crisis style proportions, there is one person who will definitely need it - moi.


I’ve just found a comprehensive run down of most web 2.0 project management apps out there for web projects:

trust me to be late into the game… again.