Thursday 29 April 2010

Technical Debt Credit Rating

A while back I wrote about how closely technical debt paralleled financial debt and then a short follow-up post with the meta-message that, through the right reductionism, certain things will always cost you an inescapable minimum and the decision that you really have is about where you choose to make that payment (I argued that you either pay through the correct design and build initially, or you pay through unnecessarily increased maintenance costs later).

Outlawing technical debt is as foolhardy as always cutting corners - sometimes the right thing to do is to take a hit to get something out sooner or in a certain shape - the problem is in the repayments; in other words, they often don't exist. And if you don't go back and sort your hacks out early they tend to accumulate in the system and before you know it developing on it is like moving through treacle (and the treacle occasionally catches fire). Everything else you do takes that much longer and is that much more expensive (and those are business metrics) and can have unintended consequences - it's a crippling burden just like its financial counterpart.

I have a rule - no one is allowed to take technical shortcuts through a project [where that = incur some technical debt] without showing where, in the same plan, they go back to do some refactoring so that our long-term assets remain sustainable. We're pretty lucky at Sporting Index; most of our stakeholders value technology and recognize how critical it is to the business, so it's a conversation I rarely have to have - but I know many other companies are less fortunate.

So now I think I have a better idea. It came to me while I was thinking about why, if technical debt is so similar to real debt, it doesn't regulate itself in the same way - and I think that's becuase there is no concept of creditworthiness in technical debt, in other words no assessment of a team's ability to 'repay' a quality compromise (read: loan of functionality to the business ahead of when it otherwise would have been ready) alongside all the other outstanding quality compromises that they already have.

But we might be able to simulate that...

Imagine giving each product manager a 'credit rating' of, say, 3 - meaning they could call for unsustainable technical shortcuts 3 times as they worked with the delivery team to determine their solutions. Once those 3 debt points were used, that product manager would be unable to encourage the team to make further quality compromises until at least one of those was paid back. If you have product managers with a demonstrated track record of revisiting earlier deliveries to address technical debt then why not give them 5? A higher creditworthiness ought to enable an individual to take on more concurrent debt as we can be more confident that they'll come back to service it.

I pretty much guranttee that any product manager's cavalier attitude towards shortcuts would change and they'd suddenly treat technical debt as the instrument it really is and use it only where it mattered materially. That, ladies and gentlemen, is a feedback loop.

The downside is that you'd have to be better at tracking this sort of thing and, like any other method, it'll need some discipline when a product manager with maxed out technical debt points wants just one more shortcut. If you've ever had to maintain a spaghetti codebase (as most of us have at some point) then you'll know that these things need closely policed anyway, so perhaps being forced into formally tracking it isn't so bad.

Wednesday 28 April 2010

Nobody Wants Computers

Well they shouldn't - they should want what computers will do for them.

Many people turn up to conferences or SIG meetings and ask me how virtualisation or a centralised inventory database or VPNs (or pick something) will help their company. Misguided. My response is always the same - what is your business case and what benefits are you expecting? I do get quite upset when I don't get a good answer to that, because it means someone somewhere is cooking up some technology for technology's sake.

Sales functions are excellent at creating a need around a product they sell - great if you're in that business and I used to be - but it is the functionality your organization really needs that should matter. Talk to me about outcomes, goals, what you want to be able to do from a business capability perspective, and then the right technical solution will fall out of that.

Contorting business processes to fit a specific technology or vice versa - i.e. doing it backwards - only ever works when combined with a healthy dose of luck.

Friday 23 April 2010

The ISO standard for business plans

If I had a quarter for every time a budding entrepreneur has asked me about what should go into his business plan, then I'd have - let's see - three fifty? I don't know, but put it this way, it's in my top 10 FAQs. My two secrets behind this one are; a) there is no such thing as a standard format or expectation and b) it matters a lot less than you probably think.

Don't agonise over format and presentation - the vital thing is to intimately know your key facts and be able to provide a logical narrative for them. What are your costs? Where does the revenue come from? Who are your customers and how big is the market? How soon will you start bringing in revenue? How is your product different from any competitors (current or future)? What does it cost you to acquire new customers and what is their lifetime value? Have you done this before and who do you plan to work with? Even if you just talk through it you're always better off knowing those things inside and out than having a 200-page glossy document.

And when I say that a business plan matters less than you think it isn't because investors won't want one - they very much will - it's because in the early stages of a new idea what matters most is working product. The best, most detailed, most polished business plan in the world will always be worth much less to a potential backer than a pretty basic, hacked together but functional, beta product.

Monday 19 April 2010

What kind of idiots are in charge here anyway?

When I coach people about being effective in organizations something that regularly comes up is their ability to influence decisions made at the senior level. Because (with very few exceptions) most people in most organizations are rational and competent professionals with the organizations best interests at heart, any time they feel like their proposals or suggestions aren't being adopted, it can be easy for them to lose a little faith in senior ranks.

I never like hearing that because the truth is (again with very few exceptions) that most executives in most organizations are also rational and competent professionals with the organizations best interests at heart. So why don't your ideas stack up for them?

My advice is usually to look into these two things:

1 - What don't you know that they do - executives will usually have a much broader view of things and can therefore be privy to other information, plans or constraints elsewhere in the organization, that you may not be. Taking into account the things that might be invisible to you, not adopting your recommendations might well be the most beneficial course of action. In my experience, most executives are more than happy to share this information with reports who show an interest in the wider business, so just ask.

2 - What data aren't you being effective at conveying - sometimes the message just isn't getting through and therefore your decision makers don't fully understand what you're proposing and why. It happens to me; I see a lot of proposals for a lot of things (very few ill-conceived) and if the key facts aren't well summarised and the options clear, I am not able to make an effective decision. Again, the solution starts with communication. Ask why, use questioning techniques to check for understanding, find out how your audience wants things presented. I am yet to meet an executive who won't be willing to give that feedback - after all, it helps you both.

Answering these two questions usually gives people the insight they're missing to clear things up and, if it doesn't, then I guess it's always possible that you might be one of those few exceptions...

Wednesday 14 April 2010

Things change because people change

Occasionally I get a hard time for spending such a large part of my time with my teams, with the individuals, out on the floor in their work instead of in my office with 'my' work. Occasionally that's also fair - I have a different job than the people who report to me, and the the people who report to them, and that comes with different deliverables.

On the other hand a big part of my job is the performance of my department, the quality of their deliverables, and the continuous improvement of both of these.

New processes, technology changes, new policies, culture and structure are all part of it, but ultimately nothing is ever any different until individuals change their day-to-day actions and behaviours. You will never create lasting change by making rules and proclamations from behind a desk, or just by telling people to 'do better'. Lasting change only comes from sustained leadership focus; coaching and repetition and doing things differently together. When the man on the ground changes then overall results change.

Oh and don't forget my golden rule no. 22867: paperwork is an artifact of effective work - effective work is not an artifact of paperwork.

Monday 5 April 2010

Let's Ban Agile

Bet that made you look.

Whenever I'm dealing with the wider business and I come across confusion about (or resistance to) agile practices I typically find that, once the few genuine issues are swept up, much of what's left comes down to semantics. And fair enough too - the extensive metadata that has built up around engineering processes is intimidating.

If we put all that aside and just talk about the basic practicalities of doing projects, you are pretty much just looking at an inventory of requirements that must be turned into an inventory of working product. To do that, distinct individuals need to execute specific tasks within certain time constraints (or, more colloquially, who does what by when). From there, we build up some rules to make sure everyone can cooperate effectively around those basics, and it is these rules we'd tend to call our development process/project methodology.

It isn't any harder than that. But, for some reason, we like to make it sound difficult through a plethora of technical terminology.

Instead of iterations, why don't we just talk about tackling big projects a bit at a time? [In fact, I'm yet to discover a better way of solving huge problems than breaking them down into a collection of smaller ones] Instead of backlogs, let's just have a prioritised list of requirements. Instead of standups, let's just have regular and frequent meetings to keep everyone on the same page. Instead of sprint planning sessions why don't we all get together to iron out a detailed plan before we commit to our next chunk of work?

I guess what I really want to ban is unnecessary jargon - at least when dealing with the non-technical contingent of the business. I think we should use common everyday language to describe what are, ultimately, practical and common sense activities.

Just because we're solving complex and difficult problems doesn't mean we need to use complex and difficult processes - in fact, one could make a case for quite the opposite.