Good management at Atomic is putting people in the right context for success and getting out of their way. In other words, we hire trustworthy people, then trust them.
At lot goes into that simple statement. Read more on Short-Handed Management Model – Five Practices that Make it Work…
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…
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…
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…
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 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…
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…
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.
Read more on Poly-skilled Teams Deliver Products…
During the myGRcitypoints project we used a backlog that integrated design and development tasks.
To minimize rework, we strived to complete design and markup tasks before writing the related code.
We thought an integrated backlog would allow for better collaboration and task sharing between team members (especially on IA, IxD or markup tasks that can be more easily shared between team member from design or programming backgrounds).
Read more on Managing Agile, Poly-skilled Teams with Intermediate Milestones…
This year at Atomic Object, we implemented a new practice: designers, instead of sitting all together in a group, sit co-located with the developers on their project. There is no “design team” or “development team” here; we all belong to “project teams.” This is just another step in our continued efforts to tightly integrate application design with application development, and in my opinion, it’s been a successful one.
Including designers on the project team rather than setting them apart promotes open, continuous communication between team members. I love having my team handy to ping them for ideas or perspective on design work that I am doing, whether it’s UI/UX work, graphic design tasks, or design implementation with HAML/Sass. Similarly, they might glance over at what I’m doing and say something like, “Hey, that’s really cool!” or, “Don’t forget (insert application requirement here)”. Being close together also means we’re all on the same page with regards to project-related decisions or communications with the client. Following the progress of the development team and synching up with the project lead is just a natural part of my day.
Read more on The Benefits of Poly-Skilled, Co-Located Project Teams…