You Can’t Always Outwork the Requests! (How to Reduce an Overloaded Queue)

We’ve all been there—that moment when you realize you’ve bitten off a little more work than you can handle. Interestingly, the more you increase your skill level, the more often you find yourself in this situation. It stands to reason; people like to assign work to competent and talented people. Read more on You Can’t Always Outwork the Requests! (How to Reduce an Overloaded Queue)…

How to Estimate an Agile/Scrum Story Backlog with Points

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…

Self-Managing People Are Smart about Asking for Help

In my experience, people who truly excel in their careers are always self-managing. They accomplish more, they discover more opportunities for themselves, and (as Verne Harnish says in Scaling Up) they’re the sort of people that smart organizations hire and rely on.

Read more on Self-Managing People Are Smart about Asking for Help…

The Delivery Lead: A New Type of Maker

Atomic is adding a new type of maker called the Delivery Lead to our lineup. Recently, we’ve recognized ways to enhance the experience of our clients and teams and build better software in the process. The Delivery Lead position is the result of more than a year’s worth of experimentation in this area. As one of the first to hold that position at Atomic Object, I’d like to introduce the Delivery Lead role and share the context for how we got here.
Read more on The Delivery Lead: A New Type of Maker…

Stop Making Sprint Commitments!

I’ve become convinced that for most Agile projects, making sprint commitments is the wrong thing to do. I was happily surprised to find out that I’m in good company here—the 2011 Scrum Guide actually removed the word “commitment” in favor of the word “forecast”.

I have three reasons why I’d suggest you stop making sprint commitments and start making sprint forecasts instead. Read more on Stop Making Sprint Commitments!…

Agility is about Accuracy

When you work with Atomic Object, you’ll hear a lot about Agile software development. Agile takes many different forms, but all of them are, at heart, about writing better software faster. Agile is part philosophy, part methodology, and part discipline. The Agile Manifesto emphasizes people instead of mechanical processes.

But before diving into the specifics of how Agile works, let’s back up and look at the problem Agile is trying to solve. Why come up with a new system in the first place?

Read more on Agility is about Accuracy…

3 Steps to Better Project Scope Management

Good project scope management is critical to success in every software project. To ensure that we come in on budget and on time, we have to keep the scope balanced and under control.

1. Don’t ignore the planning phase.

A lot of software projects are doomed from the beginning due to poor planning and underestimating. As software craftspeople, starting a new greenfield project can be an exciting time. It is critical that we resist the urge to jump right in start writing code and initially focus on planning our project with what we know now. Read more on 3 Steps to Better Project Scope Management…

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 rambling in meetings — 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…

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…