Design is essential to software product development, and developers have a crucial role to play in good software design.
Atomic’s path to understanding what design does (and all the various activities covered by that seemingly simple word) began when our company was a few years old. We were turning out great code, and we were predictble with time and budget, but we’d started to notice that:
Read more on Why (and How) Developers Should Care about Design [Video]…
Created for recent Computer Science grads, Atomic’s Accelerator program is designed to supplement their development training and get them up-to-speed fast on higher-level consulting practices and skills. Participants in Atomic’s Accelerator Program make a commitment to study on top of their 40-hour work week, and they receive significant coaching and training in project management, team leadership, and handling customer relationships.
In recent weeks, I’ve had the fun and energizing opportunity to lead the design-focused portion of our Accelerator curriculum. Members of Cell Zero have been doing three to four hours of reading homework on design topics each week, complemented by two-hour discussions in which we unpack and distill our learnings.
Read more on Atomic’s Curriculum for Teaching Young Developers about Design…
Over the past several years, agile software teams have recognized the necessity of welcoming designers into their ranks. At the same time, organizations throughout the industry have struggled with and offered different perspectives on the “best way” for designers and developers to work together on agile teams. Read more on Some Design Up Front: Why ‘Sprint Zero’ is Not Enough…
Update February 2015: Tickets for the event are now on sale! Early bird tickets are available through mid-February; standard tickets will be available after that. Please visit the Balanced Team 2015 Grand Rapids website for more information. We’re excited you’ll be joining us. See you soon!
Many teams and organizations struggle with the question, “How can creative teams work together to produce valuable, validated outcomes in an environment of extreme uncertainty?” This is a tough question — and surely has no single answer — but it’s one that the Balanced Team group has been addressing head-on since 2009 through meetups, mailing lists, and conference presentations.
Balanced Team events have been held in New York, Boulder, Austin, and San Francisco in the last few years, and now it’s coming back to Grand Rapids. Brittany Hunter, Gail Swanson, Rick Harlow, Lane Halley, and I are excited to announce a Grand Rapids Balanced Team Summit on June 13 and 14, 2015!
We’ll be gathering around 100 multidisciplinary software practitioners with traditional design, business, and engineering backgrounds for two days of talks, fishbowls, and workshops. We’ll again be tackling the above question. Read more on Balanced Team is Coming to Grand Rapids in 2015…
Atomic Object is hiring software designers to add to our teams in Grand Rapids, Ann Arbor, and Detroit. We’re a great company to work for, with competitive pay and benefits. Here’s how to apply.
I’ve been a designer at Atomic Object for almost three years now, and I love what I do. My colleagues and I are continuously working to build, grow, and improve a thriving design culture at our company.
Design culture is a tricky thing. It doesn’t just happen, especially when you’re trying to build it within an existing company. Whether that company is a software development company like ours, a startup, or an established business looking to enhance their offering through good design, you need to be purposeful about creating an environment where all facets of design — from divergent thinking, user research, and concept investigation, through visual design, user experience, and implementation — are supported and valued. Adding a few Nerf guns and trendy posters won’t cut it — a company that’s truly supportive of design will experience a culture shift from the inside out. Read more on 5 Characteristics of a Thriving Design Culture…
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…
The distinction between between developers and designers doesn’t make sense. We’re all designers — or we should be.
At Atomic Object, our teams work on software products in an agile design process that infuses all stages of product development. Each member of the team is an active participant in the design process. The design process, when executed correctly, builds from one level of design to the next. It guides both developer and designer, effectively making each member of the team a designer at either the strategic, tactical, or tangible level of design. Each member contributes to the design process when it’s appropriate.
“…designing for complex digital products and services requires input from a number of unique perspectives to be truly effective.” – Nate Fortin, Cooper Design
Designers are more valuable to software product development efforts than programmers. Designers will continue to fuel and shape innovative product development efforts as programmers fall by the wayside as a commodity to be cost managed.
Atomic started down the path of tightly integrating design and agile software development in October 2007. Before that time we’d relied on outside designers, partner firms, and even our clients for the various activities and artifacts that go by the name “design.” We felt then, and we know today, that by integrating design and development we could make better software products for our clients. (Here’s my slightly off-color metaphor: Design and Development get in bed together. What results? Beautiful little product babies!)
Consistent with our mistake-driven approach to business, we’ve tried a lot of different things in those four years. We bailed on what didn’t work, we tweaked what was close, we tried new ideas — we are still in fact learning our way through this problem. What I can say conclusively is that there’s no going back. Atomic is so much stronger for having our own designers, and the work we do for our clients is so much better, and life is just so much more interesting, that despite the additional complexities and some remaining challenges, the results have absolutely confirmed the vision.
Read more on Reflections on Four Years of Integrating Design and Development…
A lot of what sets Atomic Object apart is our people – we work very hard to ensure we hire the best. But hiring great people isn’t enough. The best people need to be set up in an environment where they can use their skills effectively and translate their excellence into business value. Atomic’s strategy of deploying poly-skilled, co-located teams of generalists puts us in a position of delivering quality to every customer every time.