Your MVP is not a finished product. If you spend too much time thinking about your product, you'll never have a product, because no-one will ever get to use it. Why don't you just deploy something small that somebody actually needs? You can just fix it after you find out it's wrong. But you need to fix it fast. - Joe, this guy, right here
Rules are for professionals. Smart people made the rules. Maybe I should follow the rules. You know, the same rules that everyone follows. If everyone follows them, maybe they're correct?
Ya, maybe. But so what? Are we thinking about things at all or following rules? Are they simple rules? How serious are these rules? Can people get hurt? Will I fail? Will I be the cause of someone else's failure?
Will these rules persist long after I'm gone? If not, will I have been wrong for following the wrong rules?
Should I have therefore been thinking about the wrong rules and why they're wrong?
Or do I just want to get to a minimally viable product?
One of them was the freedom to just write stuff down. I feel the same way when I code just for the sake of coding. I realized today, when trying to blog for the first time, that I forgot a bunch of grammar rules I learned back in my school days.
And then I thought, should rules prevent me from doing something?
Probably. But it depends.
There are so many things to think about. And man, I could go off. But, what's important? That's usually a good start.
When I'm writing software, I usually think of how cool I can make my code. I say usually here because I still think of optimization at the wrong times, but at least I catch myself and go "Hey Joe, STOP IT". My customers have never cared about the cleanliness of my code. But they do care when I can't change it quickly. That's a personal rule I choose to follow because of experience writing code and having customers change their minds. This pretty much sums up the point of agile software development.
If I cared so much about my code, more than delivering my product to a customer who is waiting anxiously for me to produce value for them, would that choice cause me to fail? Yes.
If I cared so much about my grammar, more than --just starting my blog--, would that prevent me from --starting my blog--? Yes.
So there it is. Rules in real life are just personal guidance usually preventing us from making mistakes.
I don't mean that like "Agile is the best".. I mean that like, "Agile is now like a thing and an action combined instead of a bunch of good ideas that you can cherry-pick as long as you actually know what the hell you are doing".
I can take Agile's rules, write an Agile Rule Library and share it on NPM for JS consumption, and share it on NuGet for .NET consumption. Or you know what, maybe I'll create AAAS - Agile as a Service - feel free to pronounce that however you see fit. Then that should fix everything, right? We'll all be on the same rules, our work will get rejected when it doesn't fit the rules and we can all live happily in Agile bliss, analyzing our work against the rules, making up story points for making up story points, and staring at charts until we realize - we have no MVP to deliver.
Agile is a word. Neo from The Matrix is agile because he 'moves that fast' and Trinity 'never saw anybody move that fast'... 'how do you move that fast,' she asks him. He, due to a well-encapsulated system designed by 'the machines', doesn't know how to answer that question.
If a customer asked me anything about my code, I would have the same Keanu Reeves look on my face. My reason though would be more like 'Did something go wrong? How are you seeing the code? Tell me what's wrong with the thing you're using so I can deliver a better thing.'
The bottom line is this: You gotta deliver fast. You gotta get and respond to feedback fast, directly from your customer. But you gotta remember, your MVP will suck until it's not an MVP anymore. It's up to you to ask why it sucks and do something about it. And hopefully move as fast as Neo does.