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…

Tear Down the Walls! – Shattering Team Boundaries

One of the biggest complications in large software development projects is overcoming the boundaries between teams. When (and if) things are rolling smoothly on a project, these lines can be nearly non-existent. But when push comes to shove and deadlines are looming, these boundaries tend to rear their ugly heads.

Applying agile project management to large multi-team/multi-discipline projects can help overcome these boundaries. But if the boundaries and interactions of the teams aren’t handled properly, you can bet your ass you’ll be back to the same deadlock issues commonly experienced with the Waterfall Model.
Read more on Tear Down the Walls! – Shattering Team Boundaries…

Generalist Makers: The Unicorns of the Software Industry

At software conferences, I often meet people who have titles. I’ve made connections with a bevy of “Information Architects,” “Usability Specialists,” “Visual Designers,” “Front-End Designers,” and even some “Project Managers.” They are able to quantify their role within one statement: “I write the HTML and CSS.” “I create the wireframes.” “I do usability testing.”

Whenever I have to give a quick summary of what I do, my one-line description is, “I make software.” It’s a wide description, and deliberately so, because on any given day I might be sketching interfaces, administering usability testing, writing code, doing visual design in photoshop, or tracking hours and budget using burn-up charts and other project management tools.

The Benefits of Generalists

Atomic Object makers are generalists in poly-skilled teams. Some of us have a deeper background in design while others have a deeper background in development, but everybody here is continuously growing their skills in both ends of the pool, and all of the disciplines they encompass. There are many reasons we work this way. Here are three:
Read more on Generalist Makers: The Unicorns of the Software Industry…

Organizational Departments Aren’t Aligned with Innovation

Dedicated, poly-skilled project teams are more effective at delivering innovation projects than well-honed, departmentally-distributed, operationally-focused teams.

The choice of using an internal vs. external team is often considered when planning how to take on a significant innovation project.

Internal expertise and capacity are two common factors used to assess the viability of the internal team.

Even if internal expertise and capacity predictions appear sufficient to internally pursue an innovation project, a departmentally-oriented organizational structure introduces subtle forces that can significantly increase the risk of late delivery and reduced differentiation. Innovation will be unintentionally suffocated.

Read more on Organizational Departments Aren’t Aligned with Innovation…

Designers Are More Valuable than Programmers

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.

Read more on Designers Are More Valuable than Programmers…

Diversity – A Powerful Force for Innovation

Steve Denning, author of The Leader’s Guide to Radical Management: Reinventing the Workplace for the 21st Century has published a succinct overview of  Scott Page’s book The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools, and Societies in Forbes this week. I found Denning’s review of Page’s perspectives on the potential for diversity fascinating. This book is now on my list. Thanks Steve Denning:

Scott Page shows in detail and with considerable intellectual rigor when diversity does lead to better outcomes and how and why, as well as when it doesn’t. His short answer is that in some circumstances diversity doesn’t lead to better outcomes:

“… if a loved one requires open-heart surgery, we do not want a collection of butchers, bakers and candlestick makers carving open the chest cavity. We’d much prefer a trained heart surgeon, and for good reason.”

But in other circumstances, particularly complex problems, such as constructing a welfare policy, cracking a secret code or evaluating post-heart attack treatment, diversity not only merits equal standing with ability.[sic]

Read more on Diversity – A Powerful Force for Innovation…

Multidisciplinary Teams in Embedded Development

Most electronics companies are partitioned in groups like: electrical, mechanical, software, and a testing group. This is, of course, a logical arrangement. New engineers can learn from more experienced engineers, processes can be defined, crafted and debated among people that serve similar roles. The only drawback is that at certain stages of project development it can become important to communicate early and often with people in other departments. If for example, you’re at a stage of a project where a microcontroller is being chosen, the electrical and software engineer may need to make sure that each other’s performance and feature set needs are being met. If a requirements document is being reviewed and developed, then the software, testing, and requirements personnel will benefit from being within earshot of each other.
Read more on Multidisciplinary Teams in Embedded Development…

Reflections on Four Years of Integrating Design and Development

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…