In fair little New Zealand, builders and construction workers have to comply with the Building Code. This means all building work in New Zealand must adhere to a standard dictated by the Law (which BTW is true even if the work itself doesn’t require an official Building Consent).

Lawyers, likewise, must practice…well to the law! But there’s also the New Zealand Law Society — the regulatory body for the industry. Their powers are set out in the Lawyers and Conveyancers Act 2006. So to be a practicing lawyer you must hold a current practicing certificate issued by the New Zealand Law Society.

Doctors also have to be registered with The New Zealand Medical Council, who carry responsibilities in the areas of standards, conduct and competence. They are just one of (at a cursory search) 16 regulatory bodies who operate under the Health Practitioners Competence Assurance Act (2003).

You get where I’m going here. Most industries have a regulating body and certain formal guidelines which outline compliance.

‍

Software developers… well, um, we have… Agile?

And therein lies the rub ladies and gentlemen. We have some frameworks and methodologies and buzz words — but no governing body, no law, no regulations or compliance codes that software developers have to adhere to.

When you’re shopping around for a builder, doctor or lawyer you can look at their fundamental competency and other soft factors like personality, attitude and like-mindedness.

When an entrepreneur is looking for a software development house to partner with, how do they choose with no regulatory body and formal guidelines of compliance? How do they choose the right people to get the best outcomes?

‍

“Agile” isn’t the answer.

Agile, in case you didn’t know, is the buzz word de-jour. Not just in software but in other industries too. If you’re looking to hire a software development house they will certainly roll out the “Agile” buzzwords.

Now, totally realising the following statement isn’t populist to say (and daring to throw shade on anything related to Agile) I will state boldly:

‍

I believe that any framework is purely how you could get to the great result.

There’s nothing wrong with Agile — we use it. And in most situations it can be used to achieve that great outcome. But it doesn’t make the great outcome guaranteed. Or indeed speak to the competency of the supplier.

I want to make a strong point here: Agile is not a silver bullet.

If you’re looking for a development partner just because they follow Agile frameworks — it doesn’t actually mean anything. Despite what they might say. My thesis is that you want to find ethical, smart people who can get things done (read Joel).

You need ethical people because in choosing any collaborating partner you need to have a trusting relationship. With people who act honestly and truthfully.

You need smart people because what software developers do is not trivial by any means. It requires people “smarter than the average bear” to quote the old Yogi Bear cartoon. However, we’ve all met smart people who can’t get anything done. So you need smart people who can actually move projects forward! And Agile has nothing to do with that.

It’s a framework — not a qualification. The framework/methodology de-jour serves the outcome, it’s not the outcome itself. And it’s not how you choose a development partner. Agile has its weaknesses too. So choosing a partner who understand this is really important.

For example, Agile (and Scrum in particular) doesn’t solve the problem of estimation. We have to get down that cone of uncertainty to get accuracy, especially with bespoke software.

There’s a solid thread of consistency when I talk to colleagues and peers in the industry about Scrum practice. The idea in Scrum is that, somehow, you can get the team to estimate accurately eg. how long a user story (or part thereof) will take to complete. The more mature the team, the more accurate the estimations. This is how the team commits to what deliverables can be completed in a Sprint. The team estimates and commits to delivering within the sprint and set of outcomes.

Hmm… seems reasonable, right? Certainly in Japan (or any manufacturing industry) where a lot of the concepts in Agile originate from, it’s very reasonable to predict how long it will take to make n nut / bolts /desks / cars. Timings can be predicable if you’ve made the item before. Estimating accurately should be reasonable. With little variation or dependencies to worry about. What did it take previously? Well, it should take that times n.

‍

‍

But is software the same?

Sometimes it is apples-for-apples if you’re estimating something you’ve done before a number of times. Like configuring an “off the shelf” software application or building the same Form to Database. Then yes, you can estimate accurately.

However at EndGame, we’re almost always building bespoke software. Sometimes we’re solving similar problems to the past, but we can be building software with little comparison, lots of hidden complexity, and hidden dependencies. It’s just not reasonable to expect the estimate to be 100% accurate in this case.

Without an accurate estimate, the squad will never complete what they’ve committed to. Typically, sad but truthful to say, the estimate is always too low. In 30 years in the industry on projects of all sizes with different types of people, I’ve seen this repeatedly be the case. Under-estimation (in the context of Scrum Sprints) leads to the Squads feeling failure, frustration and then blame that things aren’t fun…

‍

Scrum Poker is often bandied about as the solution.

Wisdom of the crowd: the squad all guesstimate and then you compare these guesses and talk about the differences and try to get a consensus. For those not familiar with Poker it’s a gambling game. Scrum Poker can help a little but the fact we’re using a gambling game to create an estimation... will that really help with hidden dependencies and complexity?

Estimation is not a new problem, it’s a known problem — and there are many books written about it. There are plenty of methods to getting the estimates more or less accurate. We have to get down that cone of uncertainty. Does Agile help with that? Well the methodology won’t help estimate. To be blunt, a monkey with a wrench (or a monkey with a computer) is still a monkey.

‍

So what do you look for in a developer?

Well, there’s no real certification or law that governs industry best-practice like our lawyer, builder or doctor friends. Certainly don’t choose developers because they say they use Agile. And avoid someone who says they’re 100% accurate with their estimates — they are deluded or untruthful.

If an entrepreneur is looking for a software development house to partner with, to build bespoke software — to add a competitive advantage to their business they need ethical, smart people who get things done. People who may use Agile but know its strengths and weakness and can mange them. People like the team we have at EndGame.

‍