We're hiring!

We're actively seeking developers and designers for our Ann Arbor & Detroit locations.

Project & Team Management

Post-Mortem of a Failed Project


I recently read an article detailing the many production woes of the rather unimpressive 1994 Street Fighter movie. At the time — given the cast, director, and writer they’d lined up — it seemed like a promising property. Writer/Director Stephen de Souza had been responsible for some of the most iconic 1980s action movies, and they’d also managed to cast noted actors Jean-Claude Van Damme and Raul Julia.

In retrospect we know how badly all that promise was squandered (if we remember that movie at all), but when I read the analysis of exactly how it all went wrong, I was struck by just how mundane and familiar their issues were: changing requirements, tight deadlines, shifting schedule and priorities.

In other words, all the same things that seem to plague doomed software projects. Read more on Post-Mortem of a Failed Project…

Posted in Project & Team Management | Leave a comment

What Rambling in Meetings Says about Your Team


A group of uniquely skilled individuals working towards a single goal forms a team. On a good team, every player is contributing and looking out for their fellow teammates. On development teams, I’ve found that paying attention to the things that cause us to ramble – that is speak about a topic for an extended period of time – gives a good insight into the parts of the team that are causing issues or will cause issues in the future. Read more on What Rambling in Meetings Says about Your Team…

Posted in Project & Team Management | Tagged , , | Leave a comment

Evolution of a Burn Chart

Burn charts have been a staple of Atomic-run projects for quite a while. They’ve also been the subject of much discussion both internally at Atomic and at-large in the Agile development community. The basic concepts are simple, and we’ve found them useful — especially when they are allowed to evolve as we learn how to better engage our customers and teams. I’m going to tell a story of one such evolution.

First, if you’re unfamiliar with a basic burn chart, check out Mike Marsiglia’s previous post about Atomic burn charts. Got that down? Great!

I’m going to follow the story of a ficticious company, Acme, Inc., working on a custom order management system. Our burn chart experience started simply, as Mike’s example illustrates: one big scope bucket (represented by the blue line), and a team of three working to realize the features represented in our backlog (represented by the green line).


Read more on Evolution of a Burn Chart…

Posted in Project & Team Management | Tagged | Leave a comment

Breaking Your Budget into Categories

I’ve been at Atomic Object for approximately 8 years, and during that time I’ve had the opportunity and the challenge of managing relatively large software projects. I’ve learned quite a bit from fellow Atoms and picked up a few tricks of my own throughout the years. One of the best practices I’ve picked up is keeping a well-organized and properly-categorized budget.

Software projects are generally given an overall budget that a team can work against. However, the realities are that a budget can be made up of a number of different components — some of which have nothing to do with actively creating features and are instead meant to be used for upfront processes (Kickoff and RDP Phase), customer communication, project management, technical documentation, etc. Depending on the overall complexity of your project, you may have one or two of these categories or all of them. Read more on Breaking Your Budget into Categories…

Posted in Project & Team Management | Tagged | Leave a comment

Avoid Big-Bang Integration at All Costs!!


Though we all (hopefully) know the dangers of last-minute big-bang integration, large multi-team, globally-dispersed projects still fall into this trap all too often when crucial deadlines are looming.

Wanting/needing things to be done, despite the reality that multiple pieces have run past their expected/planned completion dates, does not warrant cutting corners. In fact, these times are where our scientific/engineering ethics tend to clash with our business ethics and create a very toxic environment for all. Read more on Avoid Big-Bang Integration at All Costs!!…

Posted in Project & Team Management | Comments closed

Tackling Silence, Avoidance, & Negativity in Project Retrospectives

Improve Your Retrospective

At retrospective meetings, we reflect on how our team has been operating, sharing both the good and the bad. We try to identify problems and take actions that solve those problems.

But just as important as fixing procedural problems is giving individual team members the chance to speak, be heard, and “air-out” anything that’s been bothering us. Ideally, we will honestly share our feedback and perspectives, and humbly acknowledge our mistakes. In reality, though, most of our retros fall short of that standard. Here are some common problems and ideas to help work through them. Read more on Tackling Silence, Avoidance, & Negativity in Project Retrospectives…

Posted in Project & Team Management | Leave a comment

A Checklist for Great Feature Requirements

Checklist Feature Requirements

My long-time girlfriend works as a Business Analyst for an IT company that does agile development. Recently, she asked me what I (as an engineer) look for in an ideal requirements document for a feature.

This hit home for me because I have seen plenty of poorly-defined features on projects I’ve worked on. Poor requirements usually lead to slower development times and features that are more likely to need rework. As an engineer, I have enough work to do in figuring out the best way to architect and implement a feature without having to frequently halt my work and chase down vague or incomplete requirements.

I did a lot of thinking and came up with a pretty comprehensive checklist of things I’d like to see in every feature request/user story/programming task. Read more on A Checklist for Great Feature Requirements…

Posted in Project & Team Management | Tagged , | 1 Comment

Considering a New Methodology? First, Understand the Question

Solutions are meant to solve problems.

In Douglas Adams’s Hitchhiker’s Guide to the Galaxy series, an advanced civilization builds a supercomputer to calculate “the ultimate answer to life, the universe, and everything.” After millions of years of calculation, the computer finally gives its answer: forty-two. Despite being an advanced civilization, it succumbed to the pitfall of getting an answer without first understanding the question.

We often fall into the same trap. I once worked on a development team that practiced Agile programming. Every now and then the team would debate whether we were really practicing Agile, whether we should do more Agile, whether we should abandon Agile altogether, and whether we should adopt some other methodology. The debates centered on personal preferences and impressions of team productivity. Alternatives were suggested based on what the team had tried before and who had what certifications. Never did our conversations start with understanding what problems the various disciplines were designed to solve. Neither did we begin with the most important question: what problems were we trying to solve? We jumped straight to the answers without first understanding the question. Forty-two. Read more on Considering a New Methodology? First, Understand the Question…

Posted in Project & Team Management | Tagged | Leave a comment

Pitfalls of Integrated Design and Development Burn Charts

When managing a software project that has both design and development scope, I have come to prefer using an integrated backlog of tasks and separate burn charts to track design and development efforts.

Atomic continuously experiments with project management practices that help our poly-skilled teams manage their efforts and predictably deliver custom software products.

I’ve previously written about using integrated backlogs and burn charts and noted in my post that an integrated burn chart can be a bad solution if your team will have people inconsistently allocated throughout the course of the project. Inconsistent allocation can be problematic for burn charts regardless if the team member is a designer or a developer, but I’ve found through experience that it’s almost always true that the design effort on a project will have inconsistent allocation. The potential burn chart distortions resulting from inconsistent designer allocation are also likely increased due to a hours per point skew between design and development tasks. Read more on Pitfalls of Integrated Design and Development Burn Charts…

Posted in Project & Team Management | Tagged , , , | Leave a comment

5 Tips for Estimating at the Point of Maximum Ignorance


Estimating a new project is hard and time consuming. Why? Because when you start a new project, you are at the point of maximum ignorance. In most cases there is a solid idea, but the required functionality is ambiguous.

The business is depending on you — the engineering team — to identify a high-level timeline.

I estimate a lot of projects like this every year. Here are a things I do to cope with that ignorance and ambiguity.

1. Select the Right Magnitude

Begin by deciding a uniform level of precision for your estimates. If you think the project is going to take years, then your estimates should be in weeks. If you are guessing months, your estimates should be in days. And if you think the project is going to take weeks, you should estimate in hours. Read more on 5 Tips for Estimating at the Point of Maximum Ignorance…

Posted in Project & Team Management | Tagged | Comments closed