Category Archives: Scrum Master

Scrum Master

agile ref

Agile Introduces Delays Again

It’s gauranteed with Agile. Use the methods and your project will be late and overpriced. Many of the features your end-users were looking-forward to will have been descoped. Your product will be full of bugs, have terrible performance, and will show a return of issues that we haven’t seen since Windows 3.1.

Regression

You developed software a decade ago that has served you well, and you’ve earned enough to modernize it for today’s requirements. You bring in an Agile consultant. A year later your software that could handle character sets from anywhere in the world now has a restriction that filenames have to be in a format of eight alphanumeric characters, a dot, and a three-character extension.

Well fucking done! Give yourself a Scrummaster of the Year award for that one.

Security? Performance? This is Agile we’re talking about. Performance is something Agile practioners arrogate to themselves for the number of meaningless story points they’ve made up, and security is something that an Agile job, let alone an Agile product, does not provide.

Editing text files by sending the updated text through vanilla XML might make a nice story up on the board, you can even demo it if you choose your text carefully, and you may give it a billion story points if you like. Just don’t ask anybody with any experience of these things for test data. They will ruin your day. Your whole week if it means you have to instruct twelve teams to refactor, delaying the demo.

Focus

Whenever Agile is introduced the focus always changes, and for the worse. No longer will anybody be interested in the end product, only on the next demo. It is getting “happy path” tests through the demo that counts. Budgets depend on it.

Talk of the all-important budget is largely forbidden by Agile whose own ‘manifesto’ suggests that contract negotiations are of little relevance to commercial software development. So if you’re Agile you should stop reading now. The rest of this article is about who pays the bills, and you won’t be interested in that.

It’s large companies that have the budgets that skilled software developers command, and these mainly bring outsiders in to do development. Many, perhaps most, software development teams are externals now. Either working for one of the behemoth body-shops, small software houses, or independent contractors.

None of these people will remain on the project after it is delivered.

Typically a software project delivered to a corporate client will be immediately handed over to a different set of externals who will try to support it. Support it without having any knowledge of its development – which will not be a lot of fun for them. Debugging other people’s code never is. But they will be Agile and they will call it DevOps and all be well – apart from the end-users who will have to find something else to occupy themselves with during the downtime.

Bottom Line

As professionals with a passion for our business we at the skankworks.net always strive to deliver the highest quality systems with the resources available – and this frequently gets us into trouble and makes us enemies of the “just meet the baseline” Agilistas.

Which is fair enough. Given the focus on the demo that the customer requires and the inevitable parting of ways when the software is finally delivered, why should people waste their time and effort concering themselves about things that will only occur – if they occur – long after they’ve been ‘let go’? They’ve got bills to pay as well, and if the best way of paying them is by keeping somebody with budget happy on a short-term basis, then good luck to ’em.

There are no penalty-clauses in Agile. They prefer to woo the clients with a constant drip of contrived demos and happy talk, than bicker about trivia such as whether they are fullfilling their contractual obligations or not.

As long as they get through each demo along the way they will get paid. If the software they deliver falls over when it gets into production and proves itself not fit for purpose they will not be held accountable. There will in fact be no recourse for the customers who will find that they have purchased a shoddy product because they thought they could use sprint demos – with the unspoken but ever-present threat of immediate job-loss – in lieu of testing.

Such customers bring this entirely upon themselves by thinking they can replace permanently employed and responsible staff with a methodology that promotes short-term thinking, short-term employment. In an environment where individual and group accountability resets to zero after each demo and disappears altogether the moment their final pay-cheques are cleared.

Hacking together demos is easy.

Writing reliable value-for-money software is hard.

Anybody who tells you that they have a method for sale that will make hard things easy is pulling your leg. Trying to cheat you. They’re trolling you, to put it in the vernacular.

Caveat Emptor.