Author: Micah Alles

So, your product development engagement with Atomic Object is nearing an end. At this point, we have finished and launched your MVP, worked through your scope-controlled budget for app updates/improvements, or handed the reigns to your internal team. You now have three distinct options for continuing to work with us.Read more on Working with Atomic After Our Initial Engagement – Three Options…

Humility is a highly valued trait in our team members at Atomic Object. This is best exemplified when Atoms admit that they do not know the answer to a question—something I drive for when interviewing developer candidates. How they respond can tell a lot about how good of a fit they will be. Is their “I don’t know” defensive and argumentative, or is it curious and collaborative? Read more on Collaborating? Frame Your Ideas with Curious Humility…

When you’re trying to get started on your first agile/scrum project, it’s easy to find arguments about why it’s a good approach. But it’s a lot harder to find clear, step-by-step explanations of the tools and processes you need to succeed. I’m trying to fill that gap by answering the question: How do you estimate story points on an agile/scrum project?Read more on How to Estimate an Agile/Scrum Story Backlog with Points…

Anyone new to web development can be overwhelmed by the unending supply of choices for tech stacks. Teams just getting started in the industry lean toward something easier to pick up and learn. Teams coming from other platforms such as embedded or desktop dev tend to stick with tools and languages they’ve always used.Read more on How to Choose a Web Tech Stack…

The best process is owned by its team, but everyone has to start somewhere. That’s why I drafted this, a template for Atomic Object’s Agile process. It’s designed to be a starting point for our maker teams as they come together to tackle a new project.Read more on The Atomic Agile Process…

Agile backlogs should be oriented to a client first, team second, and product last. At Atomic, our teams range in size from two to eight developers. Teams larger than eight generate too much communication overhead and require too much effort to manage the backlog.Read more on Why Team-Focused Backlogs Are More Effective…

Anyone who’s led a product engineering team knows that a growing team requires investments in process, communication approaches, and documentation. These investments help new people get up to speed, become productive quickly, stay informed about what the rest of the team is doing, and codify tribal knowledge so it doesn’t leave with people.

One thing that receives less investment when a team scales is its deployment pipeline–the tools and infrastructure for deploying, testing, and running in production. Why are these investments lacking even when the team can identify the pain points? My theory is that it nearly always feels too expensive in terms of both money and lost progress on building features.Read more on Designing a Scalable Deployment Pipeline…