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.
No its not Agile. Scrum is anti Agile. It calls itself a Agile approach or methodology but if you read the Agile manifestoscrum 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 grandmas 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.. Its boring, its old, it leads to pointless meetings run by people who dont write software, who dont understand the technical process behind writing software and dont 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 cant even do this when building sky scrapers, let alone a 5 million dollar software project.
Accept that Agile is about people first and foremost. What will move you quickest to the goal?Be pragmatic. Dont waste time on pointless meetings like planning or grooming if thats not what will allow us to move faster.
Use standups for what theyre designed for, theyre not for updating your status to your managers. Its about quickly getting the team unblocked and moving fast. Stop meeting everyday at 9 am. Start meeting many times a day, if theres 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 cant 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 theyre X and Y? What if you can deliver both today rather then next sprint? Doing it today might be better then next sprint .
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 whats 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 cant, youre not Agile.
Writing tests reduces risk, If you refactor or redesign you can ensure that the system wont break.
I bet you 90% of the time your code isnt 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 witha 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.
I think most processes are a waste of time expect Kanban. Have a few simple columns:
A card doesnt 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).