Talking about risk is hard. Over the past couple years, I’ve adapted an approach from the book Waltzing With Bears by Tom DeMarco and Timothy Lister. Read more on How to Talk about Risk in Software Development…
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…
When we’re running a client’s project using our Atomic Process, our team will assign an estimate of points to each item in the product backlog.
In general, we classify backlog items into three buckets:
- Features (new or enhancements)
- Chores (dev work not resulting in tangible product changes)
- Bugs (fixing unexpected behavior or regressions)
Uncertainty is inherent to software development — it’s impossible to precisely predict how long individual tasks will take. And that makes it very difficult to manage software projects using traditional project management tools.
Making custom software products is extremely difficult and rife with risk—technical risk, business risk, etc. The Product Manager’s job is to see the big picture, manage the risks, and help the whole team make smarter decisions. Read more on Managing Products, not Just Projects…
During the past few months, I’ve taken on the daunting task of collecting some of the important software development lessons we’ve learned at Atomic over the past decade into a body of writing about the size of a handbook. The goal is to capture the ideas in a way they could be easily shared with a new Atomic developer, so as to build a common framework for having conversations about our dev practices here. We’re excited about this resource, and we plan on sharing it broadly when it’s completed.
While working on this project, I learned a few things about managing time and energy by breaking down tasks, categorizing them, and understanding the environmental and time constraints of each type.
Organizing My Work
Once I had an initial outline and a couple of rough chapters, I created a Trello board to track tasks and filled it with everything I could think of that needed doing. Each task was something that would take somewhere between 30 minutes and 1/2 a day to complete. To avoid distraction, if I was working on one task and realized something else that needed to get done, I’d add it to a backlog list in the Trello board.
As software craftspeople, we constantly reach for sublime elegance in our work. Just beyond every module rewrite or subsystem refactoring is the paradise of ultimate modularity, configurability, and simplicity — somewhere we never quite arrive.
However, we shouldn’t fall prey to actually believing that given the necessary time to implement every abstraction, refactoring, and re-organization is doing the world any favors. Useful software needs to be used. To be used, software needs to be in the hands of users. To get into their hands, it needs to be shipped.
Most vectors for improvement are only visible once a piece of software is being used by people who didn’t create it. This is the most important point to reach in a software product’s lifecycle, as quickly as possible.