“Everyone tries to do too much: solve too many problems, build products with too many features. We say ‘no’ to almost everything. If you include every decent idea that comes along, you’ll just wind up with a half-assed version of your product. What you want to do is build half a product that kicks ass.” Quote from the founders of 37signals (in Taylor, W. C. Practically Radical: Not-so-Crazy Ways to Transform Your Company, Shake up Your Industry, and Challenge Yourself, 2011).

“Doing less” is a deceptive term, one that gets you thinking. While you might be put off by the phrase because the mantra in most companies is to accomplish more, doing less actually means delivering more value, more throughput, more ROI, more creativity, and being more focused.

What the quote above from 37 signals’ founders says in effect is “think more, do less.” It’s easy to think about what to put into a product, we often get suggestions from a wide variety of sources—engineers, customers, managers, executives, the janitor, and other teams. Product backlogs can grow exponentially. It’s easier to say “yes” to various stakeholders than to say “no.” One of the consistent problems with engineering organizations is too much work-in-process (WIP). Projects are undertaken because the prioritization scheme breaks down (if there is one). It’s easier to tell the VP of manufacturing that “we’re working on your project,” than “we can start on your project in 2 months when we have adequate capacity.” So projects stack up in WIP and throughput drops, sometimes drastically, because of thrashing and multi-tasking.

Each of us have a handy “To Do List”, maybe what we need is a “To Do Less List.” There would of course be some process around these lists. For example, one rule might be that for every entry on the To Do List we have to make one on the To Do Less List. A product manager might create a backlog of features to do, and another backlog of features not to do. Having an explicit list of not to do features sends a message to everyone that this list is important. Deciding not to implement a feature isn’t enough—they have a tendency to creep back on the active pile.

Similarly, you might keep a list of all the meetings you decided not to attend (this one isn’t as difficult). As you start keeping meetings to attend and meetings not to attend lists, you begin to think about and refine the criteria for each. Actually, you will begin developing these criteria for each of your dueling lists.

You could even think about celebrating your “Not Done” lists at retrospectives. Here are all the features we did; here are all the ones we didn’t do. Here are all the meetings I didn’t attend this iteration. Here are all the projects we didn’t start this month. Here are all the overhead items we pushed aside last quarter. Obviously we also celebrate what we accomplished, and that those accomplishments were sharply focused on value, on real customer solutions, and on creative ideas. By lining up both lists, we begin to see how our focus on effectiveness rather than raw productivity actually improves overall performance.

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

In The Zone with Marcin Zasepa

Welcome to the second in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Marcin Zasepa, CTO at Homegate AG in Switzerland. Every episode will be approximately 30 minutes

Read More »

In The Zone with Sasha Bilton

Welcome to the first in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Sasha Bilton. Every episode will be approximately 30 minutes long, and we aim

Read More »

Case Study: DAZN Data Engineering

Find out how 101 Ways helped DAZN improve their existing data warehouse as well as planning and setting the foundations of the new cloud-based data platform. Click here to download the full case study. Get in touch with a member of the 101 Ways team if you would like to discuss ways in which we can help you and your company

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. Allaboutagile.com is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?

London

101 Ways Limited
41 Corsham Street
London
N1 6DR
United Kingdom

Manchester

101 Ways Limited
No.1 Spinningfields
Quay Street
Manchester
M3 3JE
United Kingdom

Amsterdam

101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam
Netherlands

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at contact-us@101ways.com.