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)…
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…
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…
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…
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…
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…
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.
In my day job as a developer at Atomic Object, I work on just one project at a time, giving it my full attention from start to finish. But after work, in my free time, I have side projects. A lot of side projects. Dozens of them, swimming around in my brain, each one occasionally rising to the surface for a breath of attention.
Most of them are what I would call hobby projects. For those, I’m generally content to let my interest and focus levels wax and wane naturally, without forcing myself to keep at it. For example, I’ve been learning to ride a unicycle, but it isn’t really very important to me. If it stops being fun, interesting, or rewarding, I can just move on to something new and exciting, and come back to it later if I feel like it.
But there are some projects that really matter to me — projects that I really want to see through to the end. These are more than mere hobby projects. They’re passion projects.
One such passion project is a computer game concept that has been brewing in my head for nearly a decade. I have made several serious attempts at creating it, but I never got far. Each time, I would start off well, but eventually find myself wandering aimlessly with no clear plan or road map, until I inevitably lost focus and motivation. And each time, I would feel frustrated and disappointed at my own lack of discipline and persistence.
Why did I keep failing, despite my best efforts and intentions? What was I doing wrong?
As it turns out, the answer may have been literally staring me in the face every week.
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.
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