We’ve all been there—that moment when you realize you’ve bitten off a little more work than you can handle. Interestingly, the more you increase your skill level, the more often you find yourself in this situation. It stands to reason; people like to assign work to competent and talented people. Read more on You Can’t Always Outwork the Requests! (How to Reduce an Overloaded Queue)…
Project Management
Best Practices for Scheduling Creative Teams
Managing project team schedules is one of the most challenging parts of running a consultancy. Optimizing for client release dates, assigning the right team to the job, creating good mentoring opportunities, connecting individual team members with a project that they’re personally passionate about, and minimizing schedule gaps to protect your own cash flow is an exponentially difficult problem that keeps getting more and more complex as the company grows. Read more on Best Practices for Scheduling Creative Teams…
Don’t Suffer in Silence – A Template for Scary Conversations
People are complex and not always direct in their communication. This dynamic has the potential to create misunderstandings that can lead to a lot of anxiety when developing software. I’ve felt that anxiety myself from time to time, and it can be poisonous, leading to a lack of sleep, a lack of trust, and ultimately reduced productivity. But there’s a better way to handle confusing situations.
Read more on Don’t Suffer in Silence – A Template for Scary Conversations…
Agile + Scrum = More Effective Iteration Meetings
Do your iteration meetings drag on forever, include thrashing and tangential conversations, or seem generally unproductive? Being structured about agile iteration meetings allows the Development Team to stay on track and get the most value from stakeholders’ time. Read more on Agile + Scrum = More Effective Iteration Meetings…
Growing Developers and Designers into Leaders
Technical and design skills are critical to the work we do building software. But it takes much more than technical and design excellence to bring a complex project to fruition and run a successful consultancy. Read more on Growing Developers and Designers into Leaders…
Project Leads vs. Project Managers
Atomic Object has no dedicated, specialized project managers.
Instead, we have project leads who play multiple roles of implementor, team lead, and project manager.
Benefits of the Project Lead Model
As a designer or developer, the project lead is intimately familiar with the product’s user needs and related features. They know the team’s implementation plan and can creatively consider alternatives if constraints challenge the original plan. By also playing the project manager role, the project lead will be able to anticipate constraints early on and manage the team and scope appropriately.
For instance, let’s pretend you are the project lead, and your team is working on an administrative reporting interface that shows eight key reports related to user conversions and activity. The reports are going to be run monthly by one person. As the reporting interface is being designed, the client identifies other ways their users want to manipulate reports and select data. Read more on Project Leads vs. Project Managers…
7 Ways to Keep Your Big Project Agile
Most of our projects here at Atomic Object take just 2-6 developers. But sometimes we work closely with other teams that are much larger.
On my current project, we’re part of our client’s much larger team, about 20 people. The team started out small, and as we’ve grown in size, we’ve had to refactor our project management practices as well as our code.
Here are a few of the ways we’ve refactored our Agile process.
1. Keep Your Stories Small
At a smaller size, we were successful with having stories that were about a week or less in size. As we have been growing, these bigger stories have been causing us some pains. Lowering the maximum size of a story to 2 days in size has worked well for us.
Prioritizing Refinements – Choose Wisely
As software craftspeople, we constantly reach for sublime elegance in our work. Just beyond every module rewrite or subsystem refactoring is the paradise of ultimate modularity, configurability, and simplicity — somewhere we never quite arrive.
However, we shouldn’t fall prey to actually believing that given the necessary time to implement every abstraction, refactoring, and re-organization is doing the world any favors. Useful software needs to be used. To be used, software needs to be in the hands of users. To get into their hands, it needs to be shipped.
Most vectors for improvement are only visible once a piece of software is being used by people who didn’t create it. This is the most important point to reach in a software product’s lifecycle, as quickly as possible.
The Three Layers of Management
We’ve always made project management an important and inseparable part of our development and design services. When Atomic Object was younger, we would tend to focus on the technical aspects of project management — story estimation and prioritization, velocity, burn charts, etc. This made us very good at the predictive or quantitative aspects of project management.
Over time we’ve learned that while delivering a product on time and on budget is important, it doesn’t guarantee the success of the product. We also care deeply (or “give a shit”) about the actual market success of the products we build. Because of that, we have expanded our responsibilities (while still using self-managed teams) to include other aspects of management that we think are crucial to making a product successful.
I’ve broken them down into the following three categories:
- Product Management
- High-Level Project Management
- Technical Project Management
What Business Leaders Must Do in Multi-Project Environments
Before continuing to write about the specifics of managing software projects, I want to double back around to explain the most valuable things that must be done in any company attempting to run multiple projects at the same time. Below are a few examples of such companies and the difficulties that may be experienced.
- A US-based manufacturing company has over 150 product development and manufacturing improvement projects, all bottlenecked in the tooling department.
- A global consumer goods company has a three-year backlog of IT projects needed to improve the business. Their 300+ army of IT people can only focus on the biggest projects, and even these are running late.
- Product development teams within a large global manufacturer are frustrated by their inability to manage all the projects and deliver to the market in less than 12-24 months, without any reliable prediction of when a specific project will be done.
These situations cover a diverse set of operations and products, but they all have one thing in common. All are attempting to execute multiple projects across a finite set of people and resources. Read more on What Business Leaders Must Do in Multi-Project Environments…