My Agile Rant
A fair warning, this is more of a rant, rather than a post. This is not organized, edited, or even reviewed. So here we go...
I have read several books recently and I have realized that they are all saying the same thing, but often in a slightly different way. I wonder if they are actually trying to help people or trying to make a quick buck on a current trend.
Let's talk about Agile for a minute, if you go on Amazon and look for books on Agile, you will find 419 books. Yes, 419 books. In addition to that there are 155 books on Scrum and 84 books on Kanban.
Agile is not that complicated
Agile manifesto was summed in 24 words.
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
Let me summarize all of those books so you don't have to read all of this.
My Agile Process
Communicate some initial ideas -> Create a working prototype -> Review prototype and get Feedback -> Implement Feedback in prototype
Repeat!
That's it. We worry about estimations, budgets, resourcing, and so much more. Lets worry about none of that and create something.
I am seeing the higher you go up, the less you actually produce, but the more you get paid. That doesn't make sense to me. I get the experience but when you stop producing and spend more time creating documents to describe what needs to be created. I have created working prototypes in meetings while people are discussing what we should be producing... then I show them the working prototype and the meeting changes...
"OH, wow, you are awesome, let's iterate on what John created"
Yeah, no lie, let's take 20 minutes create a boilerplate and then start adding some functionality. Put away your powerpoints and google docs. Grab a white board, draw a brief workflow, and then do a prototype.
The faster you can get to working code, the faster the client can give you feedback
When you start dealing with fortune 100 companies, the management want evidence that you know what you are doing and they want metrics, case studies, and so many more documents. All of that comes down to one thing: Trust. They want you to prove that you know what you are doing so they can trust you to give you money to do what you claim you can do. Imagine if you didn't have to do all of that. Imagine if they gave you a week, paid, to create a prototype.
The Developer Matters
Then who would be the most valuable person? The developer. The one that is creating that prototype. Not the VP, not the creative director, not the client management social engagement creative technologist, We create so many titles, so many levels of hierarchy. People are worried about scale, and you can't scale a single human. That is why process is critical.
When you create a process that is repeatable, and templated, then you can create faster. Iterate faster, make those minor customizations for the client, and then handle multiple clients by a single person. Then you can train new people on those templates, and then you allow them to create working code faster.
The Designer Matters
I don't care how pretty something is, but if it doesn't work, no one cares. However, the second most important role is the design. You want it to be intuitive. You want it to present your brand in an amazing way. Users need to know what the application does and how it works without having to research a bunch.
I have realized that the SoW only matters when trust isn't there. It prevents people from delivering crap and other people not paying for the crap that was delivered. I know this is an ideal world. We really don't need lawyers if no one breaks the laws. Or even more existential, we don't need laws if everyone did the right thing. :-) The problem is everyone has a different idea of what is right regarding software.
Everyone wants to be heard, they want their opinion to be voiced and validated. However, some opinions don't matter. I don't need to hear everyone's idea and then make a decision based on 20 people saying 10 different things.
Identify the ground rules, figure out the rules, who is the decision maker of the group. and then go from there.
Build trust, create working prototypes, and work on it over time. That's it.
I'm done for now.