Published: 11/10/2015

Scrum while great in theory is in practice a really flawed process of creating software. Scrum is iterative waterfall. Scrum is process hell. Saying this, may get me shunned and kicked out of the Agile club. But I really believe that the bane of our industry is the process management called “Scrum”.

Scrum is Agile

No it’s not Agile. Scrum is anti Agile. It calls itself a Agile approach or methodology but if you read the Agile manifesto scrum by that definition is never going to be Agile. The process of Agile is the prioritizes people and interactions over processes and tools.

Scrum has many “ceremonies”, it feels like going to grandma’s old church services where the people repeat what the “Scrum master” says, listen to the ideas put forth in “Sprint Planning”, “Grooming”, “Stand up” etc.. It’s boring, its old, it leads to pointless meetings run by people who don’t write software, who don’t understand the technical process behind writing software and don’t always care.

Adhere to the sprint commitment, even if you have to work over time. You committed so you have to deliver. Since when did a human ever estimate something accurately. We can’t even do this when building sky scrapers, let alone a  5 million dollar software project.

How to be Agile

Accept that Agile is about people first and foremost. What will move you quickest to the goal? Be pragmatic. Don’t waste time on pointless meetings like planning or grooming if that’s not what will allow us to move faster.

Use standups for what they’re designed for, they’re not for updating your status to your managers. It’s about quickly getting the team unblocked and moving fast. Stop meeting everyday at 9 am. Start meeting many times a day, if there’s a blocker, get the people you need in a room, stand up and unblock the thing you are working on.

Agile is about moving fast, building working software today and delivering with changing requirements. Scrum can’t change without process during the sprint cycle, this inhibits your ability to change and move faster. What if yesterday the requirements were X and today now they’re X and Y? What if you can deliver both today rather then next sprint? Doing it today might be better then next sprint .

Move faster

You need to write tests. Does the UI render and do its thing correctly in all happy paths? What happens when the data is bad? Test your APIs, do they contain the right contracts, ensure that they are returning the correctly formatted and designed data and that they contain correct data. Test performance and security.

Can you ship what’s on Master right now? If not you have a lot of work to do. Master should always be ready to go to production. If you can’t, you’re not Agile.

Writing tests reduces risk, If you refactor or redesign you can ensure that the system won’t break.

Screw unit tests, test the contracts

I bet you 90% of the time your code isn’t doing something totally unique like calculating the cost of a family of 5 with disabilities and all kinds of heart issues. Test where it makes sense, unit tests can be great but they tightly couple your tests to your code, making it really fragile and anti Agile.

This is where contract testing comes in. Test the contracts between classes, what is the public interface? Ensure this always does something sane even with bad data. Test the API contracts! Ensure the API returns valid data, validate with a JSON schema or an XML WISDAL or whatever schema you can get for your API.

Test UI contracts. Whats the main success scenario? What is the common path, Test functionality, not design or placement.

If you have to, use Kanban

I think most processes are a waste of time expect Kanban. Have a few simple columns:

A card doesn’t have enough details! So ship it back to undefined or get out your chair and talk to the person who wrote it!

It has no task hours: Humans suck at estimating. Instead log actual hours if this is a important metric (ex: consulting company).