Zooming Out

If you spend much time around the offices at Atomic, you’ll eventually hear someone mention the phrase “zooming out” in relation to solving a problem. I’m not 100% certain on the origin of our use of the phrase (we may have picked it up from one of our friends at IDEO or Cooper), but I’ve used it frequently over the past two years. And the more I use it, the broader my definition becomes. It’s just so darn useful. Read more on Zooming Out…

Answering Client Questions – 5 Alternatives to “I Don’t Know”

I’ve learned a lot of things in my time at Atomic Object, most of them falling into two categories: how to write great software, and how to be a consultant.

One of the most important skills I’ve learned in the latter category is how to always have an answer for a client.

Read more on Answering Client Questions – 5 Alternatives to “I Don’t Know”…

Visualizing Project Scale, Risk, and Options

We discuss scale, risk, and different options with our customers and team members continually throughout the lifetime of a project. Having a visual representation of the conversation points can be very useful.

A well-designed visual makes it easy to identify the highs and lows, draws conversation to the most important points, and helps everyone navigate the problem landscape. It’s hard to replace the way a good visual can connect with visual learners. And, as an added benefit for me, it removes the temptation to just read a slide during a presentation.

A few quick tips before we dig in:

  • Color matters. I like to browse the palettes on COLOURlovers for inspiration.
  • Double-check your numbers. It sucks to realize your visual is wrong in the middle of a presentation.
  • It’s nice if the visual is easy to update to reflect new information. Simple shapes and a straight-forward scale help that a lot.

Below are a few examples we’ve used recently. Read more on Visualizing Project Scale, Risk, and Options…

Software as a Journey – My Favorite Development Metaphor

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…

How High Should We Set the “Override” Bar?

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?…

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

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!…

Customers – Out of Sight, But Still in Mind

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…

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

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…

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…