We're hiring!

We're actively seeking designers and developers for all three of our locations.

Project & Team Management

Software as a Journey – My Favorite Development Metaphor

software-journey

What do Film Making, Manufacturing, Construction, A Television Sitcom, Time Travel, and Oyster Farming all have in common? They’re all metaphors for software development (thank you Naresh Jain for your post on Software Development Analogies). Although there are a lot of software analogies out there with varying degrees of relevance to the situation at hand, it seems few people are as fond as I am of the Software as a Journey metaphor.

Into the Unknown

For those of you that aren’t aware of it, this analogy likens software development to a trip across unknown terrain. As your journey progresses, you run into obstacles that you never anticipated such as mountains, rivers, deserts, or oceans. In software creation, these could be considered analogous to political limitations, interoperability problems, communication barriers, or any other roadblock that confronts you during the course of a software project. A nice illustration of the analogy can be found here. Read more on Software as a Journey – My Favorite Development Metaphor…

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

How High Should We Set the “Override” Bar?

thumbs-down

I recently attended the 2014 Agile Conference in Orlando and really enjoyed my time there. One of my favorite sessions was the “Netflix Organizational Structure: Freedom, Responsibility, Impact, and Agility” talk presented by Roy Rapoport.

I found the presentation full of great ideas, but one stood out especially — the concept of a manager’s “Override Bar”. Roy explained that Netflix optimizes its culture for innovation first, hires the best people it can across the board, and largely trusts them to choose and plan their own work. But… what do you do as a manager when your team wants to work on the wrong thing? Read more on How High Should We Set the “Override” Bar?…

Posted in Project & Team Management | Comments closed

Tools & Practices for Remote Teams, Part 2 – Communicate, Communicate, Communicate!

Two developers stand in front of a large monitor, conversing with two other developers via a video call.

This is part two of a two-part series on tools and practices for maintaining a healthy and effective remote team. In part one, I discussed infrastructure and tools for remote teams. In this second part, I’ll be focusing on day-to-day practices and attitudes. As with part one, this advice is not only for remote teams — you’ll find it beneficial even if you work on a co-located team.

The central tenet of maintaining a healthy and effective team is to make morale, cohesion, and communication a priority. Read more on Tools & Practices for Remote Teams, Part 2 – Communicate, Communicate, Communicate!…

Posted in Project & Team Management | Tagged | 3 Comments

Customers – Out of Sight, But Still in Mind

remote-meeting

A lot of discussion seems to happen around whether pair programming is good or how to do it pragmatically. Ditto on unit testing, and especially test driven development. Oddly enough, I don’t hear nearly as much conversation about the customer role and the common Agile strategy of having an “on-site customer.” Read more on Customers – Out of Sight, But Still in Mind…

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

Tools & Practices for Remote Teams, Part 1 – Be Prepared

Two developers standing in front of a large monitor, having a remote video call with two other developers.

In this two-part series, I’ll be writing about the day-to-day realities of working as part of a remote team, and some tools and practices you can use to help keep your team healthy and effective. Even if you’re not involved in a remote team, you’ll find much of this advice to be beneficial for co-located teams as well.

For a higher-level perspective on remote teams, be sure to check out Shawn Crowley’s advice for organizing and managing remote software projects.

If anyone is remote, you’re all remote.

When you imagine a “remote team,” you might picture team members scattered across the country, or even around the world: one in Chicago, one in Denver, one in Rio de Janeiro, one in Mumbai, one in Berlin, etc. But your team doesn’t have to be that distant from each other to be “remote,” nor to benefit from this advice. For example, Atomic Object’s Detroit and Ann Arbor offices are a mere 45 miles apart, yet we’ve found these tools and practices hugely beneficial for inter-office collaboration. Read more on Tools & Practices for Remote Teams, Part 1 – Be Prepared…

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

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.

project-scope-burn-chart

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…

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

Post-Mortem of a Failed Project

film-set

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

photo1

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).

burn_1

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