Software development is fun when your team can go fast. You see ideas turn into reality, you watch as customers like (or don't care about) stuff you put in their hands, you  iterate based on customer feedback, and it just plain feels good. So increasing the autonomy, efficiency and velocity of your team is crucial.

But it's hard. You can't just ask people to work faster. I mean, you can, but it doesn't usually result in faster work. Or if it does, the result is poor quality which just makes things slower in the long run.

A prerequistie to doing anything that I'm about to talk about is establishing the problem you're trying to solve. Focus on hard walls and leave the middle soft. Clearly define what the customer is struggling with, get everyone on the same page, then you can brainstorm solutions or develop a list of requirements.


credit: Ryan Singer

Once you've got that, it's time to pull out and combine the secret weapons: Time Boxing and the Pareto Principle

Time boxing is a technique in which a specific period of time is allocated to complete a task or project. Most teams deal with time by presenting a list of requirements and asking "how long will this take?" This results in all sorts of unhelpful antipatterns like stakeholders treating estimates as commitments or sandbagging (teams saying something will take 3 weeks when it should only take 1 to give themselves wiggle room).

Instead, separate from any individual project, the team gives themselves a strict deadline the team are given a strict deadline, like "we're giving ourselves X weeks to deliver something." Basecamp goes into a lot more detail about the benefits of cycles like this. The key is X should not so long that it feels like you can’t see the end, and not too short that it feels like nothing will get done. In practice, 5-6 weeks seems to be a sweet spot for many projects.

Because the amount of time is limited, the thing that must be sacrificed is scope. There simply isn't enough time to do A, B, and C. So the team has to pick. 

The Pareto Principle, also known as the 80/20 rule, states that 80% of the consequences is often derived from 20% of causes.

This is a rough guide, but the distribution can be observed in various aspects of life and business, such as:

When building products, a good assumption is that 80% of a product's value comes from 20% of its features.

When the team needs to pick between A, B, or C (because they only have a limited period of time and have to pick), ask which of these features will deliver the most value, then pick that one. It might not be 80% of the value to customers, but delivering even 50% of the value in that time period is better than delivering 0%.

Important to remember that all of these constraints are artificial. You don't have to complete things in 5 weeks. That's just something you're imposing on yourself. But embrace the constraints. Especially in software development where theoretically anything is possible, constraints are incredibly freeing.

Time Boxing forces the team is forced to choose between features A, B, and C because time is rigid and scope is flexible.
The Pareto Principle helps guide the decision-making process, so the team focuses on the most valuable features.

To start, a team lead or product manager might have to guide this decision making or even just make the decisions themselves. But ideally, the team doing the work should make the decisions themselves. If they've been given enough context, are clear on the goals of the project, and most importantly are given the trust to make decisions autonomously, they'll make the right ones more often than not, because they are closest to the work.

This will free up team leads to set up and define more problems to be solved in the future. Momentum begets momentum, so try it in a small way to start. It will pick up speed.