Company X has been developing software for decades, and they still suck at it! Why why why?!?!1
Agile and Scrum were supposed to solve this, right? Here's my take on why it still doesn't work well at most places, and some small tweaks you can do to make things work a LOT better!
Screwing up the Agile values
The Agile values are quite sensible. They value the stuff on top of the image more than the stuff on the bottom. It doesn't mean the stuff on the bottom should be ignored. Pretty simple, right?
If you want to screw things up
Create strict boundaries and don't let developers speak directly to each other. Argue that developers should always go through a PM (Product Manager) or similar. This just leads to a whispering game where the message changes, sometimes greatly, before it reaches the final developer.
Require comprehensive design documents and product documentation, knowing well ahead of time that these docs won't be read.
Have the customer specify things in detail and be anal about it and develop exactly to spec.
If you want to make it work
Trust your developers in making decisions between themselves. This trust will eventually make your "software developers" into "product developers" - people who think about the product and not just the code. Inform the PM during Scrum so he's kept in the loop, and knows what's going on.
(Non-trivial) development contains a LOT of exploration. There's no way to document a detailed plan up ahead. Document the intent, and then let the smart people you hired do their thing.
Have your developers use common sense and ask themselves "Is this thing I'm building right now turning out well?". Put yourself in the shoes of the user - it's as simple as that. If it doesn't feel right, then it's probably time to change things up a bit. It needs to be quick and easy to get hold of the "customer" (or their proxy, the PM) to make sure you're not stalling waiting for a reply.
Screwing up the Epics, Stories, Tasks
I'm pretty convinced the creators of Scrum were semi-trolling us when they came up with these names (I've even heard of people creating "Super Epics" or "Themes").
In reality, these names hold little more meaning than "Task", "Group of Tasks", and "Group of Group of Tasks" does. I guess it's a bit easier (and more fun?!) to say "Epic(!)" instead of "Group of Group of Tasks" though.
In my opinion, this is what the different terms should be used for:
Epic
Something larger, functionally complete, that stakeholders outside of the dev team care about.
A somewhat obvious example would for example be a "signup and login flow".
A more non-obvious example would be a change to the data storage layer that's necessary for whatever reason. The outside stakeholders probably don't care about the data storage layer per se, but they probably care about things not breaking down if you onboard more customers. Remember to frame your Epics in a way so that they make sense to stakeholders outside of the dev team.
Story
A piece of work that needs to be done as part of the epic. Intended for the developers in the dev team.
"Create a visual mockup for the login screen"
"Implement the visuals (with HTML and CSS)"
"Create auth cookie and redirect to the dashboard on successful login"
Some mandate that story titles should be written in the format "As an X I want to Y so that Z". In my experience this doesn't work well AT ALL. It decreases the information density in the story title, by adding details that aren't necessary when trying to figure out what the story is about.
I like to add a "Reason" and "Acceptance Criteria" (and sometimes "Notes") as part of the Description of the story instead. This is where you should document the "why" - not in the story title!
Task
Don't use them!
Tasks should often just be "# TODO" comments in code. This is much more fluid and easy to work with. The reason is that as you discover new things to do you don't want to go back to your issue tracking system every single time. This just leads to the developer keeping their tasks in their head or personal note taking systems instead.
If you want to screw things up
- Make a complex system of rules and regulations with a lot of hard requirements on how things should be done.
If you want to make it work
- Keep it simple, and allow the team to come up with something that works for them.
Screwing up the planning
The planning meeting can be extremely boring if it's not done right. However, if done right, it can be the highlight of the week, where you ideate and discuss how to do things.
If you want to screw things up
Require everyone from the whole team, and other stakeholders, to be on a long call where they're only active for about 5% of the time.
Create stories with a long and detailed description, and lots of acceptance criteria to avoid uncertainty.
If you want to make it work
Start by having a short high-level planning meeting with everyone involved. Go through what you're planning to do during the next sprint, and allow people to ask questions. Have "placeholder" stories that the PM created before the planning meeting.
Once you've had the high-level meeting, split off into smaller groups and refine the stories. Backend developers might for example split up into one group, frontend developers might join up with your UI/UX developer etc. The PM can be available to be called in when needed.
This way everyone can actively contribute to their respective meeting, and you can discuss ideas and thoughts at the "right technical level".
Have your developers discuss how to implement the story, and write it down as part of the story description. Yes - this takes a lot of time! You'll be looking at a lot of code together when doing this. However, it's a great opportunity for knowledge sharing and getting properly good stories with accurate estimations.
This is work developers will have to do anyway when working on the story, so there's no effort wasted.
I like to create stories that take either "a few minutes", "a few hours" or "a few days" to complete. I know this is way smaller than a lot of people do. The reason is that stories that are estimated to take 5+ days often contain huge amounts of uncertainty, and should be split into smaller pieces.
Screwing up the team
A core feature of an Agile team that a lot of people seem to forget is the fact that they need to be self-sufficient.
If you want to screw things up
If you want to make it work
Create a team that's completely self-sufficient when it comes to their day-to-day tasks. A good team setup can potentially look like this:
Two backend developers
Two frontend developers
One UI/UX developer
One Product Manager
Let the PM and the developers make the decisions. Ask for forgiveness instead of permission. Demo things regularly to your customer instead.
The TLDR; Summary
Sorry - there isn't one!
Planning and working with the high levels of uncertainty we face in software development is not easy! Talk to each other, and try to make your (lightweight) process better every sprint! Try new things! Most of them won't work, but a few will!
Team happiness is way more important than accurate estimations! Make sure you're not trying to enforce a draconic process your team members don't like.
