Supersonic Project Velocity!
Many companies find that general project velocity isn’t anywhere near what they want it to be. After having successfully managed a number of projects, I often find myself shocked by the vast contrast between how fast projects could be delivered and how long they generally take in the software development world. Recently, I led a 7-day highly-ambitious software project in which both the quantity and quality of work delivered blew away all my expectations. This is what empowered such incredible productivity.
In my personal journey as a project manager, I have been managing software projects for just over 3 years. Recently, I organized a team of 6 primary contributors, working remotely from various countries, with a variety of experience levels, a mixture of professionals and hobbyists, and a blend of different roles and specialties. Together, in just 7-days, we completed 550 tickets across 609 commits, and completed a very ambitious open-source project on-time and under budget. These are the key factors that fueled such an incredible pace:
1. Motivated People Deliver
This is the biggest key to a successful project. When people are individually motivated to make the project succeed, the project is setup to succeed. It doesn’t matter what the motivation is, but it has to be an intrinsic motivation, and it has to come from the individual himself. Group motivation isn’t important. A particular person may be motivated by desire for money, public acclaim, learning, social acceptance, altruism, competition, or any other driving force. It’s important to have that motivation aligned with what is best for the project.
- Will a learning-oriented person learn more if they do certain kinds of tasks? Let them have those challenging tasks.
- Will someone driven by ego produce better art? Give them the high-profile art tasks.
- Will a money-driven person work harder if those efforts translate directly into money? Pay them per task instead of per hour.
- Is a person motivated by altruism and wants to contribute to the world? Make it easy for them to help create a better user-experience.
A well-managed project ensures that each individual’s motivation is aligned with the needs of the project, and that any detractors from those individual motivations are minimized.
2. Microtasking Maximizes Momentum
With some projects, I have seen developers working on the same ticket for multiple consecutive days. Are they stuck? Are they making progress? Is the project healthy? This is a recipe for disaster.
One key to a well-managed project is a very short cycle time. Fast feedback cycles are incredibly empowering and even addictive. Like a person’s heartbeat or breathing, a healthy project should continually have tickets flowing through from Created -> In Progress -> Done. This is hugely beneficial for several reasons.
- Microtasks activate people’s natural psychological reward center.
- Microtasks make it easy to see which pieces of work are large, complex, or bottlenecks.
- Microtasks ensure that the project always has momentum.
- Microtasks keep the project codebase fresh and compels Continuous Integration.
With microtasking, the momentum and energy of the project is always tangible, and continually morale-boosting. When the team is shipping an average of 78 tickets per day, it’s easy to watch the project evolve before your eyes. Every time you run the latest code, you are playing with new features, seeing new art, hearing new music, and not getting bothered by bugs that were present just an hour ago. It’s electric!
3. Communication is Crucial
In order for a team to work effectively, communication must be clear, efficient, and rapid. Any gaps in communication can be very costly, leaving team members stuck, uncertain how to proceed, or spending effort on the wrong things.
- There must be clear documentation on how work should be worked on and delivered.
- There should always be a very clear list of what work should be done, in what order, and what its requirements are.
- Work should be clearly partitioned so that each team member knows which work is theirs and which isn’t.
- There must be excellent real-time communication channels so that team members can get feedback, ask for help, encourage each other, and solve problems together.
All answers to general project questions should be added to the documentation so that other members won’t need to ask them. Role leads should always prioritize communication over work, since empowering the team members and unblocking them is essential for maximum velocity. This also means being proactive about expressing things that need to change. There can be no hesitation in communicating which things are what the product needs, and which things are totally wrong. If there is a feature or piece of art that doesn’t fit, communicating that as quickly as possible eliminates a lot of waste and costly rework.
4. Use Actual Sprints
One thing that is totally wrong in many Agile projects is the idea of a sprint. Most projects that nominally use sprints, will always try to run their sprints back-to-back, with no real space in between. This is totally wrong!
The whole metaphor of the sprint is meant to evoke the runner’s experience. For a very short period, maximum effort is applied, and afterwards the runner rests. This is opposite of long-distance running, in which the goal is a sustainable pace and high endurance.
If you want a genuinely high-velocity project, you must use actual sprints. The work should be time-boxed, everyone should work as hard as they possibly can, and once the finish line is reached, everyone must rest. The sprint is finished. An actual sprint should take everything you’ve got, and leave you with nothing left in the tank. It should require incredible effort, and be immensely rewarding. Actual sprints bring out the best in the whole team and help surpass their own personal and group best productivity records. Sprints are only possible for short projects, or for bootstrapping a project in a very short period of time and then easing into a low-energy period of refinement.
People are only capable of going full-speed when they can see the finish line. Without a clear finish-line, they will always hold energy in reserve, and sandbag time-estimates.
5. Product Owners should Manage the Project
Having a project manager is a good thing. It’s better than not having an organized approach to work. But, what is far more powerful than having a project manager is having the product owner or lead designer be the project manager. When the two roles are handled by different people, there is always a time lapse between the way the work is flowing, how quickly things are prioritized, how effectively things are tracked and what the project really needs.
When the product owner also has the project manager role, this lapse is non-existent. The product owner is the person with the most motivation to deliver a successful project, since his reputation is on the line. He is most motivated to ensure that the way the work is tracked, organized, and delivered is the most effective. He cares more about the end result than about charts, metrics, points, and other bureaucratic details. The product owner is best equipped to ruthlessly prioritize, remove blockers, and communicate effectively.