Hi, welcome!

I'm Alex, and I came up with the idea of Atlas Principle based on my 15+ years of experience as a senior/staff engineer. I've had the pleasure to work across many organizations, teams, projects, and many many talented folks.

Let me share some of the problems I repeatedly had to face and how that translated to something to help you avoid all the pitfalls I fell into

Daily standups as status meetings

Maybe you've heard or read it a few times that "you're not doing agile right", and while it doesn't mean you're doing it wrong, I've found it true that many teams do what they think agile is, but not what's written in the books.

So about the daily standup: it is supposed to be a meeting for developers to coordinate on what they will do to achieve a sprint's goal. It's sometimes referred to as "daily scrum". Scrum itself is a borrowed term from rugby. It's supposed to be quick, to the point, and the purpose is to align on what everyone's set out to work on next, and whether the sprint has to be adapted based on new information.

The coordination between developers should be self-organized, and ideally shouldn't require a facilitator. What I mean is: no lead dev or product owner going through each person's tasks and interrogating them about progress and estimates.

You might have guessed it, but the latter is what usually happens over time, especially if teams don't deliver and trust erodes.

As a side note, I also became frustrated by working with boards. Let's say you need to pull a card back from testing to in progress, that sometimes requires horizontally scrolling which is janky at best on all platforms I've worked with. Nothing major, just... why?

Staying on the topic of scrolling: you always see one slice of the whole story. Either only some of the states (horizontal scrolling hides them), or some of the work (vertical scrolling hides them). Let's leave the board behind, and have a list that lists each task's status and shows the same information much more densely:

A couple of things to note here:

• There is no manual ordering, tasks naturally bubble up to the top the closer they are to being finished. This helps you finish current tasks before starting new ones.
• The status is a visual indicator that doubles as a selector too. Hover the state you want to move your ticket to, click, done. Beats dragging cards around and using dropdowns.
• This screen communicates and encourages setting a limit for your WIP. WIP means work in progress, and it relates to the first point about pushing work out. By setting constraints here, you are somewhat forced to complete things before being able to jump on something else. Great way to avoid getting blocked for longer periods of time.
• It's not shown on the screenshot, but collaborators (yes, there are no assignees) are also shown, and can be filtered for. If anyone is curious what each team member is working on, they filter for them and see that they're working alone on one task that's being implemented, and also on 3 others that are in review — probably being the reviewer in this case.

On the landing page there's a note (maybe it'll be removed) that says something like "Made in frustration". This is true for the entire tool. It's true for what it does, how it does it, and how the underlying code and infrastructure is built and managed. More of those details will be revealed as the posts continue, I believe there are many things to share that could benefit you.

As closing notes, these were the main frustrations that led to Atlas Principle:

• Misused daily standups that took 40 minutes, killing any kind of productivity immediately before and after it (not even mentioning that most people were bored because work didn't overlap so there was little useful information being shared)
• Companies struggling to come up with metrics to rank developers from best to worst. If you want to fire people, there might be legit reasons for that, but let's not play this game. None of the metrics I've seen were even remotely accurate.
• Management being lost on how things are coming along, what is being built, and from the other end: why are we building a certain thing?

We've covered parts of the first pain point today. There's an extra piece that wasn't a frustration, but instead a great idea I saw somewhere else: recommending things you can do to save you time/money/make future work easier based on your profile. These are what we'll call "housekeeping".

Thanks for reading through, if you're happy with the direction, agree with the frustrations, or find the tool useful: please sign up and help us improve Atlas Principle.