After a lengthly break from blogging, mainly due to the nature and intensity of my work changing, it occured to me….  that I didn’t have enough time, in fact, nobody had enough time… something that needed to change…

Divine revelation?

I was actually inspired by my local church on this one, on a message about developing margins for other people.  Being 100% busy is a symptom of the times especially around the western world, especially in London.  In the “church context” it was about having time for your neighbours, and even turning up to church early and hanging around afterwards spending some quality time with people, rather than dashing in and out, leaving barely enough time to say a “hi” or a “bye”. 

The rat run

I was challenged by this, not only on the personal social level but also on the commuting level.  From the simple task of how a commuter crowd fails to efficiently navigate through the turnstyles at Cannon Street station, using only 5 of the 15 available gates because they are in a rush thinking only of themselves, in doing so causing congestion for others by blocking the routes to the other turnstyles, if only they would invest a couple of seconds to spread out a bit, a couple of seconds cost to individuals works out to a minute saved for the poor people at the back.  To the “rat runs” in London where people barely leave any margin between cars, busses, taxis and errant bikes while crossing the road, near misses becoming the norm.   I have seen a couple of people lain out on the road over the past year because they got their margins wrong and been hit by a cyclist. Speaking of safety; margins also exist on the motorway suggesting a safe distance between cars.

margins used in traffic

The workplace

What I am most interested in are the margins in the professional realm of software development.  You could expand this to any aspect of project management too.  Now this is an area where there is some recognition from other professionals who realise that a project should have something called “contingency”, a good project should have “contingency” in its plans, its a good high level rule thats generally accepted, but it doesn’t tend to get looked at in any great detail. 

If it works, then lets figure out why, and exploit it.

Margins

Margins can mean many things, from the white space that surrounds the context of a page to the type of financial collateral used to cover credit risk.  The margin context I am referring to is the provision of buffer space between the time you take to do something and the boundary which is set to do it.

How margins work:

On a personal level:

They enable you to help others, at “your expense” and “their profit”. 

It enables other to help you, at “their expense” and “your profit”.

The net effect is that at a cost to the individual, the team wins.  Not only that the individual often wins too as by seeing a problem from a different context, gains domain knowledge.

At a project level:

During estimation if you leave a margin for development and delivery:

You invest the cost of delivering later to:

1) De-risk the project from a late delivery due to unknown factors
2) Accommodate late changes
3) Invest in quality for reuse and building future projects
4) Invest in accuracy and quality of the current deliverable

At a department level:

If you leave a margin for your yearly book of work you:

1) Promise fewer deliverables up front to reduce the risk of the compound effects of delayed and late delivered projects
2) Promise fewer deliverables to allow the teams time to reflect and improve on how they are working and therefore deliver more effectively in the future
3) Promise fewer deliverables to help retain team members in the organisation and therefore their learned domain knowledge.  Therefore removing the need to invest in domain knowledge again and again due to a higher turnover of staff (with little guarentee of success or margins at any level).
It sounds a bit like common sense does it not?

The endemic underlying challenge to margins

Firefighting, Inherent Win-Lose mentality and rewards are the anathema of margins. 

Firefighting, robs us of our free time, it is usually unplanned work of high urgency requiring 100% attention at the cost of everything else. Firefighting is the precursor to more firefighting in a viscious circle as often the time required firefight (eg. code quality checking, QA windows etc..) cuts into the margins (if any) to produce good code in the first place.

How not to use margins

I have seen margins being used only at the end of a piece of work, these margins inevitably get used up.  This is when people dont invest the time earlier, but allow it to be eaten up later.  An hour not invested at the start of the project to make something better, will easily expand to five hours later.  The end result being that the quality isn’t there. You need to apply margins on multiple levels.

Do not confuse margins with planning

The more planning you do at the beginning of a project the more re-planning you will need to do mid way through the project when you begin to deliver the code, and find out that it needs tweaking or there were a few issues with testing.  What the margins enable at the beginning of a project is to invest in quality.  The margins you will have at the end of a project will help in added or changed functionality.  The cost of change is lower because of the quality of resuable code, the fact that nothing was rushed due to late night working or high pressure means instead of fixing bugs in the provided margin, you can actually add or refine functionality.